User centered design, HCI, Interaction Design, User experience

2012-01-19T23:03:00.001-08:00

Portfolio

2011-09-14T22:35:00.000-07:00

Emotional Behavioral Response Relationship

Let’s start with the basics: an emotion is a psychophysiological response in your body to a stimulus. It’s an internal process that in turn triggers an external behavioral response. Behavioral responses help you decipher the emotional responses of others. Things like facial expressions and body language give you clues to whether the chef wielding the knife is angry and going to attack you or happy and going to make you dinner.

But you don’t have to be face to face in order to read a person’s behavioral clues. In digital environments, users’ behavioral interactions with the platform can give you insight into their emotional states. Instead of reading facial cues to analyze how your UX efforts affect users, you can measure their responses via metric data. Metric data is a user’s behavioral response quantified. With a little reverse engineering, you can identify strong emotional triggers, optimize weak elements and create stronger user experience strategies, using psychology as your secret weapon.

User experience doesn’t start when they hit your landing page or start your app, but prior to it. Visitors have to make their way to your website in the first place. They’re navigating through websites full of frustration-inducing elements, trust-busting perils and anticipation-inducing amusements. The focus at this point is on building trust, anticipation and whatever other emotional responses you’ll target in your copy, imagery and overall storytelling.

Track awareness-level engagement using metrics like page views, page hits, video views, impressions and click-through rates.
Identify emotional image and copy triggers during the development phase by A/B testing on micro-sites, as well as using ad content and email campaigns.
Create dynamic content that spotlights your SEM, SEO and advertising goals, giving users exactly what they want as soon as they hit your page.
Leverage strong referral sources and advertising platforms to build trust and credibility. The coffee vendors featured in the screenshot above use Google, and the companies featured to the right of this column you’re reading use Smashing Magazine to reach customers. By aligning their messages with these brands, they are able to build more trust in the user than an ad on a less relevant platform (like Craigslist) might have.
Use emotionally rich imagery in your advertising messages, and carry that messaging through to the website itself. “Fresh-roasted coffee” begins to paint an emotional picture for the user of that perfectly roasted cup of steaming delight first thing in the morning. If your click-through rate is low, then your ad may not be compelling enough.
Develop intuitive and relevant architecture to decrease frustration and increase trust. First impressions count. If the bounce rate is high or the time on site is low, then the story you are telling in the awareness phase might not be carrying though to the user’s interaction on the platform.

Attraction-level engagement keeps users interested in your platform. Cohesion of the UX elements and usability is the name of the game. Building emotional engagement at this level is critical because behavioral engagement consists mainly of superficial interaction such as navigation and content absorption.

Track attraction-level engagement by looking at bounce rates, session lengths, pages per visit, abandonment rates, email opening rates and click-through rates.
Stay up to date on current trends in usability to create systems that are user-centric.
Identify high-focus areas in your user interface through eye-tracking, heat maps and software that records mouse movement. Optimize your framework, and place emotion-building content in strategic areas.
Continue building and reinforcing motivational and emotional triggers through engaging imagery, emotionally charged words for headings and main copy, and persuasive triggers. @Mailchimp publicizes a lot of “free”, “big” offers and uses bright imagery to boost joy and anticipation levels. Negative emotions, like sadness, can also build strong emotional engagement in users. Examples are the powerful images of animal cruelty often seen in PETA and ASPCA campaigns.
Highlight brand relationships, security measures, press and endorsements. Aligning your product with other respected brands builds trust. The list of brands that Mailchimp uses to show its press features builds an impressive amount of credibility. This is immediately followed by the call to subscribe by email. Putting the call to action after the trust-building credentials is more effective than the other way around.
Develop proper system-generated feedback and error handling. This could include loading notices and 404 pages with content referrals, which reduce abandonment due to user frustration.

Adoption entails users accepting the website structure as a common platform for interaction or knowledge on a subject. Emotional engagement is extremely high, and interaction is consistent. If investment-level engagement gets users involved, then adoption-level engagement makes them your cheerleaders.

Adoption-level engagement can be seen in return customers, unique versus returning visitor ratios, geo-location check-ins, and participation in “karma” systems (badges, etc.), to name a few.
Use strong social interfaces to spotlight followers, supporters and die-hard addicts.
Put community-building messaging in your copy. “Colbert Nation,” “Psychos,” “Gleeks” and “Chipotle for Life” are elements that brands use to add excitement and enthusiasm to their products and reinforce the emotional engagement of their communities.
Make it easy for users to integrate the product into their daily lives, as Foursquare, Facebook and Twitter do via apps and open APIs.
Invite fans to help shape your future, and make it easy for them to share information, spread your brand and recruit their network.
Let users play. It’s just a burrito wrapped in foil, but builds an addictive community element into its website by combining joy, trust and anticipation with quick, simple interactive elements.

2011-09-12T23:47:00.001-07:00

THE CUSTOMER EXPERIENCE

UX Of Long-Term Relationships

Initially, all markets compete on price. However, competing on price simply isn’t relevant with Web apps, because they are all in the same $0 to $99 per month bracket. Think about it: what sane person would switch project management tools just to shave ten bucks off their monthly costs?

We have reached the point where the service part of SaaS is most relevant, the point where the experience your customers have with your company will determine whether they stick or switch. Say you’ve been paying $50 a month for your time-tracker for the last three years. Have you enjoyed the service? Have you ever been personally thanked for your loyalty? Do you feel that the provider values your $1,800?

Customers Who Don’t Feel Valued Leave

The Rockefeller Corporation studied why customers leave one company for a competitor and found the following:

Look at what’s not here. No mention of price or quality. How you make customers feel is what drives their loyalty, and it’s here where website owners are in trouble. Website owners are disconnected from their customers, save for a conference party or survey each year. If you asked them to introduce you to 10 of their customers, most would struggle, grimace and then get a developer to break out the SQL. Imagine trying to run a bar, convenience store, hair salon — heck, any service — with that level of apathy towards the folks who pay your wages. It shouldn’t be surprising that your customers are willing to jump ship the second a competitor launches a sexy iPhone app. If you’ve never cared about your customers, why would they care about you?

Warren Buffett talks about building a moat around your business to make it untouchable. The strongest moat you can build is one based on strong relationships. Low prices can always be beaten. Stunning design ages quickly and can easily be copied. Impeccable uptime can be matched, and your features copied. However, a good customer relationship is unique, and loyal customers are hard to steal.

Wireframes and mock-ups are excellent for figuring out and discussing screen layout. You can follow all therules of wireframing to create a compelling user experience, but you can’t wireframe how a customer feels after 15 months of using your software. To deliver a compelling experience, you need to also consider “touchpoints” and “timepoints.”

Touchpoints Make It Holistic

Touchpoint diagrams help you see the various ways in which customers come into contact with your software. The diagram above from a holiday home website shows that the mobile experience is bad for non-iPhone customers, and that email and phone support should be improved. An amazing website is of no use if your call-center staff is rude or your developer is a jerk to customers on Twitter. Great experiences are about getting everything right; it goes well beyond fancy sign-up forms, cute mails and game-ified tutorials. Sure, all those things help, but the customer experience has to be comprehensive.Quality is fractal. Your customers will judge your company based on all of the experiences they have with it, not just those dripping with CSS3 effects. Using a touchpoint matrix such as the one above will help ensure that you’re considering all of the experiences your customers will have.

Timepoints Make It Long Term

Anyone who has relied on metrics for customer acquisition will be familiar with some variant of the funnel above. We start with a lot of visitors, and convert a small few of them into customers. While this scenario is rather contrived and rosy, it does provide a way to measure different parts of your Web app. It does not, however, look at what happens next. If you ignore your paying customers, and they hear from you only through their invoices, then you can expect the relationship to deteriorate over time. Here’s how that goes:

We need it to go more like this:

Improving Your Customer Experience

Achieving this requires that you put a plan in place and put someone in charge of customer communication. There is no universal method that works for all software; it’s an iterative process. Your customers need just enough personal communication to feel valued, while not feeling like they’re being nagged constantly. As a start, I’ve prepared the simple questions below; someone on your team should be able to answer yes to all of them.

Test Your Relationships

Do you greet new members, introduce yourself and let them know that they can contact you at any time?
Do you check in with them after they’re settled in to see how they’re doing and to see whether they’re making the most of your app?
Do you talk to your users about new features before and after implementing them?
Do you send them the right types of messages at the right time?
Do you check in with your customers after their first year to thank them for their loyalty?
Can you easily tell the difference between your most loyal customers and yesterday’s sign-ups?
Can you tailor your communications to different types of users?
Can you name 20 of your customers and tell me something about them?

There is no shortage of questions you could add to this, but I find this initial set is enough to distinguish those who genuinely care about their customers.

Cut The Excuses

There are plenty of reasons why one might believe that this change is too hard to make. App owners will argue that their time is better spent adding features and fixing bugs. This is only partially true. Your customers are with you now without those planned features and with those bugs. I’m not arguing that you should ignore these tasks, just that those tasks are not the only important ones. Recall why customers leave: it’s not likely just because your competitor has launched an iPhone app. That’s one straw, but the camel’s back is already overloaded.

What If I Don’t Have Time?

Do you not have time to invest in keeping customers happy? The rule of retention is that you must be willing to spend as much to keep a customer as you did to acquire them. Leaky buckets don’t fill up quickly. Software such as Intercom makes this degree of customer insight and communication far more manageable.

Intercom is the first of a new wave of tools aimed at enabling Web app and website owners to get to know their customers.

Too Much Feedback?

No one can afford to ignore their customers. This doesn’t mean that you must do everything they say; it means you should listen and respond. Too much feedback is a good problem to have. Rather your customers tell you what’s on their mind than silently disengage, forgetting about you until their credit-card bill arrives. By that point, you’re already history.

Delivering Customer Experiences

For one year straight, I spent one day every week speaking with customers of one of our apps. Before I started this, they were simply rows in a database. By the time I was finished, I had had a conversation with over a thousand people. I heard about what we got right, what needed improvement, and why we were losing customers. Very useful stuff.

Users were delighted to hear from us, because it reminded them that we’re more than a set of pages and a monthly debit. We started a customer blog and featured a few customers each week. We also added their logos to our home page. To customers, this is the business equivalent of being taken home to meet the parents. It shows a real personal commitment. These actions persuaded our customers to give honest regular feedback and to let us know when we disappointed them. We’d rather they say it to us than run into the open arms of a competitor.

Wufoo sent all of its customers Christmas cards in its first year. That was a huge hit. It was hardly surprising that by the following year they had too many customers to do it again. As a start-up, you have to play to your strengths. A small customer base offers you a big opportunity to deliver amazing service. Scaling that experience can be tricky. There is software that will help, but, again, solving this is no small challenge.

2011-09-05T02:57:00.000-07:00

Where did Agile come from?

Envisioned by a group of developers, Agile is an iterative development approach that takes small steps toward defining a product or service. At the end of each step, we have something built that we could release to the market if we choose to and therefore it can assure some speed to market where waterfall methods usually fail. Agile prefers to work out how to build something as we go, rather than do a waterfall style deep dive into specification and then finding out we can’t build parts of the spec for some reason e.g. a misjudgment of feasibility, misjudgment of time to build, or changing requirements.
A group of developers such as Kent Beck, Martin Fowler and Ken Schwaber got together to come up with a way to synthesize what they had discovered was the most effective ways to develop software – The Agile Alliance was born. It released a manifesto2 to describe its tenets and how it differs from waterfall methods.

Agile can be thought of as a risk-management strategy. Often developers are approached directly by a client who does not know what a user experience designer, information architect or user interface designer is. Roles such as these usually interpret what clients want and translate it to some kind of specification for developers. Without this role, it’s down to the developer to work out and build what the customer wants. Because Agile requires a lot of engagement with the client (i.e. at the end of every iteration, which can be as little as a week) it mitigates the risk of going too far toward creating something the client doesn’t want. As such, it is a coping mechanism for a client’s shifting requirements during development as they begin to articulate what they want. To quote the Agile Manifesto’s principles “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Why do people rave about it?

At the heart of what makes Agile attractive is the possibility of quicker return on investment for development effort, because we can release software earlier than we would have otherwise. In the short term, this is typically borne out. In the long term it can be too, though only when the team hasn’t fallen victim to temptation (more on that later). Agile is also good at generating momentum because the iterations act as a drumbeat to which the team marches toward manageable deadlines. The regular "push" to finish a sprint ensures that things move along swiftly. Agile is also good at avoiding feature bloat by encouraging developers to do only what is necessary to meet requirements.
Because it emphasizes face to face contact for a multidisciplinary team, Agile tends to encourage contribution from different perspectives. This is generally a positive influence on, pragmatism, innovation and speed of issue resolution. The team is empowered to make decisions as to how requirements should best be met.

The Minefield

In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.

Mine 1: An unclear role for design

In the best cases of business approaching developers to build some software, some of those developers may have design skills. But that’s not a particularly common scenario. Many developers have also had bad experiences with designers who don’t know what they’re doing. It took a long time for the design profession to come to grips with designing for complex systems and there is still a deficit of expertise in this field. “Business people and developers must work together daily throughout the project” is another principle of Agile. Where does the designer fit into the frame?

Mine 2: The requirements gathering process is not defined

Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.

According to Ken Schwaber, SCRUM intends to be a holistic management methodology and leaves space for activities other than programming to occur within the framework of iterative cycles. But when organizations adopt SCRUM, too often the good parts of a waterfall process like research and forming a high-level blueprint for the overall design become the proverbial baby thrown out with the documentation bathwater. As the Agile Manifesto says, “Working software over comprehensive documentation.”2 Many latch onto this and don’t want to do any type of documentation that might outline a vision, even if in a rudimentary sense.

Mine 3: Pressure to cut corners

Implementations of Agile that put design activities within the same iteration as they must be developed, ensure designs are achievable in code. But they also put tremendous pressure on the experience design team to ‘feed the development machine’ in time enough for them to implement their vision. This can and does lead to impulsive design. So, what’s wrong with that? Well, nothing if you’re not adhering to user centric principles which suggest you should test ideas with end users before committing them to code.
Some assert that there are plenty of examples of best-practice interfaces to copy out there. So, why reinvent the wheel? Surely we can save time that way? Sometimes they’re right, but how will we know which best-practice interface works best in context with the user’s goals, with no time to test with the user? How can we innovate by copying what already exists? Before Google reinvented internet search, other search engines assumed a status quo which behooved the user to learn how to form proper search queries. It was institutional knowledge among the other search engines that this is how searching was done and customers simply had to learn to use it. Most people’s search results were poor at best. Then Google came along and realized what is now obvious. People just want to find what they’re looking for, not learn how to drive a search engine first. I’m not suggesting the other search engines could not have done what Google did sooner, but I am pointing the finger at a mentality which meant they missed the opportunity. Interestingly, Google is not known for its designers. It’s mainly a development house, but lots of those developers can clearly put a design hat on too.

There is absolutely nothing wrong with using Agile to produce results quickly; that is, if you don’t intend to release them on your poor, unsuspecting user without some usability testing. Just don’t be fooled that this is going to save you a lot of time if you want your new product to be right, because you will have to iterate to arrive at an appropriate solution. Alan Cooper has argued that this creates a kind of ‘scar tissue’ where code that has to be changed or modified leaves a ‘scar’ that makes the foundations of the program unsound.4

Mine 4: The temptation to call it “good enough”

Invariably when we have release-ready working code at the end of each cycle, even if it’s sub-optimal, there’s a strong temptation to release it because we can. Agile condones releasing whatever we have so long as it works. Sometimes, that means doing what we can get away with, not what is ultimately best for the user. Equally, if we do decide that a feature isn’t right yet, it’s amendments get fed back into the requirements backlog where temptation strikes again. Should we spend time in our next iteration on a feature that we’ve already got a version of? Or shall we develop something new instead? Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.

Mine 5: Insufficient risk-free conceptual exploration time

Iteration “zero” (i.e. a planning and design iteration prior to the first development iteration) can be used to do this and other planning activities. However, depending on how long this iteration is, the level of rigor applied to exploration may be insufficient. An argument used by some Agile practitioners asserts that a working example of a solution is the best way to validate whether it is the right one through exposure to the market. This ‘suck it and see’ approach bypasses an activity called “concepting.” Concept activities dedicate time to sketching different solutions at a high level and validating them in the rough with users before digging into detailed design or code. “Suck it and see” would have us just build it, launch it and see if it flies. This way, we’ve wasted time building something we will probably have to take apart or rebuild. The counter argument is: if it took as long to build as it would have to research and design before laying a line of code, then we break even. This statement is a stretch in practice because development itself usually does take longer than well-managed design research and conceptual exploration. Also, there has to be some level of design regardless of which methodology is used, and this adds days to the timeline.

Mine 6: Brand Damage

Let’s just say that design and research takes the same amount of time as development for argument’s sake. In the worst case, we completely miss the mark with the non-researched and designed solution and we have to start all over again. Then we’re back to the same total duration after developing it a second time, but there’s no guarantee we’ll get the solution right the second time either. All the while we’ve repeatedly foisted a botched product design on our users and adversely affected our brand. Many companies succeed on the back of their reputation for producing consistently appropriate products and services. When a company releases a flawed product or service, then their image in the customers mind (i.e. brand) is tarnished. Brand damage takes far longer to mend than it does to make. Software creators that fall victim to the temptation of "good enough" and fail to innovate through conceptual exploration put their companies revenues at risk. In a competitive market, repeated failure to meet user needs well leads to serious brand and subsequently financial repercussions, as other companies who do get it right take the business.

Agile is good for refining, not defining.

If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.
But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.

User Centered Design

UCD requires iteration – design, test with users, refine, test with users again, refine… repeat till it’s right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming you’ll need to change things, and that’s a good thing when it comes to refinement.

Uncovering requirements to form a strategy

User Centered Design (UCD) is not about answering requirements alone, but also includes defining requirements. When we practice UCD end-to-end, we pretend we know little. Little about what the solution to a problem should be; little about what the problem actually is because assumptions close us off to new possibilities. We prefer to allow some design research to create a viewpoint and then form a hypothesis as to what we might build. In this regard, we cross into the realm of product managers, producers, program managers, business analysts and the like, trampling toes with gay abandon and meeting resistance all around. Facing confinement to defining the boring old business need (distinct from the user or customer need), these folks would prefer we constrain our UCD work to usability testing on designs meeting the requirements they set out. They’d prefer we stick to just helping with development… and if we can do that quicker using Agile? Wahey!

Is it always appropriate to do extensive research before starting design? That’s a good question and one that Jared Spool’s Market Maturity Framework5 helps answer. Sometimes, just getting something off the ground, regardless of how precisely we meet user’s needs with it is all we can afford to do. Once we graduate out of this "Raw Iron" stage into "Checklist Battles" focused on getting the right features and then beyond, research is a core ingredient to putting our feet in the right place.
After researching what the user and business requires, we can make the “Strategy” tier of Jesse James Garret’s Elements of User Experience3which underpins everything we do during the project. Do this well, and you really shouldn’t come up with something that’s fundamentally wrong. Agile doesn’t account for this beyond a planning phase (i.e. iteration zero), which may well define a strategy of sorts. But does it really define the correct strategy? Surely, that’s created through careful consideration of three things:
Empathetic qualitative research that uncovers the user’s context, needs, goals and attitudes i.e. user requirements. Cooper suggests that the customer doesn’t know what they want and advocates a role of interaction designer as requirements planner.4 This would avert building to the wrong requirements in the first place, but the time to do this must come into the development lifecycle somewhere. It involves talking to users, preferably visiting with them in their environments to create experience models and user personas.
A thorough appreciation of what else in the big wide world exists in terms of products, features and technology that can be emulated somehow (not necessarily addressing a similar situation to ours).
A clear articulation of the business problem, objectives, success measures and constraints. Business people sat in a room discussing what they think should be done must be informed by all these things if the right strategy is to emerge. Agile doesn’t preclude that kind of consideration, but it does not mandate it either.

Concept Development
If we manage to built something usable and reasonably intuitive without research or strategy, did we succeed? Most MP3 players fit this bill but none took off like the Apple iPod. Leaving interface usability aside, the iPod had a service concept behind it which included digitizing, replenishing and managing your entire music library with iTunes. This was part of the iPod concept from the outset and in combination with good marketing and design, continues to eclipse the competition over seven years later. But that concept needed to be sketched and iterated at some point. If we don’t explicitly build this into our Agile methodology, we can miss that thinking time.

The best of both worlds

UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go.

A shared vision of the interaction fundamentals
In good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms, i.e. not each and every navigation label, task or tool but rather the interface and interaction patterns that will persist. This produces something rudimentary to test with users to see if we got the big picture right. Following this roadmap sketched on the back of research and concepting prior to development activity, ensures consistency and cohesiveness when each component is coded separately to each other later. In many cases, the concept will need iterating to accommodate lessons from the journey. But we’ll at least have some indication of direction at a macro scale. Then, when in the midst of Agile iterations working out the details alongside our developer brethren, a level of expertise and experience is required of the designer because what we design will be built before we’ve had a chance to second-guess ourselves. Domain knowledge and an understanding of interface paradigms that work is also a big help. But to build new projects from scratch without a shared vision is a mistake.
Risky interfaces that are new or significant improvements on what has been seen before, are best tackled as design-only activities in a sprint prior to when they will be developed (i.e. do involve developers, don’t try to produce code). This circumvents the pressure to deliver something before proper thought, reflection and user testing, which ensures you’re not wasting time and effort. Sometimes most of the product will be done this way and that’s fine so long as developers and designers are still working together and talking every day. The first development iterations are an important time for the developers to lay the architectural foundations based on the vision. Designers should use this time to get a jump on any high-priority tricky interfaces so the development team isn’t waiting for something meaty to start on when it comes time to build features.

Most important to success, the business needs to accept that some things won’t be right the first time around and commit to iterating them prior to release i.e. not be led into the temptation to release something that’s not right yet.

USER-CENTERED DESIGN PROCESS

2011-09-05T02:28:00.000-07:00

user-centered design process has three major phases of the work – analysis, design and evaluation - with iterations that cycle between each phase.User-Centered Interaction Design. This framework allows specific methodologies to be formulated to meet different product development or organizational needs.

The six stages are:

Envision
Analyze
Design
Evaluate and Refine
Implement
Support
Each of these stages, fits together into a project plan that covers the complete life-cycle of a project. The stages may iterate, but both within an iteration and for the overall project, the deliverables from one stage are the input for the next. In addition, assumptions about users and usability requirements are continually tested during the entire life-cycle.

Envision

The work of envisioning the product to be created may be the single most important activity for the success of the product. It is often overlooked, or done incompletely, leaving gaps in the understanding of the scope, concept and function.

Ideally, this work is done with all of the stakeholders, including marketing, product development, design, support, training and product management. As each team begins to work, it is critical that there be a clearly enunciated, shared vision.

The envision activities end with the creation and approval of a Vision Statement which defines the product concept, target users, usability goals and early requirements as well as any technical or market constraints and key functionality.

Analyze

Analysis activities include all user and task analysis as well as coordination with business requirements analysis.

In some projects, the analysis activities are completed before any design is begun. However, in projects using a phased or iterative application development methodology, the analysis, design and evaluate activities are repeated for each phase. Typically, the first round of analysis covers high-level issues such as building an interaction model that matches the user’s mental model, while later rounds focus on detailed task analysis for specific functions.

Design

The design phase is one of the most iterative. It begins with a simple key screen prototype and continues until all critical design decisions are made.

Typically, this progression of prototypes builds from a main menu or home page and sample work pages to include the design outline or style guide for all screens to support the product functionality.

User feedback is collected through rapid, informal usability techniques on each iteration of the design. This ensures that the design matches users’ mental models and meets usability goals before complete detailed design is begun.

Evaluate and Refine

At key milestones, user evaluation is critical to ensure that the product will meet user needs. These evaluations give the design team an opportunity to test their assumptions and the emerging design.

It can be difficult to create a project plan that includes a final revision phase at the end of each activity, but leaving time for refining the design based on the results of evaluations is critical.

Implement

The implementation activities include the creation of detailed designs and accompanying specifications for the developers as well as monitoring the development process to solve any problems which are found.

The degree of formality during these activities depends on the structure of the team and, in part, the scope of the project. Without clear communications during implementation, the process can become chaotic, wasting time and energy.

Support

During the design process, users have supported the activities with their participation and input. Successful rollout of the product requires attention to how users will be supported. Planning the release, installation, awareness or training programs and initial support should be part of the project from the beginning.

In some cases, the designers may work with the technical support group to anticipate problems, or to plan ways of collecting usability information during support calls. Other ways of collecting information about the success of the rollout include user satisfaction surveys some time after release, follow-up site visits and focus groups.

All of these activities help the designers learn what techniques worked well, and which should be changed or improved in a future project.

IMPLEMENTING USABILITY IN YOUR PROCESS

New usability practitioners are often surprised to find that the rest of their development team does not share their enthusiasm. They can be met with outright rejection or more subtle resistance. One solution is to apply user-centered design to the process of introducing usability.

Looking at the entire product development and support group as the "users" of a new process provides some useful guidelines and insight. The LUCID framework can be applied to designing a process as well as designing a user interface.

Envision the End Result

Rather than simply diving into usability activities that sound interesting, take the time to create a shared vision of the result of implementing a new process. This includes a lot of "homework" but is an opportunity to explore the development process in some detail.

Document the business benefits of usability and how it can support the company’s strategic objectives.
Take the time to learn what those objectives are and think carefully about how user-centered design can help meet corporate goals. A company in the midst of a cost-cutting effort will be more responsive to plans for site visits if they are shown how a better understanding of users and their requirements can avoid costly rework late in the development cycle.
Determine who must approve usability activities.
In some companies, access to customers is carefully guarded by a marketing or field service department. In others, all requirements analysis is done by a central group. Depending on the structure of the organization, usability activities may all fall under a single department or may impact many groups, each of which must approve them.
Explore how usability will change the development process.
If there is a well-established application development process in place, any usability activities must fit into it. In some situations, there may be no formal methodology or new activities will have little impact on the existing process for developers. It is important to identify who will be affected by any changes in the process which are proposed.
Identify the most important problems usability can solve.
Sometimes the problems which are currently bedeviling a product group are exactly the ones which usability can help solve. In cases like this, it is easier to make a case for a process which offers a systematic solution.
In other cases, learning what problems need solutions might change ideas about the first activities to be introduced. In either case, the goals for the user-centered design process become part of the general goals of the company or product group.

Analyze Your Environment

Any user-centered design process requires user analysis and the process of implementing a process is no exception. Whether the change will be a momentous one, or a small refinement of a mature process, it will force people to change how they work. It is important to know who will be affected, and what their goals and requirements are.

Identify the stakeholders in the current process.
No matter how informal the current development process, there are stakeholders in the status quo. They may be the product managers, business analysts, individual developers or even another department such as the marketing, training or quality group. Find out who they are. Spend the time to learn how they will be affected by any new process.
Observe and interview people who will be part of the new process.
This may be done informally, or may be as formal as any site visits or subject matter expert interviews. Along with the basic fact finding, there are three questions which can be very helpful in deciding how to design and implement a user-centered process:
How do people on development teams interact and communicate? They may work in tight, cross-functional teams or primarily interact with their skills peers. Large projects may use formal (and long) documents to communicate between groups, while smaller rapid-iteration teams may have little written documentation, relying on information communicated in shared meetings.
What needs are not currently being met? Look for information which is not communicated well, or is missing entirely. In an environment which is not user-focused, this may be exactly the information which user analysis can provide.
What works well that can be leveraged? There may be informal procedures or techniques that can be borrowed, with the benefit of having already been ‘tested.’
Design (and Prototype) the Process

Rarely can a process or methodology be imported wholesale into a new environment. Take the time to design it to take advantage of the user analysis, making the connections explicit. Making decisions traceable to identified user requirements is just as powerful in a process design as in an interface design.

Plan the process
The plan must answer questions about both immediate and long term impact: what will the process look like when completely implemented; and how will it be introduced. In defining the usability activities which will be introduced first, the plan should include an assessment of how they will affect the current process. Can they, for example, be done in parallel with other work or will they add days to the schedule.
What usability activities will help solve problems and meet goals.
For each activity selected for initial implementation, the deliverables must be defined and there must be a clear statement of how they will help solve problems in the current process. If others will have to act on the information provided by an activity, the nature and scope of that response must be outlined.
Select a few key activities to pilot.
Don’t be too ambitious. Look for clearly defined problems with medium visibility and use them to test the effectiveness of user-centered design activities. The problems should be clearly defined so that success in solving them can be measured easily. Many products have intractable and difficult problems. Leave them for later, and take on something more manageable at first. If a problem has too little visibility in the company, no one may care if it is solved; too high visibility and the new process is forced into the spotlight too early.
Evaluate and Refine the Process

Few things are done perfectly on the first try. Plan for feedback and refinement as part of the normal course of action. That way, any problems or setbacks are not disasters that can derail the process, but part of an expected period of adjustment. Although much of the focus may be on the success of the activities themselves, use this evaluation period to make sure the process is working as you envisioned.

Are usability activities meeting expectations?
This is a good opportunity to be sure that the expectations of the rest of the product team, and management, are being met or exceeded. They may have seen usability as a ‘magic bullet’ which would solve all design problems with one site visit. Or, the activities may not have produced the results you expected. If this is the case, the plan may need to be changed or expectations adjusted.
Are you successful in communicating results?
Find out if the information is reaching the right people. Are user analysis materials being read? Are insights being shared? Communicating learning is as important as the learning itself.
Is new information about users having an impact on design?
The ultimate test of a user-centered design process is the effect it has on the product. Have there been any design changes – or even breakthroughs – as a result of this work? If so, think about how to expand these results. If not, why not?

Build on Successes

Moving from a pilot to full implementation can be difficult. The emphasis of the process shifts from the isolated tactical projects which needs only one sponsor to winning company-wide sponsorships. One of the biggest mistakes is to assume that one successful pilot can be automatically turned into a new approach. Even if the success of the initial project is obvious and universally acknowledged, it takes work to build it into a standard procedure.

Expand successful activities to include more projects and more people.
It is not enough to simply repeat the activities with the same group. Expand in two directions: train more people to use successfully piloted activities in their process; and pilot more activities, broadening the repertoire.
Find ways to make usability a "way of life."
This is the time to build the processes and procedures officially. If there is already an application development process or quality cycle in place, the political work of adding usability to that process begins. No matter how formal the process, be sure that usability activities are part of every project plan – from the beginning.
Solicit feedback from users of the process.
Continue evaluations with users looking for places for improvement. Spend the time to respond to their feedback, whether it is positive or negative. Ignoring any difficulties simply sweeps the problem out of sight, so take the time to work with anyone having problems to understand the issues, find solutions and create an ally.
Support Usability During the Rollout

Designers and technical communicators can be too modest. Accustomed to working quietly on their projects, they fail to share their successes. Be sure to:

Evangelize shamelessly.
Share techniques and success stories. Write articles in corporate publications. Present at conferences and publish in industry journals.
Share information from usability deliverables.
Be specific about what was learned and how it helped. Show how usability activities brought new insights, changed designs, sped up the development process. Good stories about users can become part of the corporate lore, building a customer-focus. Simple, quotable facts or anecdotes help people remember usability and its impact.
Look for evidence of success.
The real test of usability’s success is in improved customer satisfaction, increased sales, better performance numbers and other tangible metrics. Find out who tracks these elements, and work with them to find cases where usability played an important role.
Find allies.
Build relationships with other departments such as marketing, field service, training and technical support. They are the eyes and ears of the company, in touch with users on a regular basis. Work with them to find improvements (and help them get credit for finding any problems that usability can fix).

User-centered design (UCD)

2011-09-05T02:25:00.000-07:00

User-centered design (UCD) is a design philosophy and a process in which the needs, wants, and limitations of end users of a product are given extensive attention at each stage of the design process. User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to use a product, but also to test the validity of their assumptions with regards to user behaviour in real world tests with actual users. Such testing is necessary as it is often very difficult for the designers of a product to understand intuitively what a first-time user of their design experiences, and what each user's learning curve may look like.
The difference from other product design philosophies is that user-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product.

Human computer interaction (HCI)

2011-09-05T02:16:00.000-07:00

Human–computer interaction (HCI) is the study, planning and design of the interaction between people (users) and computers. It is often regarded as the intersection of computer science, behavioral sciences, design and several other fields of study. Interaction between users and computers occurs at the user interface or simply interface, which includes both software and hardware; for example, characters or objects displayed by software on a personal computer's monitor, input received from users via hardware peripherals such as keyboards and mice, and other user interactions with large-scale computerized systems such as aircraft and power plants. The Association for Computing Machinery defines human-computer interaction as a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them. An important facet of HCI is the securing of user satisfaction.
Because human-computer interaction studies a human and a machine in conjunction, it draws from supporting knowledge on both the machine and the human side. On the machine side, techniques in computer graphics, operating systems, programming languages, and development environments are relevant. On the human side, communication theory, graphic and industrial design disciplines, linguistics, social sciences, cognitive psychology, and human factors such as computer user satisfaction are relevant. Engineering and design methods are also relevant. Due to the multidisciplinary nature of HCI, people with different backgrounds contribute to its success. HCI is also sometimes referred to as man–machine interaction (MMI) or computer–human interaction (CHI).
Attention to human-machine interaction is important, because poorly designed human-machine interfaces can lead to many unexpected problems.