4: Capture What Customers Want in the User Experience
Successful user experience is ultimately measured according to meeting the demands and expectations of the user. Where the experience is more difficult than users expect it should be, they seek a simpler solution.
(EN: the opposite extreme is seldom mentioned: is it possible for a UX to be "too easy"? I have seen arguments, backed by various research, on both sides. Some suggest that easier-than-expected serves to impress and delight users; others suggest that users are suspicious and uncertain when something was easier than expected. My sense is that it largely depends on the task and user in question.)
Usability, like trust, is also a core requirement for successful operations. If the user cannot successfully complete the task, the value of the site is utterly negated. If it's technically possible to complete the task, but too difficult for the user to do so, this is no different. And even if the user is able to complete the task with some difficulty, he may seek an easier solution to his needs in future.
Usability is also subjective and based on the user's level of knowledge and experience. An example is given from a financial services firm that found that many customers were unable to use their site because the interactions were too complex and required specialized knowledge about investing. Seasoned investors (like the business team who developed the specifications for the site) had no problem - but most users are not seasoned investors.
(EN: Note that "usability" is often discussed in terms of the online channel, and I expect this to be the author's focus as well, but it is germane to all interactions in all channels. Users will even abandon a business if their experience in the brick-and-mortar channel is frustrating and difficult.)
The author bullets a handful of challenges to usability:
- Technology tends to guide design toward a single, homogeneous experience that is efficient for the system, but difficult for the human user.
- The marketing and IT departments have differing agendas and employee different metrics to measure success - neither of which have to do with the user's notion of success
- The user is assumed to be knowledgeable, task-focused, and single minded
In all, the core reason for failure is that user experience is not considered from the perspective of the actual user - such as he is.
Why User Experiences Fail
The author reiterates the notion that success requires a site to address both the goals of the user and the goals of the operator. The latter is almost always implicit in a project: the company knows what it wants to achieve, and is motivated by its own desires.
Examples are provided of more granular problems: a marketing manager who falls in love with an idea or a drawing; the programming staff resist making changes to their existing systems; an executive expects that users have the same motivation and skills as himself; the designer is excited about using a new technology or technique; and a project manager wants to constrain time and budget to make the project more efficient. (EN: the author expresses these as evidence of the challenge of multidisciplinary teams, but I fear she reduces people to stereotypes - such obstacles can and do come from anywhere.)
UX can also fail when firms do not know enough about their customers and proceed on mistaken assumptions. Knowledge and skills are an area of particular concern - firms assume that customers approach the task with a high level of subject matter expertise. They also tend to assume that the customer understands and is already motivated to perform the task that the system enables.
It's also implied that firms expect customers to do too much in the online medium - people want to do it online simply because it can be done online, and that the online channel must be more efficient for the customer because it's more efficient for the business. The example of car buying is used as the perfect example: because it is a high-dollar decision, people will use the internet to do fairly extensive research, but will still go to a physical dealership to close the deal.
(EN: having recently been involved in a project that put car buying services online, and seen the success it has had, I can't agree that this is a perfect example, and I expect an increasing number of people to continue to turn to the medium. Even so, the point is well taken, as there will always be some people who are unwilling to trust the medium for some purchases - to dismiss them as luddites is to dismiss them as customers - but perhaps there are better examples.)
Capture Customers' Expectations
The answer to common usability issues is straightforward: ask the user. Invest in customer research early in the process, before development begins, and test concepts extensively with actual users to identify and correct problems.
Most companies settle on collecting feedback after a project has been rushed to production. The feedback comes too late, and too few companies are motivated to act upon it. It's also noted that feedback can be ambiguous, or easily misinterpreted.
Unfortunately, the research process is time-consuming and expensive, and many companies attempt to shortcut or skip this step. They do so to their own detriment: user adoption is a critical factor, and falling short means less of a return on the development investment or the complete failure of the project.
Ubiquitous, Transactional Experiences Will Demand Even More Customer-Centric Design
As channels evolve, customer-centric design remains important to determine whether a given transaction is suitable to a new medium. The present assumption is that the mobile channel will replace the Internet, but it is likely that there are a number of actions that a user might undertake in one channel that will be unacceptable in another.
In this regard, prototype testing is key. If you ask an enthusiastic cell phone owner if he would like to be able to perform a given task on his phone, the answer will likely be "yes." If you allow him to interact with a prototype, he may find that the same task is less comfortable in the separate channel, and ultimately, accommodating an awkward experience for the same of providing functionality can be more damaging.
An interesting bit: a quote that suggests that users might even be willing to pay for services that grant them sufficient convenience on their mobile devices. (EN: interesting because the current proliferation of cell phone "apps" for which users pay - and while many companies provide free applications, their customers have shown a willingness to pay a small amount for third-party applications that do the same things in a more user-friendly way.)
Ultimately, the device is only the means to an end. If users want to do something at a specific time or in a specific environment, a device that empowers them to do so will be welcomed. The act of inventing a device or application does not create this demand.
Planning the User-Experience Strategy
User experience should be considered beyond the scope of an imminent development project, as a given application is only one way in which the individual interacts with the business. A broader view, of the way in which the customer interacts with the firm in all media, for all transactions, is essential to ensuring that the present project "fits" within the bigger picture. Strategy must also consider how user experience will evolve over time.
Planning, Staffing, and Resources
The author suggests a team structure to ensure that all the necessary skill-sets are included, and all the appropriate functional areas have buy-in to the plan.
- Business Team: business strategist, product manager, marketing manager, program manger, project manager
- Experience Design: UX strategist, information architect, creative director, designer, content manager, documentation writer, copywriter
- Research: Usability analyst, moderator, research assistant
- Technology; systems architect, technical manager, software engineer, quality assurance
- Other: legal and compliance
In larger companies, the individuals involved may be specific to a product or a program. In the case where a task involves an entirely new product, individuals who have experience in similar ones should be selected.
Given that the team is interdisciplinary, there will be different and conflicting agendas that must be negotiated to arrive at a plan that delivers value to the customer and drives profitability. (EN: the author provides various advice for managing the conflicting interests of the group, but the advice is both speculative and facile - not worth preserving.)
Establish Metrics for Business Success in the User Experience
The author provides a list of the key questions that can be used to evaluate user experience:
- Who is the customer that makes the purchase?
- Who is the end-user of the product?
- What are their goals? Or, what problem will the product solve?
- What do they value in the experience of the product?
- What do they expect the experience to be like?
- What are the drivers of relationship?
- What substitutes and competitors exist for this product?
(EN: This seems a bit hazy, as the process of purchasing and using seem to be blended together, and the notion of servicing and repurchase seem to be forgotten. It might be better to identify all parties involved in the product lifecycle and ask the questions of each of them to have a more comprehensive approach to the UX.)
Once each of these are identified, evaluate the answers, and consider how to translate them into actionable metrics. Some of these will be imperatives to be considered in the design of the site, others can be measured over time from customers use of the site.
(EN: The examples the author provides are also a bit off, and seem to be based on speculation about what the customer might want, which is prone to inaccuracy. And there is second-degree speculation as to the qualities that would satisfy the "wants". All in all, this is very messy and another source should be consulted for better guidance.)
Know the Customer Well: Develop a Customer Model and Establish the Demand
The author describes a process for creating a customer "models" (called "personas" in other sources) that provide a more concrete notion of the individual customers. Such a model would included demographics, working and learning styles, technical and product expertise, expectations based on competitive experiences, features they consider useful, and product attitudes. Such an approach can be used to focus discussion based on the consideration of the actual characteristics of typical customers.
Once the models have been developed, it should be fairly straightforward to develop detailed scenarios that indicate how the customer is expected to behave, step by step, throughout the purchasing process as a means to discover areas that need additional consideration or identify opportunities to improve the user experience.
(EN: The use of models or personas is a "better than nothing" practice, but a poor surrogate for interviewing and testing with real people who match the market segment you're intending to serve.)
Perform Competitive Analysis for User Experience
Once you have determined what the customer wants and expects of the user experience, consider the competition, with an eye toward how well they are fulfilling it. Any instances in which they are falling short is an opportunity for you to outperform them; and the instances in which they are strong are areas in which you must match their strength in order to be competitive.
Do not limit your considerations to a specific medium. Which medium to use is a component of a valid customer choice, and competition may well be between your Web site and a competitor's physical store. (EN: And while you're at it, compare your project to your own channels - your goal isn't necessarily to steal business from yourself or compel customers to switch channels, but to ensure the project you're developing is comparable - and provide notes for other channels so they may benefit from your research.)
UX should be examined in detail to determine where there may be customer expectations set by common practices or "best practices" that can be considered for adoption.
(EN: The timing of competitive analysis, and the description here, are well done. Too often, a project merely imitates competition, without considering whether what a competitor is doing is actually desirable by the customer. Doing the core analysis first can avoid imitating bad practices.)