uselog.com | the product usability weblog

Complete list of recommendations for usability in practice: second feedback round

2010-07-10T14:40:00.003+02:00

First of all, thanks for all the feedback I received in the comments or via email after my first call. In a way of working similar to the Delphi method I have now incorporated your comments in the recommendations. The additions or changes are listed in red (like this) and in most cases I have motivated them in the comment section of the post.

Now that the overview of all recommendations is complete, I would like to invite you one more time to give your feedback. Based on that input I will perform a second and final iteration of the recommendations, which I will publish in my PhD thesis. And as promised earlier, I will mention everyone that makes a (serious) contribution.

Below is the complete list of recommendations. The ones that I made changes to are labeled with an asterisk (*). I will be taking a summer break from blogging for a short while and will return in August. I hope you enjoy the full list.

Usability 101

1. Understand what usability is and what it means for your products*

2. Analyze the consequences of usability for your company

3. Decide whether usability should be a priority for your company*

Team

4. User-centered design skills on the team early and throughout

5. One roof: all disciplines - in one room - throughout the process*

6. Feed the 'feel for the user': provide product developers with feedback

7. Get and keep experienced people

8. Don't let designers do their thing*

Process

9. A development process that facilitates user-centered methods

10. Think development rather than design*

11. Think concept as well as detail*

12. Apply guerilla usability techniques

13. Early user research, simulation and evaluation

14. Inside-out approach to user research and evaluation*

15. Rich communication of user research and evaluations

16. Select the appropriate functionality

Project

17. Increase design freedom

18. Do not innovate the user interface*

19. Don't prescribe methods for user-centered design

Company

20. Align the organization with user needs

21. Upper management that gets and prioritizes usability

22. Establish a user-centered company culture*

Market

23. Merge buy and try in retail*

24. Control your retail channels

25. Don't explicitly advertise usability

25. Market: Don't explicitly advertise usability

2010-06-29T14:14:00.020+02:00

"People always talk about ease of use, but I think it’s more... I don’t think it gets into the play in the buying process. It's more of a dissatisfier, I guess..." (Market intelligence manager)

Advertising usability is no guarantee for success

There have been a considerable number of electronic consumer products marketed specifically 'as easy to use', such as for example the Philips Easy Line and Vodafone Simply. They never seem to last or achieve mainstream success. In terms of the Kano-model of satisfaction, usability is a must-be requirement; people expect a product to be usable. Advertising a product as usable is like saying: "Hey people, we did NOT screw up this time."

In general, usability is not a sales argument
In general, I would not use usability as an explicit sales argument because I believe usability is usually not an important purchase consideration for buyers. Long-term satisfier: yes, initial purchase consideration: no. In addition, by using usability as a product's unique selling point you run the risk of stigmatizing its buyers, and you are raising expectations with regard to usability. Usability is about customer satisfaction, and customer satisfaction is about expectations. If these expectations are too high, it is hard to outperform them. Instead, sell a product based on qualities that can be perceived already in the shop, such as functionality, aesthetics and performance.

Except when usability has led to frustration

There's one case in which usability may be used as an explicit sales argument: if a wide audience is very conscious of a usability problem with a certain product category. And if this issue is top of mind as they are walking into the store. Apple started to explicitly highlight the usability of its Macintosh computers in its Switch campaign, but only with its Get a Mac campaign, when people's frustration about Windows Vista peaked, did it really seem to strike a chord. TomTom assessed that the frustration of not being able to find your destination resonated with people, even before using the product, so it adopted the slogan: 'Find your way the easy way'. But using a TomTom product does not send the message that you as a user are technology-averse.
You can take further advantage of people already being frustrated by the usability of a certain product (category) if you allow buyers to experience the - superior - usability of your products in the store, as discussed in this previous recommendation.

Simple, not easy
Even if usability is a purchase consideration among buyers, I would shy away from explicitly billing a product as ‘easy to use’ or 'ergonomically designed'. 'Easy to use' basically implies: “Hey, even you - being a complete dummy - could figure this out!" and 'Ergonomically designed' first of all sounds ridiculous, and second of all communicates that there's really nothing else to this product than correct physical dimensions. I you do want to highlight usability in a marketing message, I would position a product as ‘making sense' or as ‘it simply works’. And highlight the benefits of the product being usable: Fun! Results! As the Flip Video is advertised: "As simple as it is fun." Note that it reads simple, not easy.

Summary

Because:	Requires:
- ‘Easy to use’ products stigmatize buyers - Usability is not an important purchase consideration - Advertising usability raises expectations	- Having other purchase arguments besides usability - Have buyers experience the product in-store - Marketing message that implies usability and highlights the benefits - Marketing message that blames products for being unusable, not people for not understanding them

Relevant posts on uselog

> Simple phones and basic phones

> Hoover goes ergonomic: the Freemotion
> The Flip: video doesn't come any easier
> Usability as sales argument for Sharp copiers
> Bahco: Ergonomic Tools

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: jcwestbrook

24. Market: Control your sales channels

2010-06-28T09:59:00.003+02:00

"Network operators are very interested to have things in phones that force people to use the network to download something onto the handset. So for example, a network operator may prefer a handset to ONLY support music which is downloaded. (....) Often operators will ask us to limit certain features and functions in a handset to force the consumer to use network based services." (Product marketing manager)

Service providers and retailers have their own preferences
Companies that in the end sell a product development group’s products to consumers, such as retailers and service providers, often have their own ideas about what a product should do, based on their own interests. For example, a telecom service provider makes money by users making calls and would not be terribly delighted by a phone with a built-in voicemail box. And as in electronic consumer products retail functionality often is a primary sales argument, retailers may demand a large amount of functions including functions that, from a user experience perspective, are unnecessary.

Control your sales channels

One strategy for a product development company to become less dependent on third-party resellers is to set up its own retail, in the form of retail stores, shop-in-shop concepts, and online shops. This also enables more control over the way products are presented. Secondly, though this is more of an advantage than a pro-active strategy, if a product development company has an extremely well-known product, retailers will need to have this product in their stores, as buyers will come in and ask for that specific product, and otherwise they will go somewhere else to get it. This will enable a product development company more freedom to make a product that they believe offers the best user experience.

Summary

Because:	Requires:
- Third-party sales channels may demand non-user-centred requirements - More control over how products are presented	- Setting up own sales channels - Owning a product that third-party resellers need to have in their store

Relevant posts on uselog

> Selling usable products: The roots of Apple’s retail stores
> Sales over usability in hotel remote control

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: humedini]

23. Market: Merge buy and try in retail

2010-06-25T09:16:00.010+02:00

"There are what we call self-select environments, where (...) you pick the box up and you take it to the cash register. (....) But in many of the more advanced retail environments there are people that who actually go through a service cycle with you, who will demonstrate the product." (Product marketing manager)

Experience usability before purchase
Because consumers can have a hard time judging a product’s usability before purchase usability is usually considered a long-term benefit: initially it may not increase sales numbers, but it does increase customer satisfaction, thus brand loyalty, and thus may lead to repeat sales. But your sales numbers could benefit directly from your products being usable. If you believe your products really are usable, you might want to make that usability visible to buyers. One strategy can be to enable buyers to experience them before and during purchase; what Lincoln and Thomassen (2007) refer to as ‘merging buying and trying’.

Fully functional products on display
This requires products to be fully functional and accessible to users when on display at sales points. This includes other components of the ecosystem being hooked up, and the products not being locked away in display cabinets, but freely accessible to customers. What also helps is sales staff that is actually knowledgeable about the products they are selling, and that can guide potential buyers while trying a product.

Appearance can raise expected usability
A second - but somewhat risky - strategy is to give potential buyers a hint about the usability of your products by giving them an appearance that accurately conveys their level of usability: align expected usability with actual usability. But then you'd better be sure you live up to what you promise, because if you set expectations too high, it becomes harder to satisfy users.

Summary

Because:	Requires:
- Usability must be experienced	- Usable products - Fully functional products at sales points - Customers can access products freely - Knowledgeable sales staff - Optional: product appearance that raises expected usability

Relevant posts on uselog
> Study: expected versus experienced usability
> Stabilo 's Move Easy: high expected usability
> Expected usability: all buttons to the back (don't forget to read the comments, I rest my case ;-))
> How consumers get themselves into usability trouble
> Shop demos: Don’t try me, just buy me
> Selling usable products: The roots of Apple’s retail stores
> A consumer's manual to buying a usable product

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: reflexer]

22. Company: Establish a user-centered company culture

2010-06-24T11:17:00.007+02:00

Dutch billboard by Tele2 Business saying: 'Service is not a department but a mentality.'

"You should really get your people to care about usability, and that requires making a strong case about why usability is important. It should not be something that comes up now and then; it should really be at the core." (Usability specialist)

Positive attitude towards usability
Product development means compromising. Development teams have to weigh product properties and then figure out how to realize as much of them as possible with the available resources. To create usable products, usability should be prioritized in at least some of the decisions. This can be positively influenced by a user-centred attitude among product developers, which in turn can be fostered by a user-centered company culture. In addition, running a user-centered product development process can require a significant investment of resources (time, people, money), which is unlikely to happen in a company that does not consider usability important.

Enabling a user-centered company culture
Such a culture is enabled by product developers understanding and appreciating usability, seeing the results of their work in user tests and after sales feedback, and having customer satisfaction (which is impacted by usability) as a key performance indicator. A user-centred company culture is also fostered by upper management prioritizing usability and if product developers perceive usability to be a part of their company’s brand promise. As such, a company's brand position does not only communicate to potential customers what to expect, but also to product development teams what promise they have to live up to.

Prioritization of usability
As usability is a long-term non-quantifiable product quality, it is unlikely to be prioritized if more short-term, quantifiable product properties, such as system stability, production quality, aesthetics and functionality are not yet at a sufficient level. If the short-term quantifiable product properties are at a certain minimum - satisfactory - level, that increases the chance of usability becoming a priority.

Summary

Because:	Requires:
- Product development = compromising - User-centered product development requires a significant investment	- Knowing if and why usability is important - Team members seeing the results of their work - Customer satisfaction as performance indicator - Viable product proposition and stable technical platform - Upper management gets and prioritizes usability - Usability (perceived as) part of a company’s brand promise

Relevant posts on uselog
> Motorola's company culture obstructs good design
> Philips: Sense and Simplicity
> Organizational aspects and consumer product usability

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: Marketingfacts]

21. Company: Upper management that gets and prioritizes usability

2010-06-23T13:23:00.008+02:00

"Usability is very important for our products. We have a board member who's always saying: 'If my wife can't use it, it's not good enough.'" (Product manager)

Power brokers
One of the most influential factors to determine whether a company can successfully deal with usability is upper management (development group managers as well as corporate managers). First of all, managers decide about the resources that are assigned to development projects and groups. Secondly, as argued earlier, upper management is the only actor that can ensure different product development groups cooperating on a product or product family. Finally, the attitude of upper management can seriously impact company culture. If management is seen to prioritize usability, product development teams are more likely to do so as well.

Upper management needs to understand its products
For upper management to prioritize goals (product quality, usability) over resources (time, money, staff) they will need to understand their own products. If it is not clear to them how a product works, they will not understand how certain design decisions impact product quality. And thus they will prioritize concrete, short-term effects (i.e., resources) over ungraspable, long-term ones (i.e., product quality). Also, to have an effect on the individual product development projects, upper management will need to be involved in, or at least have knowledge about product development projects.

Appoint a creative director
In the movie industry, apart from the producers, who ensure that making the film runs smoothly from a financial and project management point of view, there usually is a creative director, who is ultimately responsible for the quality of the creative work. In companies where upper management does not understand its own products and/or product development, I would argue for appointing an - equally powerful - creative director, who balances the process and resource-oriented view of other managers. Bear in mind that the word 'creative' in creative director refers to the process of creation, not to being responsible for thinking outside the box.

But to be honest, I would prefer a situation where upper management actually gives a damn about their products and how they're created.

Summary

Because:	Requires:
- Product development = compromising and upper management decides about resources - Upper management can ensure development groups within a company cooperate - Upper management influences company culture	Upper management that: - understands its products - understands (and prioritizes) usability - is involved in product development

Relevant posts on uselog
> Want to make an iPhone killer? Think this over...
> TeliaSonera wants usability
> Microsoft's Steve Ballmer in 2007: why the iPhone is not a good proposition

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

20. Company: Align the organization with user needs

2010-06-22T09:13:00.002+02:00

"To be honest, to provide a proper user experience, we should have integrated their product with our own. Or ours with theirs. But they were in a different division." (Product manager)

Electronic consumer products are networked
Electronic consumer products are becoming more and more networked. Many of the most serious usability problems are caused by the system as a whole, not by user interfaces on the individual products. Try to ensure that your product works well in the eco-system in which they will be embedded. Either by creating industry-wide standards (hard to achieve, not always upheld) or by making sure your company owns all components of a product’s eco-system (costly). Owning the eco-system ensures you can coordinate the application of user experience design guidelines, and deal with connectivity and interoperability issues.

Limited collaboration between product groups
But even if your company as a whole develops all components of the eco-system, there is no guarantee that development will be in a coordinated fashion, as often these components are developed in separate development groups, between which collaboration can be limited.

Cutting through the silos

Companies should be willing to cut through the silos of their organizations in order to create a great product experience. Product development companies’ raison d’être is to develop products. In the end the organization should be designed to create successful products, products should not be designed to fit the existing organization. Alignment and collaboration between development groups does require involvement of upper management. And it is facilitated considerably if all development groups are in one single location, as for true collaboration I do not yet see an alternative to meeting day-to-day, face-to-face.

Summary

Because:	Requires:
- Products keep changing (integration required) - Product usability > interface usability - System usability > product usability	- Owning the eco-system - Development groups within company cooperating - High level visionary - Product development groups in one location - Budget - Guts

Relevant posts on uselog
> Consumer electronics have become complex systems
> Ensuring consistency and interoperability: monopolize or standardize

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

19. Project: Don't prescribe methods for user-centered design

2010-06-21T13:59:00.004+02:00

"As an agency we try to provide the test setup that will help our client best. And that may mean applying methods we are not experienced with or that are not routine. And then we try to organize that." (Human-centred design consultant)

Check-box mentality
Prescribing what methods for user-centered design a team should use in the development process could ensure user involvement. However, it may also lead to a situation where a team does not apply the right method, but the prescribed method. Or to a check-box mentality: instead of actually being interested in the results of user involvement, team members may simply conduct a step because the process prescribes it and they can't pass a milestone without having executed that step.

That, not which
The product development process should indicate that user involvement is desired, or even required. However, what method for user-centered design is appropriate to apply in a particular project should be left up to the development team. They have most knowledge about the design challenge, resources and team skills, and thus are the best judge of what methods should be used.

Don't push methods, get the team to pull
Instead of pushing teams to conduct user involvement by prescribing methods for user-centered design, I would argue for a 'pull': in a company with a sufficiently user-centered culture product development teams are likely to start looking for possible ways to conduct user involvement. This does require thorough knowledge of user-centered design methods.

Prescription ends process innovation
An important advantage of not prescribing specific methods is that you are fostering grass-roots process innovation: because teams can explore, test and share new methods, the user-centered design proficiency of your company as a whole has the chance to evolve and improve over time. Whereas when you prescribe a process, all improvements have to be conceived, tested and sanctioned by the 'methodology people'. That's a lot of weight to carry.

Summary

Because:	Requires:
- Prescribing methods may lead to inappropriate methods being applied - Prescribing methods may lead to a check-box mentality - Prescribing methods may cause teams to look for workarounds	- Development team with knowledge of user-centred design methods - Development team that prioritizes usability - Product development structure that facilitates the integration of user involvement - Exchange of knowledge about and experiences with user-centred design method

18. Project: Do not innovate the user interface

2010-06-18T09:54:00.009+02:00

"It would be way too much work to develop a UI for each new product. We have a number of UI platforms. It takes time to develop a new UI carefully." (Interaction designer)

A UI from scratch is unfeasible
In the electronic consumer products sector the speed of product development is so high and the product portfolios are so large that it is impossible to develop the user interface for each product from scratch.

UI innovation = high risk
Secondly, as usability can be influenced by a large number of product properties, ranging from the high-level (such as the lack of a function) to the minute (a button label that is hard to interpret), introducing a new function, content, interface or entire product increases the risk of poor usability. Often user interfaces take many years and generations of products to optimize and it is preferable by far to improve them in an evolutionary fashion. Innovating a product or a UI, that is making changes to them that have not been applied yet (e.g., in other products) diminishes a development team’s knowledge of the usability issues in their product. The value and applicability of the knowledge gained about the usability of the predecessor product, through user testing and after sales feedback, is dramatically reduced if a new design is made. And, assuming that existing products are developed based on knowledge about the user group, developing a product that targets a new user group (either because the product proposition is new or the target market is) means that the knowledge about the user group may not be present.

UI paradigm: easier to develop

To prevent having to make a user interface design from scratch for every product, using a UI paradigm as the basis for the UIs of individual products is an appropriate solution, especially if a company has a considerable portfolio of fairly similar products. A UI paradigm is a platform-based approach to the development of user interfaces allowing a company to quickly develop user interfaces for individual products, and apply the learnings from the user test of individual products to the improvement of the UI paradigm. This makes a UI paradigm an extremely powerful tool for developers of electronic consumer products.

Cross-product consistency
Additionally, as a consequence of basing the UI per product on a UI paradigm, users will encounter similar UIs on the different products of a family or over generations. This will make it easier for them to learn how to use a product, which in time may become an argument for repeat sales, as it once was for Nokia phones ("All Nokias work the same way...").

Conditions for a UI paradigm
However, to be able to apply a UI paradigm, there are a number of conditions. First of all, the UI paradigm must be suitable for the product category to which it would be applied. Don't try to fit the same UI paradigm to all your products if these range from mobile phones to high-end televisions. Secondly, to be able to base individual UIs on a UI paradigm, within and between-generation consistency of products is needed. Within-generation consistency means that the products within a product line of one year are similar, so the same UI can be applied to the different products in the range. Between-generation consistency means that the product lines don’t differ too much from year to year, which allows the learnings from one generation to be used for the improvement of the next, and the same UI paradigm to be used over a number of generations.

Innovate when you have to

Finally, sometimes you should innovate the UI. Because your product simply has a poor UI or you can see that due to changes in your product category the current UI (paradigm) is outdated. In those cases, innovate, but then with your full weight behind it. Only innovate when you have to, and when you have to, make it count.

Summary

Because:	Requires:
- User interfaces take years and generations to optimize - Time pressure too high to design from scratch for every product - UI paradigms: capture what’s good, transfer knowledge	- User interface paradigm (suitable for a product category) - Design freedom to implement a UI paradigm: control over the UI - Cross-range and between-generation consistency - Continuous improvement of UI paradigm

17. Project: Increase design freedom

2010-06-17T14:35:00.002+02:00

"That product was built on predecessor models, so you start from a legacy. That's like carved in stone, and any changes to the legacy are difficult." (UI designer)

Design freedom

You can feed all the knowledge you have about the user group, potential design solutions and usability issues into an extremely sophisticated user-centered design process, executed by the most user-centered team imaginable, if they can’t apply their knowledge and talents all this is useless. If you’re not allowed to change a component to begin with, for example because a third-party supplier makes it, you cannot improve it. If you are not given time, budget, or staff to work on an issue, you cannot improve it. To make use of a team's knowledge and user-centered design proficiency, product developers need what I refer to as design freedom: the combination of sufficient resources (budget, staff and time) and design mutability (being allowed and able to change a design). To draw a parallel, if you are sketching, the size of your paper represents the mutability, and the crayons and time you can spend are your resources.

Control the technological platform

For electronic consumer products, design mutability can be improved by developing a technological platform with a flexible hardware and software architecture, because this facilitates implementing changes late(r) in the development process. Design mutability can seriously suffer if the product development team cannot influence the development of the technological platform, because the engineering department works in isolation or development of the technological platform is outsourced. In these situations the development team is often not involved in setting requirements for the platform and then late stage changes require considerable investments.

Do not outsource the UI

In situations where the development team has little control over the development of the technological platform, it should at least retain ownership of the user interface. A technological platform in which the user interface is integrated, and which thus forces the development team to completely rely on the third-party supplier for changes, is a barrier for design mutability. In outsourcing strategies it is usually not recommended to outsource core-business activities or strategic components (Jiao et al., 2007), and companies that aim to make usable products should consider the UI a strategic component.

Summary

Because:	Requires:
- Knowledge & user-centred design proficiency are useless when not applied - Design freedom requires the availability of resources and the possibility to change a design	- Sufficient resources to design and implement a user-centred design (time, staff, budget, equipment) - Development team has control over the technological platform - Flexible hard/software architecture - Ownership of the UI (not depending on suppliers)

16. Process: Select the appropriate functionality

2010-06-16T14:24:00.068+02:00

“The view from marketing was that every year you had to offer new features. But at some point this has to stop. You can’t put more and more features in the same product every year.” (Interaction designer)

A product with extensive functionality is likely to be less usable because:

the user has more functions to learn and choose from, and
the development team has more functions to design, implement, and integrate into a fluent whole.

So extensive functionality can have a twofold negative effect on usability.

Functions, not features
Note that I talk about functions, not about features. Functions are the goals that a product can help the user achieve, such as cleaning clothes or playing music (Shackel, 1984, p.54; Grudin, 1992), while features are the identifiable aspects of a total product offering that a critical reference group perceives and evaluates as an ‘extra’ to a known standard among comparable products (Thölke et al., 2001).

Fewer functions, less consumer appeal

Although in general I do believe it is beneficial for usability to prioritize quality over quantity of functions, I do not think a product’s functionality should be kept to a minimum per se, as this is likely to make it harder to sell it. There is an abundance of ‘simple’ products that were never to be heard of again (e.g., Philips Easy Line).

Fewer functions does not automatically equal more usability
Secondly, a product with more functionality can be used for a larger variety of goals, which - considering the definition of usability - in some respects makes the product more usable. For example, putting a camera, calendar, and MP3 player into a mobile phone is indeed likely to make it harder to just make a call. However, for the goal of carrying around as few devices as possible, a product with all the aforementioned functions is more usable in comparison to having to carry around a digital camera as well as a PDA, MP3-player, and a mobile phone.

Ianus-prioritization: sales and usage

As electronic consumer products are sold to a large part based on functionality, but an excess of functionality is likely to lead to a less-usable product, a Ianus-prioritization of functionality should be made. Highlight the sales as well as the usage perspective, and thus outline which functions are important to:
1. sell the product, and
2. provide a satisfying user experience.
And don’t kid yourself, these lists are not necessarily identical. They serve two masters, the customer and the user.

Identifying versus selecting

It is much easier to identify possible functions than to select the right ones. Possible functions can be identified through user research, competitor products, focus groups, etc. However, few methods are available to subsequently converge on an appropriate set of functions, one of the few being the conjoint analysis.

Prioritizing use cases by frequency and impact

Selecting the functions that are most important for usage - and that thus most attention should be paid to while developing the product - should be done based on usage frequency (how often a function is used) as well as on usage impact (how important it is if it is used). An example of a use case with a high frequency would be playing a song on an MP3-player, while a use case with high impact would be activating the emergency brake on a train. Based on frequency and impact the use cases can be labeled as primary, secondary, etc. This prioritization can be used to direct attention and resources when designing, evaluating and implementing the product.

Summary

Because:	Requires:
- Products with extensive functionality are more prone to be unusable and harder to develop	- Knowledge about the user group (needs and preferences) - Knowledge about product usage (frequency of usage of functions) - Looking at a product from the user perspective (and not the buyer’s nor the geek’s) - A functionality evaluation method - Two prioritizations of functions: from a sales and usability perspective - Prioritizing quality over quantity of functionality

Relevant posts on uselog
> Easy 5. Easy yes, but a phone?
> Simple phones and basic phones
> Simplicity: functionally and visually
> The simplicity of the first Walkman
> When simplicity wins over features: Philips DirectLife
> Don Norman: Simplicity is highly overrated
> Mobile phone 'gadgets' not used by half of Dutch users

15. Process: Rich communication of user research and evaluations

2010-06-15T13:17:00.012+02:00

"We asked software engineers to sit in during the consumer tests (...) to have them see this is really something that people experience. (....) I think that for some of them it was something like a turning point in how they see things. After that they got a very proactive attitude." (Product manager)

Understanding, acknowledgement and empathy
Human-product interaction is very hard to capture in words, let alone numbers. I found that communicating the results of user research or testing to development teams in a 'rich' way - by the team being present at user tests or at least by showing videos - increased the team's understanding of the results. But it also increased their trust in and empathy with them. I would say that when communicating user research and evaluations you have the following goals:

Understanding: the team gets your description of the interaction problem;
Acknowledgement: they believe that it's actually a problem;
Empathy: the team can identify with (people having) this problem;
Engagement: feeling responsible to deal with the issue;

Which in the end, of course, should lead to action; to the issue being dealt with.

Ends discussions
Communicating user research and evaluations in a 'rich' way ends discussions. There is no denying that the problem actually occurred when it is happening right in front of you. And it's a lot harder to blame the test participants when you've seen for yourself that they are not complete morons.

Communicating knowledge not explicitly requested
Secondly, communicating the results of user research and evaluations in a rich way offers the development team much more information than just the issues the research focuses on. For example, videos of a field study don't just show how people have set up their stereo equipment (if that is the focus), it also shows designers how people talk about those products and what their homes look like. When making decisions designers integrate huge amounts of - often tacit - knowledge. Through rich communication of user research and evaluations you may feed them very important information for design decisions in the current project as well as the next.

Designers as user researchers?
One of the most effective ways to communicate user research and usage evaluations to designers may be to have them execute it. It doesn't get any richer than doing it yourself. Usability specialists could involve industrial and interaction designers in the execution of user research and evaluations. Or maybe the roles should not be separated, and there should be what Boivie et al. (2006) refer to as the Usability Designer: someone that is proficient in all aspects of the user-centred design cycle, not just in user research and/or evaluations.

For more information on communicating user research to design teams, see the work of my colleague Froukje Sleeswijk Visser.

Summary

Because:	Requires:
- Designers need detailed information for design decisions - Facilitates understanding, acknowledgment, empathy, and engagement	- Capturing user research and evaluations on video - Integrating video clips in user research or usage evaluation debriefing - Involving designers in user research/testing - Presence of team members at user research or user testing

Relevant posts on uselog
> Sony Streetstyle headphones: based on a keen eye for detail
> Usability at Xerox: when user hits machine
> Anthropologists to the rescue!
> Contextmappping symposium videos online

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: lucamascaro]

14. Process: Inside-out approach to user research and evaluation

2010-06-14T09:54:00.010+02:00

We have to iterate by looking at foam models. (….) We’re looking at, for example, keys. Are they separate enough (…) or will they be accidentally pressed? Or the side keys are they buried enough, or are they sticking out a lot? (Industrial designer)

The only head you can look into is your own

For both user research and user evaluations, take an inside-out approach. When conducting user research for a new product, start by using the product yourself. This is often relatively easy to arrange, and secondly, this is the only way to experience how it is to interact with a product (category) first hand. You can’t look inside anybody’s head, except your own. Exploring a product category first hand will sensitize you to the issues that are important for interaction with this product. Next, you can observe and interview colleagues at work, and after that you can - informally - study family and friends. Finally, user research can be conducted among people that are thought to be representative for the actual user group.

The same approach goes for evaluations. A design can first be evaluated by the designer, then by his team, then by colleagues outside the team, then by friends and family, and finally with a representative group of test participants. To increase the quality of the earliest evaluations, usability inspection methods, such as cognitive walkthrough and usability heuristics can be applied.

You are your own first checkpoint
The idea is that both for user research as well as for usage evaluations the initial first ‘inside’ steps provide high-resolution information and require limited investment of resources. And though the results may not be completely representative, they do sensitize the development team to the most important issues. And it increases the chance that by the time a full-fledged user test is conducted you can focus on the more detailed issues, as the most obvious ones have already been filtered out.

Bridge the designer-user gap

When going through the 'inside' steps, be aware that you are not the user. Try to compensate for this with techniques to invoke empathy. For example by simulating how it is to be a user, as with the third age suit, and with the help of evaluation techniques. Secondly, being aware of the context of use of actual users can help designers to better be aware of the differences between them and the user, and help to better anticipate future usage. This can enable you, for example, when evaluating a prototype, to be aware that real users might feed the dog while using your product, and not give it the dedicated attention that you do.

Designer bias
Finally, beware that because you have defined, designed and/or developed the product, you have infinitely more knowledge about how it works than the user has. In their book Made to Stick the Heath brothers call this inability to unlearn what you have learned and thus being less able to explain things to others the 'Curse of Knowledge'. Also, when conducting user research or usage evaluations with colleagues and/or friends and family, be aware of possible differences with the projected user group. And of bias, because the participants know you and possibly the company you work for.

Summary

Because:	Requires:
- Early knowledge = high design freedom - Resources are limited - You can’t look inside other people’s heads	- Personally exploring a product category (user research) or a evaluating a design (user evaluation) - Understanding of and empathy with the user group - Techniques to compensate for participant (developer, colleague, friends/family) not being similar to the user group - Techniques to compensate for bias because you have made the design or participants know that you have (in usage evaluation)

13. Process: Early user research, simulation and evaluation

2010-06-11T15:15:00.039+02:00

"And if you don't do this in an early stage, in a majority of the cases it simply is not possible to change it in a later stage. (...) At the moment we are trying to do that more." (UI manager)

Early phases = high design freedom
Early in the product development process design freedom (design mutability in combination with available resources) is still high (see illustration above). This explains the desire for the early availability of user research (to make a usable design), and early usability evaluations (to iterate this design).

User research before official project start
As product development projects usually hit the ground running and time pressure remains high throughout, it is recommendable to execute the user research for a project during the implementation of the previous project. In the later phases of product development usability specialists and interaction designers should still be involved, but more in an advisory capacity, so they should be available to start conducting the user research needed for the next generation of the product.

Early evaluation = early simulation
As in the early phases of development the design is not yet detailed, early simulation and evaluation, implies conducting evaluations with simulations that may not be representative for the final product and that are not very mature, such as paper prototyping and physical mock-ups. To ensure that evaluations are conducted, apply 'low cost' evaluation methods, such as usability inspection methods (cognitive analysis, heuristic walkthrough) and ‘quick & dirty’ user testing.

Information from previous projects
The results from usability tests conducted in previous projects can contain important information, as often not all usability problems that were identified could be dealt with in the that project. Similarly, after sales feedback (reviews, helpdesk calls, satisfaction surveys) on a previous generation of the product is also a very valuable source of information on usability issues. For after sales feedback to be useful, there needs to be a certain degree of similarity between product generations.

Summary

Because:	Requires:
- Early knowledge = high design freedom	- User research previous to project - Early prototyping & testing - Usability inspection methods - Transfer of information from previous projects - Use after sales feedback of previous products - Similarity between product generations - Keeping product development teams intact - Accepting that you can’t quantify everything

12. Process: Apply guerrilla usability techniques

2010-06-10T14:51:00.013+02:00

"Usually we try to do the testing in English-speaking countries, primarily because of the costs. Because doing this stuff is really expensive." (Market Intelligence Manager)

Pragmatic considerations for selecting user-centered methods
In product development practice pragmatic considerations, such as costs, required time, staff and costs, are a very dominant factor to determine in whether or not a user-centered design method is applied. More important than the perceived effectiveness of a method. I believe practitioners benefit more from methods that are widely applicable and mostly accurate, than from methods that are one hundred percent reliable, but hardly applied. Many small-scale tests and iterations are preferable over a single, late, and half-hearted iteration.

Guerrilla usability methods
Jakob Nielsen presents a number of user-centred design methods that can be applied in a limited amount of time, by a limited amount of people, and at limited costs, which he refers to as guerrilla HCI or discount usability engineering. Successfully applying discount methods does require a company culture that is open to qualitative analysis and evaluation techniques.

Summary

Because:	Requires:
- Multiple, fairly reliable iterations are more effective than one half-hearted 100% reliable iteration	- Knowledge of and experience with guerrilla user-centred design methods - Company culture open to qualitative methods

Relevant posts on uselog:
> How much can you learn in 73 minutes of user research?

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Illustration: useit.com/Jakob Nielsen]

11. Process: Think concept as well as detail

2010-06-09T15:13:00.012+02:00

"Our products tended to be for geeky people, people that like to sit and play with their computer. We wanted something that perhaps my mother could have, bought from the shop, (...) switch it on and it was simple to use. But that required us to completely rethink our product." (Hardware development manager)

To develop usable products you have to carefully select the appropriate UI concept, and then refine and implement it without compromise.

A concept is a promise
When selecting an interaction concept the development team should move with caution, as some concepts offer a much higher potential level of usability than others. Especially when selecting a UI concept that will be implemented throughout a product line, the consequences of selecting a concept can be severe. To be able to select a UI concept, these should be designed and simulated in sufficient, maybe even in full, detail, and subjected to a comparative evaluation.

Implementation can make a promise come true
Once a UI concept has been chosen it should be developed further through many iterations of evaluations and redesigns, each time zooming in further on properties of the product that can be improved. This optimized design should be implemented without compromising it, which requires sufficient design freedom (resources and ability to change the design).

Fixing problems versus overhauling the concept
Especially when working on a new version of an existing product, when a UI concept is already in place, it might be tempting to focus on fixing known usability problems of the predecessor product. Even though changing the underlying concept might be the appropriate step, and improve the overall usability of the product much more. Whether changing the UI concept is possible, however, depends on the design freedom, goals and planning of a project.

Both interaction and UI designers
In order to execute this, the presence of people that can analyse and synthesize with the usability of the whole product and eco-system in mind, as well as that of people who like the nitty-gritty details of perfecting the user interface, such as optimizing transitions, icons and text labels. In other words: interaction designers, as well as user interface designers.

Summary

Because:	Requires:
- The choice of UI concept determines the hypothetical maximum level of usability - How well a UI concept is implemented determines how close one gets to the hypothetical maximum level of usability	- Development of multiple UI concepts - Prototyping multiple UI concepts - Comparative evaluation of UI concepts - Attention to detail - Multiple iterations of evaluation and redesign - Design freedom - Interaction designers as well as user interface designers

Relevant posts on uselog

> Usability is fragile: design examples from consumer electronics

> User profiling gone wrong: TiVo thinks I'm gay

> Not every touch-screen phone is an iPhone

> More BMW iDrive reviews: the evolution of a bad idea

> Senseo: the (real) story behind a coffee revolution

> 10/GUI: multi-touch UI concept for the desktop computer

[Photos: UI patterns (left), Gilette Razorsharp (right)]

10. Process: Think development rather than design

2010-06-08T15:09:00.011+02:00

Left: A Big Mac as advertised (the design). Right: a Big Mac as purchased (implemented).

"The products can look good on paper, but then they go through a process, where this happens: 'Look, you can’t do this because of costs, and you have to take this functionality out because it would be too expensive' or 'it’s going to take too long to do this, other type of market and we don’t have the supplier to do this and this and this.'" (Market intelligence manager)

Don't make unfeasible designs
A design that will lead to an extremely usable product is worthless if your company does not have the skills and means to implement this design. Interaction designers and usability specialists should be conscious of the limitations posed by resources, technology and business models. This is facilitated by all disciplines working 'under one roof'. On the other hand, interaction designers and usability specialists should also challenge the limitations, push the envelope (some engineers may be inclined to say “no” to every request that implies changes), in order to ensure design freedom. But in the end, a feasible design that gets realized is more desirable than a dream-design that gets mutilated beyond recognition.

One person responsible from start to end
A product manager or planner should be responsible for the whole product innovation cycle. If the person that manages the early stages of product development - creating an idea, requirements, concept, design - is also responsible for delivering the actual product, he or she will think twice about coming up with a dream design that's nearly impossible to implement. Secondly, if a product manager is responsible from the product's conception up until providing customer support s/he will also be confronted with the consequences of design decisions, ensuring a feedback loop and thus learning.

Summary

Because:	Requires:
- It is about usable products, not about usable designs - A feasible design that gets implemented is more usable than a dream design that is compromised beyond recognition	- Truly collaborative product development, involving all disciplines - Development team conscious of limitations - Product manager responsible for whole product innovation cycle

Relevant posts on uselog
> Concepts versus products: usability is about execution

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: Fast Food: Ads vs. Reality]

9. Process: A development process that facilitates user-centered methods

2010-06-07T13:22:00.006+02:00

"Up to now it mainly was the UX team trying to initiate things. We are now formalizing the way we commission user research and evaluations and also the way in which we deal with the results of that research." (Requirements manager)

What is a process?
The structure of a product development process should facilitate the integration of user-centered design methods. Davenport (1993) defines a (business) process as: ”A structured, measured set of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how work is done within an organization (...). A process is thus a specific ordering of work activities across time and space, with a beginning and an end, and clearly defined inputs and outputs: a structure for action.”

The spine
Consider the product development process the 'spine' to which all the individual steps are attached. This spine should thus feature sufficient time, resources (and staff) to execute use-centered design methods, but also be designed as to be facilitate the integration of the outcomes of these methods. If there is no space on the spine for new limbs, you will not grow the limbs for a hands-on approach to user-centered product development.

Facilitating user-centered design methods
If your company has a standardized product development process - be it formally documented or de facto ensure that its structure facilitates:

the execution of user research;
thorough user-centered synthesis steps;
evaluations of product usage, and,
the opportunity for redesign(s) and implementation of these, as the value of a usability evaluation is in the follow up. A usability test as such does not increase the usability of a product, implemented (re)designs do.

Summary

Because:	Requires:
- Creating usable products requires user research, user-centred synthesis, usage evaluations, and iterations	- Sufficient time to execute user-centred design methods in all the phases of product development. - A product development process that is equipped to deal with the outcomes of user involvement.

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: Matthew Oliphant]

8. Team: Don't let designers do their thing

2010-06-04T10:20:00.017+02:00

"Making design decisions based on assumptions is very bad for usability. It is good to have a gut feeling about something, but you need to verify the assumptions you base your design upon. You need to ask users, observe them, and give them the design to test it." (Industrial designer)

Design can make a difference
Synthesizing the design is one of the most influential and yet most ungraspable steps in the development process. In the synthesis step all information is integrated. This is where a designer can make a huge difference: given the same amount of resources, one design may fulfil all (user) requirements, while another one falls short. But give three designers the same briefing and chances are you’ll end up with three completely different designs. So it matters what designer you pick for the assignment.

The analytical, the intuitive, and the artistic designer

When allowing my prejudices to prevail I can distinguish three breeds of designers: the analytical, the intuitive, and the artistic designer. The analytical designer works systematically: analyze, synthesize, evaluate and iterate. The intuitive designer's way of working is less method-driven, but does take into account the goals that were set. The artistic designer considers design an art form, something that cannot be forced through methods. In other words: it’s a kind of magic. Again, being blunt, I would say that the first two types of designers want to make something that works - be it via different paths - while artistic designers want to make something they like.

Analytical does not mean boring
Please note that by analytical I do not mean non-creative. It takes a tremendous amount of creativity to come up with a solution that works within certain limitations. But creative is not the same as artistic. If you want to see what I mean by creative within limitations, take a look at Wired magazine's article 'Design Under Constraint' which discusses a number of terribly creative technological solutions. As Dutch poet Jules Deelder put it: "Inside the box the possibilities are just as big as outside the box."

"I know what the user wants"
And then there are some designers (both industrial and interaction) that consider themselves the 'representative of the user', without actually looking at the user, which is a potential a pitfall for intuitive designers. Without doing user research and user testing they believe they understand what users need and want. For them, being user-centered is designing a product based on their own knowledge and experiences. I believe product design, interaction design and user interface design is not about ‘doing your thing’. Whether you think you represent the user or not.

Don't let designers do their thing

In my opinion, designers should be less like gods and more like servants. If your goal is to make usable products, hire designers that lean towards the analytical and that have thorough knowledge of user-centered design methods. Or embed intuitive designers with a positive attitude towards user-centered design in a user-centered design process and team, which ensures their intuition is fed and verified. And then leave your designers alone, don't try to manage how they synthesize. It really comes down to not letting designers do their thing, but do let them do their thing.

Making things that work

To paraphrase an old HCI adage, ‘cool’ is not a good adjective for user interfaces. Designing for usability is not about making something that's cool in the designer's book; it is about making something that works for the user (and that the user may find cool). That requires a lot of knowledge about the user group, about methods, about design techniques. And it requires the attitude of putting the user center stage, while acknowledging that you are not the user. And, yes, it also requires a little bit of magic, of talent, of je-ne-sais-quoi. Some designers just get it.

Summary

Because:	Requires:
- Large (potential) impact of design on usability - Some designers want to be an artist - Some designers believe they represent the user	- Designers educated in human-product interaction principles and methods - Analytical designers or embedding intuitive designers in a user-centered process - Learning: seeing user tests, after sales feedback - User-centered product designers

Related posts on uselog

> Unnecessary interactivity: ten whack job interaction designs
> When graphic design gets in the way
> Giugiaro: there's more to automotive design than styling

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: Karim Rashid on Hotelchatter]

7. Team: Get and keep experienced people

2010-06-03T14:34:00.011+02:00

“The worst that can happen to a product is a new product manager and a new interaction designer, because they'll want to leave their mark and have no idea what the user wants yet." (Product manager)

Experience matters
Experienced product developers have a better understanding of the intricacies of a product category and over time product developers develop a ‘feel for the user’ that is very hard to transfer from person to person. Secondly, having gone through several development projects increases a team member’s understanding of the development process and of other roles in the development team.

Keep teams intact
I would suggest keeping product development teams intact over generations. Consider a product launch a release of a version, not of the definitive product. Keeping the development team intact is the best way to ensure communication of usability issues and suitable design solutions from one project to the next.

Reward expertise
This requires low personnel rotation, which in turn requires a company culture in which being in product development is not considered a first start or stepping stone. Keeping experienced product development professionals in product development can be facilitated by a personnel policy that offers experienced specialists just as much of a path to grow and similar rewards as managers.

Summary

Because:	Requires:
- Experience fosters ‘feel for the user’ - Domain knowledge is crucial - Enables knowledge transfer	- Keeping project teams intact (over projects) - Low personnel rotation

6. Team: Feed the ‘feel for the user’ - provide product developers with feedback

2010-06-02T10:03:00.046+02:00

"Designers rarely have the opportunity to see outside people interacting with their product, so when they do they become very inspired by what they see. (...) They get a tremendous amount of empathy for the user. So that's why they just need to see the user test." (Usability consultant)

Feedback to the whole team

Make sure the results of user tests are not only communicated to the product managers and usability specialists, but also to the interaction designers and product designers, and preferably to the whole team. Invite them to witness a user test or the presentation of results, even if they are at that time no longer a part of the product development team, work in different departments, in a consultancy-like role, or if they don’t work on the user interface. The same goes for after sales feedback. Don't let customer complaints, field studies, and customer satisfaction studies stop at the product manager, but share it with the whole development team. They'll learn from it.

The 'feel for the user'
Providing this feedback will foster their ‘feel for the user’, their intuition about what makes a usable design, which can help to improve the next generation of products tremendously. Besides, no one likes to see the results of their work disappear into a black hole and never know how people thought about the product they worked on.

Summary

Because:	Requires:
- Increases the ‘feel for the user’, which is essential to user-centered design proficiency - People take pleasure in seeing the result of their work	- Communicating the results of user tests and after sales feedback to the whole product development team in an engaging manner

5. Team: One roof: all disciplines - in one room - throughout the process

2010-06-01T11:20:00.012+02:00

"Everyone must have experienced it: if you sit in a corner, with a small team, separate yourself from the rest and work closely together, then you move much quicker." (Designer of user manuals)

A shared space for project teams
The development of usable products requires the involvement of all disciplines, from the interaction designer to the product manager, from the usability specialist to the development engineer. Whereas currently in product development of electronic consumer products these disciplines are usually seated in separate departments, I would try to let them work in truly collaborative project teams. Especially in the phases in which the product is defined and designed, but also during implementation. I would opt for project teams working in a single location, in a shared project space, to allow for continuous informal interaction. On the other hand, all disciplines should also keep in touch with their departments, as this enables them to share experiences and knowledge regarding their specific discipline.

The software/hardware, interaction/industrial split

I found that it is fairly common in the development of electronic consumer products that the development of the software and hardware are separate projects and teams, between which collaboration can be cumbersome. Though far from optimal, in the light of concurrent engineering one can imagine this happening. I was (even more) surprised however, to find that in many cases industrial designers and interaction designers hardly cooperate, and even can be based in different departments. Again, there may be arguments for doing this, but it is hardly beneficial for the creation of alignment between the physical and the on-screen UI.

Informal communication

What I'm arguing for here is more alignment. It is about different disciplines understanding each other as well as having a comprehensive picture of the product they are developing. I believe true collaboration happens best in an informal, day-to-day mode, which is most likely to arise when your are located together physically. Apart from being an effective way to share knowledge, working together results in a more positive mindset, focused on solutions and understanding each other's perspective, instead of underlining problems, disagreements and company politics.

One roof
Yes, I know there is collaboration software for distributed teams, but I've never seen it work quite as well as simply sharing a room. Informal communication also is less likely to occur if team communication is limited to meetings. A meeting only allows team members to learn about a specific topic, while by being in the same room you also learn things about the product and other disciplines that may not directly influence your particular assignment, but will allow you to make a better contribution. Secondly, being in the same room allows for short bilateral discussions, as opposed to long group-wise discussions.

Work sessions instead of meetings
If being situated full time in the same space is not an option, as a fallback option you could regularly hold work sessions. Note that there is an important distinction between holding a meeting and working together. The latter is focused on sharing information, talking through issues and challenges, the former is focused on working through design challenges together, as a (multidisciplinary) team.

Design and engineering

An especially salient issue in my research was the collaboration between the people who made the design and who implemented it. As argued earlier, if interaction designers are involved early on, they can point out the consequences of requirements and early (platform) design choices. And interaction designers being aware of the properties of the technological platform limits complications during implementation. But it also works the other way around: during implementation interaction designers and usability specialists should be available to the engineers on a day-to-day basis. No design is perfect, and usually changes are required for it to be implemented. Development engineers should have quick, informal access to a person who can answer their questions. Finally, it is important for the whole team to learn about evaluations (e.g., user tests, cognitive walkthroughs) of their product, as this enables them to learn about the consequences of their decisions, but also because they can provide input about possible solutions. Again, this is more likely to happen if a team sits in one room.

Technology is not the enemy
On a special note: don't treat engineers as ‘the guys who should implement what we define and design’. They usually possess a wealth of knowledge on alternative technological solutions that can be applied if the right questions are posed early on, and if they are able (or enabled) to see the user perspective. Too often technology is described as a barrier to usability, but it can just as likely be the solution.

Summary

Because:

Requires:

- Informal communication is more efficient and effective

- Facilitates cooperation between industrial- and interaction designers, software and hardware developers

- All team members will learn from their actions

- Interaction designers will know about usability issues

- Engineers will know about user requirements

- Interaction designers will know about the limitations of the platform

- Interaction designers available for day-to-day questions during implementation

- Team members being there

- Office architectures that facilitate both project spaces and departments

- One central product development location
- Being in one project room (or having regular work sessions)

- Budget

- Staff

Related posts on uselog
> How technology improves usability: the Nokia 8810

NOTE
This recommendation is a part of a series of recommendations for industry on how to deal with usability in product development, which are the outcome of a PhD research project. Product development professionals and researchers were invited to provide feedback, based on which a first iteration of the recommendations was performed (changes and additions are listed in red). Currently the second round of feedback is being collected. You can still provide input.

[Photo: Andrea Collet]

4. Team: User-centered design skills on the team early and throughout

2010-05-31T14:57:00.041+02:00

"I think that it is good to involve people like us, the usability people, in an earlier phase, when you define how the user interface will look like, the wording, etc. It doesn't mean that we have to be a checkpoint, but we can say: 'This looks strange.' Obvious problems can be identified way earlier, without the user telling us." (Usability specialist)

Early presence of user-centered design skills
User-centred design skills should be present in the team throughout the product development process, from the very first start. By user-centered skills I mean knowledge of and the ability to execute user research, synthesize usable designs, prototype designs, and evaluate them.

Early phases = high design freedom
In the early phases of product development important decisions with regard to product definition and the technological platform are taken. Usability specialists and interaction designers should be involved in, or at least be informed about, these decisions. Maybe the UI in itself is not designed in this phase, but the interaction definitely is (at least partly). This is an issue that is especially relevant for electronic consumer products, as, in contrast with most web and software products, for electronic consumer products the hardware, operating system, software, and the controls are custom-made, and decisions about these components are taken early on.

Design freedom - whether the design can and is allowed to be changed, in combination with the amount of resources available - is highest in the early phases of product development. This means user-centered design methods should be applied early on, which in turn implies that user-centered design skills should be present on the team.

Customer-centered does not equal user-centered
Though in theory any team member could have these skills, the roles that are most likely to provide a product development team with user-centered design skills are usability specialists and interaction designers. I believe the knowledge of usability specialists is not the same as that by product managers or market researchers, as these roles are usually focused on the buyer and not on the user. Their primary goal is to know why people will buy a product, not what properties of human-product interaction will (dis)satisfy the user.

Usability specialists
Setting user-centered requirements is a lot easier if you have first conducted user research. And setting requirements is one of the things that is done rather early. Which means that user research has to be conducted before that. Which means: bring in the usability specialist (or whoever conducts user research) from the start. Secondly, even in the earliest phases of product development usability evaluations are possible, for example, usage scenarios, paper prototyping or cognitive walkthroughs. Usability specialists can provide the team with the knowledge and skills to apply these methods and techniques.

Finally, usability specialists have often witnessed many user tests and have (possibly) acquired a thorough understanding of the user group through previous user research. They should be able to provide input in the early phases of product development (i.e., concept definition, requirements setting), to be able to apply the knowledge they have gained from previous projects.

Interaction designers
Interaction designers should be part of the development team from the start so they can be involved in setting requirements and constraints, because they can anticipate what these will mean for the interaction. Many usability problems arise as a consequence of decisions about a product’s eco-system or technological platform. If the interaction designer is only involved in designing the user-interface, his/her design freedom is extremely limited. Being involved in an early phase allows designers to point out potential problem areas as a consequence of requirements or decisions about the technological platform. And to be aware of these limitations when they synthesize the UI. Both software engineers and interaction designers can tell stories about how frustrating an exercise it is to compromise to oblivion a 'dream design' that did not take constraints into account.

I would shy away from just bringing the interaction designer on board when the actual design needs to be synthesized. To make a good design, you need a deep understanding of the user, the product domain, and technological limitations and possibilities. Having the interaction designer on board early on allows him/her to learn about these issues. It is unlikely that a designer can develop just as good a solution if you bring him/her on board by the time the design needs to be made and simply provide a list of requirements. Designing is just as much about thorough analysis as it is about creative synthesis.

Summary

Because:	Requires:
- Early phases = high design freedom - Early perspective on human-product interaction - Brings experiences from previous user tests - Enables execution of user research - Allows designers to be sensitized to the design challenge	- Early and throughout involvement of interaction designers and usability specialists - Usability specialists and interaction designers present in organization - Fitting product development process - Sufficient staff - Budget

3. Usability 101: Decide whether usability should be a priority for your company

2010-05-28T15:14:00.019+02:00

"That's the whole philosophy of our brand: that it has to be easy to use, for everyone." (Market Intelligence Manager)

Will you benefit?
Implementing a user-centred product development process is likely to require a significant investment in resources, organizational changes and support from upper management. Thus a conscious choice should be made whether usability should be a priority at all. Based on the aforementioned analysis of usability, and of the consequences of usability for your company, decide whether usability should be prioritized. Even if usability is an urgent issue for your products, you should consider whether your company will be able to make the required investment, and will benefit from improving it.

Cost and benefits of usability differ per company
This also depends on your company’s brand position and product position. An established, premium brand may suffer more from dissatisfied customers than a C-brand, and if a company has a high-end product position it will have more resources to ensure design freedom than a company with a fast-follower, value-for-money product position. Also, if your company is still struggling with ensuring product quality or is very much focused on sales numbers and less on customer satisfaction, you are less likely to be able to prioritize usability during development, as other, short-term issues will probably take precedence.

How to make it happen?
This step is about putting your resources where your mouth is. If you decide that usability should be a priority for your company, discuss the requirements that places on your way of working. Are changes to the product development process required? Do you need additional skills in your development teams? And how can each discipline within the company contribute to usability? For example, how can the mechanical engineers or the graphic designers contribute to usability, and how is their work related?

Summary

Because:	Requires:
- User-centred product development requires a significant investment and support from upper management	- Understanding of usability and its consequences to your company - Understanding of the potential benefits of usability for your company - Discussing the requirements for user-centered product development - Understanding the required investments for implementing user-centered product development

2. Usability 101: Analyze the consequences of usability for your company

2010-05-27T15:03:00.018+02:00

"Because at that time it was also decided, somehow, that we decided to keep it as is. As it would not cause any returns. Since this is a just a one time operation." (Usability specialist)

Manifestations and consequences of usability
Based on the definitions, examples, stories and analyses from the preceding step, take stock of how usability manifests itself in your products in:

(1) human-product interaction: quantity and quality of output, errors made (effectiveness), time and effort required (efficiency);

(2) the user experience: underperforming or outperforming expectations (satisfaction about use).

And the consequences that this may have for:

(3) the response of users to the user experience: customer support requests, complaints, product returns, word-of-mouth;

(4) the resulting business performance consequences for your company: financial costs, staff, repeat sales, cross-purchases, productivity, extra equipment required.

Effects are likely to be long-term

Note that, as usability is an intangible issue, the consequences of usability are most likely to be long-term: there is nothing that prevents a product with poor usability from being launched in time, and poor usability may not affect sales performance (at first). However, as usability is about consumer satisfaction, in the long run usability might affect repurchase intent and cross-purchasing, product returns, demand on customer support, and brand perception.

Anticipated consequences influence prioritization
Analyzing the potential consequences of usability is essential, because anticipated consequences of usability play an essential role in the prioritization of usability in a company and projects. The effects of usability can be communicated by means of a quantitative analysis, documenting for example product returns and customer satisfaction scores, but also through videos of user-product interaction or by having product developers and upper management experience their own products.

Summary

Because:	Requires:
- Usability is prioritized if its (business) consequences are understood and visible	- Analysis of what usability means to your company

Related posts on uselog

> Eavesdropped conversations about mobile phones

> Deaths in hospitals due to misuse of equipment

> Sprint launches training for smart phone users (but who's paying?)

> Dutch public transport chip-card system flawed at introduction

> 30% fewer helpdesk calls due to ADSL installation-kit redesign (see picture above)

> How consumers get themselves into (usability) trouble

> Why word-of-mouth might not happen

> Product complexity causes product returns
> UX fund (still) outperforms all other stock indexes