Best Practice No. 2:
Design First. Firms should not leave user experience to chance. Instead, they should design the user experience and then build a Web site or application that delivers that experience. Design is part art because you have to find that differentiating je ne sais quoi that attracts customers. But design is also part science because there is research on what has worked — or failed — in the past. To design a user experience that is useful, usable, and desirable:
· Serve business goals by serving user goals. The user experience provided by your Web site exists in the broader context of your business needs. Well-designed sites help users do something that furthers the goals of the organization. For example, http://stargate.mgm.com serves fans of the Stargate series of science fiction television shows by letting them explore the new spaceship in the show. It also serves the business goal of showing potential advertisers site usage data proving that fans are highly committed, which means that ads on the show will be worth more.
· Find and grow design talent. Great design requires creative talent that is inspired by a deep understanding of the user, a deep understanding of the business goals, and a deep understanding of all that is possible with technology. That takes either a team of individuals with complementary skills — like visual design, interaction design, and copywriting — or an interactive agency or design firm that can supply a team. Recruiting a team won’t be easy because agencies compete intensely for the top talent. One option is to recruit employees with agency experience with the lure of more regular hours and less travel than agencies can typically offer. Another option is to train internal staff with the right potential by sending them to workshops or courses on user experience design.
· Design for change. Users’ expectations of what is useful, usable, and desirable can change depending upon a number of factors, including cultural shifts, economic realities, competitive offers, and technology. Application developers should therefore design for change by getting insight into how your personas will evolve in the future. Do this by coming up with a couple of future scenarios based upon trends that are in context such as competitors’ announced intentions, technology adoption cycles, cultural shifts, and economic cycles. Then brainstorm about how each of your personas will react to each of these future states. Now evaluate how well your current user experience design can evolve to each of these future visions. When you do this, be sure to evaluate the ability of your technical architecture to evolve as well.
· Know your constraints. Make sure that your designers know their constraints before beginning the design process. Like everyone else, designers are constrained by time and money — but those are not their only constraints. They may also be constrained by the need to fit their work into an existing site that has consistent internal conventions for elements like menu placement and link format. Or, you might have technical constraints like the screen size for a mobile application or an underlying technical architecture that prevents you from supporting certain features cost-effectively or performing adequately.15 For example, providing your customers with a single view of all their accounts might sound simple but could require a million-dollar integration project on the backend system.
· Design for differences. It is likely that your user research uncovered the need to design for more than one persona. That doesn’t mean that each of the user segments these personas represent are equally important to your business. For example, you may want to put more design effort on satisfying users that are the most profitable or users that have the most potential for increasing revenue. Or you may want to focus on attracting a new set of prospective users to your site. Once you’ve assigned a relative importance to each persona, you can use a tool like the persona-based prioritization matrix developed by Microsoft to determine the most important content, features, and functions to include in your site.
· Borrow inspiration from other designs. Design almost never starts from scratch. Most firms periodically review competitors’ sites to see what they’re doing. More forward-thinking companies also look outside their industry to find design ideas that will differentiate them among best-of-breed sites like nytimes.com in media, amazon.com in shopping, netflix.com in entertainment, and fidelity.com in financial services. New design ideas can also be inspired by new technology. For example, application developers can see designs based on innovative uses of Flash at the Fidelity Labs site and an innovative interactive transcript feature used with videos at ted.com.
· Start with low-fidelity prototypes. Starting with paper prototypes to communicate and test design ideas reduces cost and encourages exploration of a broader range of design options. In contrast, starting out by creating slick, detailed designs in Adobe Photoshop or a Web design tool lengthens the early stages of the design process and tends to lock in the first design that’s considered — which probably isn’t the best alternative out of all those available. Additionally, early stage designs that look like a finished product can distract the user from what is really important during early usability tests by focusing their attention on colors or fonts. In addition to paper prototypes, designers should also consider creating wireframes using Microsoft Visio. The wireframes offer some interactivity, don’t look like a finished product, and are fast and inexpensive to modify. Once your confidence in the design increases, you can start to increase the resolution of the design.
Pitfalls To Avoid In Designing First
When designing first:
· Don’t forget to design for all aspects of the user experience. Remember that UX design requires visual design, interaction design, and then usability testing to validate the design. To create a user experience that is useful, usable, and desirable, you’ll need individuals with all these skill sets on the development team.
· Don’t think tools can design for you. Tools can be useful in designing, testing, and developing applications. But giving a business analyst Visio, Photoshop, Adobe Dreamweaver or an assortment of portal templates won’t necessarily result in a great user experience any more than giving a budding writer Microsoft Word will automatically result in the next great American novel. To use these tools effectively, your design and development team will need relevant training and guidance.
· Don’t ignore the user research. Amazingly, many companies commission user research only to ignore it during the design phase. This can happen when the research is commissioned by the marketing department, but then ignored by product development. But it can also happen simply because designers feel threatened by the constraints user research puts on their creativity. For example, one software company created personas only to have the team responsible for redesigning their site stick them in a drawer and ignore them. The resulting design was a failure that drew huge criticism from the company’s customers.
· Don’t lock into a design too soon. Do not commit too quickly to a particular idea. A design team that doesn’t generate at least three viable alternatives at the start of the process isn’t doing its job. Before you pick one of the options, subject it to some user feedback via low-fidelity prototypes, and review it for fit against business objectives. It’s natural to lean toward one of your options, but be prepared to abandon it swiftly if it does not pass user and business case review.
· Don’t rush to write code. Resist the urge to start coding before you have a solid design. Keep in mind the advice of Bill Buxton, author of “Sketching User Experiences,” who said, “. . . the last thing that you should do when beginning to design an interactive system is write code.”
Continue reading this series produced by Forrester Research, by reading onto Best Practice No. 3: trust no one — testing.