1. The Content/Article Writer – This is the juicy stuff. Good article writers come few and far between, but our industry is overpopulated with content providers who fill websites with useless information. We have a core need for writers who can produce quality content. I feel the article writing business should come with no-strings-attached.  Too often, marketers and business gurus want something in return for providing such content, but I don’t believe this is the place for it. In a world where web surfers will leave your website in a blink of an eye, it’s important to continue to provide exactly what the users are looking for. With the help of an SEO, I find it is useful when this content is written by your subject matter experts.
2. The Call-to-Action: Copywriter – This person writes strategically to get a user to do something. This may include obtaining an e-mail address, making a sale, or any other call-to-action. This is especially important in regards to search engine marketing because when you pay for traffic, you want to be sure you get the lowest bounce-rate for the keywords you bid on. Getting a user to complete an action is the best way to quantitatively measure the effectiveness of an advertising campaign. It’s also a way to attribute a dollar amount to each of our users.
3. The SEO - Search Engine Optimization increases a website’s search engine ranking placement, also known as a SERP, in an effort to optimize the flow of traffic for certain keywords that users are searching for. This can include generic keywords (like Web Design, Information Architecture, User Experience Design) that are combined with a relevant location (like Washington, DC), or long-tail keywords (like “Top 5 User Experience Design Issues”). The point is to strategically expose web content to as many relevant users available. An SEO is usually involved with other writers to make changes to improve website quality.
4. The Multimedia/Social Media Consultant - This is a fairly new form of content provider who specializes in the development of other important mediums of content, such as video, podcasts, e-mail, etc. They’re often involved in social media, like YouTube, Viddler, Vimeo, and other video sharing sites to provide information to users. Be sure not to push this person aside, video marketing and other social media platforms are some of the most effective forms of internet marketing. You should consider including this into your strategy.
5. The Editor – This person makes everyone look good. They edit for consistency, grammar, spelling, and ensure a professional product.

As information architects, we bring all of this together to improve the products we develop. We specialize in organizing, generating the correct metadata and taxonomy, and ensuring consistency. Although writing content isn’t necessarily in our job description, I think it’s necessary to step up to the plate and fill these roles when needed.

• 62% percent of projects fail to meet their schedules
• 49% are over budget
• 47% have higher than expected maintenance costs
• And get this—25% are canceled before they are ever deployed!

If you’ve been in the software industry long enough, you’ve probably seen all of these things happen. The funny thing is, it doesn’t really come down schedule, cost, or requirements—it comes from bad design. When software companies think design, they’re thinking about contractual obligations and meeting commitments with their stakeholders.

Click HERE to read the rest of the entry over at Armedia.com

Being a good cop is pretty fun. For one, we’re known as the good guys because you never get into confrontations with people. Everybody likes us because we can make important promises and give users exactly what they need. Kicking off design is where most of us thrive because we love being around users, architecting solutions, and being creative. We always look good because we design based off of our extensive experience in human interaction and cognitive engineering.

It’s never fun when we have to be the bad guy. Being the bad cop happens frequently during and after implementation–when features are not fully developed to specification and it’s our job to call people out on it, ruffle a few feathers, and get things accomplished. Here are some important things we have to remember when being bad cop:

1. If we can’t prove it can be implemented, we really shouldn’t design it that way. The idea is to make something that insinuates the user experience, not something that is up-scope and over budgeted. Simple is okay sometimes. Some of the best interfaces out there are very easy to develop.
2. Be prepared to go behind someone and do it yourself. Not your job, role, or experience? Then you need to work with people you can trust. We should all try to build a skill set where we can play designer-developer if we have to.
3. Be practical. Remind everyone how the users will be effected or try to come up with a solution that is reasonable for everybody.
4. Monitor development regularly from start to finish. If implementation is over and design wasn’t followed to spec, it’s almost too late to make a difference without getting everyone around you frustrated.
5. Making arguments for the users are often not very popular on development projects. Sometimes, you have to make it sound like it was someone else’s idea in order for you to get them to buy in. If management is resistant to buying in, we need to remind them that it is our job to make them look good. User acceptance is a huge risk to the success of any software development product. If the user ain’t happy, ain’t nobody happy.
6. Be prepared to ask for a do-over. If it’s not right, it’s not right, but beware of scope–you can’t make a difference if you get fired.

If we’re going to be exceptional at what we do, we have to embrace the struggles and hardships of being bad cop. It may not make us popular, but it will certainly give us the reputation of being effective.

Being responsible for the user experience is often not what you’re hired for. I’m usually brought on to improve the user interface of an application or redesign it, but I’m rarely called upon to test the usability of an application or measure the effectiveness of a feature.

Let’s face it—most projects do not have a dedicated UX role. I’m not sure why this is—but I do know in the software development industry, user centered design is thought of as expensive. It may eliminate a lot of risk, but it’s still something that hasn’t caught on everywhere quite yet. A lot of projects don’t hire specialists in usability because they’re afraid of what the results might bring. The truth can be pretty scary.

I’ve learned recently that you have to create a User Experience—Experience. Nope, I’m not being redundant at all. You have to create a reputation that the UX guys are the good guys and sell it to everyone you meet. Here are some tips that will help create this experience I’m talking about:

• “My job is to make you look good.” When the users are taken care of, we all win. You have to win over management support and to do so, you have to remind them that when the users are happy, that feature you’re responsible for will make everyone involved look good.
• “Did somebody say users?” Take every opportunity to get in front of actual users. If you’re in a meeting with stakeholders and they mention a particular user or user base that could be affected—that’s when your head should pop up with a big smile asking for a time and a place when you can interview/observe these users.
• “Well, in our user research, we learned that…” If there is an opportunity to cite what you’ve learned from your users, take it. I talk about users almost every day. Your research is the most valuable tool you have. Use it frequently.
• “What would our users think? Let’s ask them!” Never jump to conclusions or let your team guess when it comes to design. Test a few options with a set of users—nobody can argue with the facts.

I just completed over a month of back to back usability testing sessions for different clients along the eastern seaboard. This consecutive approach to cognitive walkthroughs was exhausting. I’m literally sitting on the plane about to pass out–thankful I’ve finally got a day off to relax tomorrow.

As a UX consultant, I often find myself in different offices watching people use software I helped develop. There is so much you can learn by simply watching people. Some are resistant to change, some embrace it, some are computer savvy, and some have limited experience. Regardless, sampling a variety of users is important because it allows you to collect constructive feedback from all different perspectives.

Since I haven’t blogged in a while, I thought I’d share what I’ve “learned and confirmed” in the last five weeks:

• After observing as few as 5 users, you’ve pretty much seen about 80 percent of your usability issues. I’ve experienced this several times before, but when you have an inventory of hundreds of users, it doesn’t take long before things get repetitive.
• You’re not testing the user, you’re testing the system. Things are never their fault. You need to remind your users of this.
• Unless you can do something with what you’ve learned, it’s just information. You need time to reflect and act. Once you’ve spent three days with a particular set of users you are wasting time and money.
• Some users will be brutally honest with you, some will be quiet. There’s also one guy in every office who is a total jerk-face. Don’t let them get in the way of doing your job.
• Your findings will hold a lot more weight if you’re a 3rd party. Remind them you have no role in the development of the software. If you do have a role, don’t tell the user who you work for directly. Just let them know you’re simply there to test the software “Acme Inc.” built. If things go really well, feel free to tell them who you work for after the observation is over. You never want to risk it by revealing who you are.
• If your users needed to reference training or an online help system, you’re not doing a very good job as a designer. There is no such thing as a “training issue” in regards to usability. Did you need training to use popular internet applications such as YouTube, Facebook, or Twitter? Usability issues are just as important as system issues. Document everything. UX design minimizes the need for training.
• You need a control mechanism. A survey should back up your observations. If it doesn’t, you’re not listening hard enough.
• One opinion or frustration does not constitute a design makeover. Look for the trends. Follow the famous 80/20 rule. If most of your users get stuck somewhere, it’s time to rethink your design.
• You’re not there to train, you are a fly on the wall, but don’t let the user get upset. Once you’ve got it document, help them out so you can move on.

Updated June 13th

• Stay off of your blackberry. There is nothing that drives people more crazy than someone who is wasting their time and not even giving them their undivided attention.
• Maximum one observer/per user, period. I’m serious here. There should be one person facilitating a cognitive walkthrough. If you absolutely must have another person, that person should stay quiet and take notes. Risking the user feeling uncomfortable will impact your findings and sway the results (possibly in a negative way).

What a drastic statement! We often forget the products we build are not about technology, engineering, or even design. We write software because it enriches the lives of others and makes the world a better place to live.

If this can’t be accomplished, the tools we build are just lines of code rendered graphically on a computer screen.

While developers fall for this trap on a steady basis, user experience consultants and information architects are supposed to be an advocate for their users—but I’m beginning to observe many of us focusing heavily on our design tools rather than who’s most important, the people we serve.

At the end of the day, our wireframes, personas, style guides, taxonomies, photoshop comps, and site-maps are just communication tools. They serve no purpose unless we communicate them between our customers, stakeholders, and engineers. We have to convince people to adapt to better technology and embrace change.

So why am I writing this blog entry? I’m writing this because I want to offer a gentle reminder to the universe that people always come first. If we’re to be successful in our industry, we need to remember the people we serve. You’re not just “the wireframe guy” or “the photoshop gal”, you’re a very important person that is there to make a difference in the lives of your users.

You have professional responsibility to ensure the best experience for your customer, but I believe you also have a social responsibility (as a citizen of this planet) to build experiences that make peoples lives better. If you can limit someone’s frustration and empower them with technology, you are changing the world. Remember, those who believe they can change the world are the ones that do.

So what are you doing to change the world?

This is something I find common among user interface designers—rules that are so sacred, violation will untwine the threads of society as we know it; crippling the entire internet to a slow and painful end.

This, of course, is simply not true. Breaking a few design best practices does not necessarily mean you’re creating monster about to be unleashed in the city. Design rules are merrly suggestions that—in most cases—facilitate a consistent user experience. Sometimes breaking the rules can even improve user experience.

The other day, I was discussing this with a colleague who was convinced opening new windows (either through a new browser or javascript popup) was one of those rules that should never be broken. There are many reasons behind this and the his reason is it creates an unusual user experience. Opening a new window navigates the user away from what they’re working on and eliminates the use of the browser’s back button (used 80% of the time to navigate websites). Another valid reason is because the use of the HTML anchor attribute [target="_blank"] to open a new window has been deprecated and the W3C recommends not using it.

Although these are completely valid reasons, it doesn’t mean there are never reasons to break this rule. He asked me to give a real life example. I told him you can open a new window if opening in a current window interrupts a task that a user is working on. More specifically, one client of mine needed a chat support feature that could be used while the visitor browsed their website. This feature provided a reasonable change in experience and it actually increased sales and improved customer service.

The danger of being completely controlled and dictated by design rules is it undermines the very reason user experience is so effective—it helps get past process and predetermined notions to effectively meet the needs of your users. Also, sometimes you have to loose battles in favor of improving experiences elsewhere and make your customer happy. Anytime it gets in the way of building the best product—that’s when you know breaking the rules is okay.