Don Norman said once in a lecture at the I-School that if the HCI people aren’t part of the product planning, then their value is actually lost (*paraphrased). Possibly, in the past year or two, the importance of user experience (UX) design is rising to its appropriate place in entrepreneurship circles and startup teams.
As a community, we are realizing a trained designer with a diverse skill set goes beyond the placement of buttons and the creation of CSS sprites. We UX designers now come prepackaged with the features to help inform the product roadmap (if not manage the product), work closely with software developers, and contribute to sales calls and client visits. We are a diverse breed because at the crux of our skills is not only the know how to make things look pretty and function properly, but the ability to empathize with our users’ problems and to understand people – we need to specialize in both innovative product design and functional accommodations for user experience.
Today, I found myself writing an essay-of-a-response to an interesting blog article from Cooper, a design and strategy firm in San Francisco. Tim McCoy wrote in “Lean UX, Product Stewardship, and Integrated Teams” how UX designers are finding their place in start-ups, flexing their diverse skill set, and effectively contributing to lean development team. I had a few pieces to contribute that went beyond the maximum permissible (in my opinion) characters of a good comment, so here I share with you.
McCoy posits that traditional UX methodologies were developed in waterfall environments, which we can all agree upon because almost everything regarding software development began in the waterfall environment.
In the past decade of my education and career, user-centered design rose to the challenge of modern software development techniques by being inherently iterative. Research, design, develop (Lo-Fi Testing), research, design, develop (Hi-Fi Testing), research, design, develop (Alpha/Beta). My design project from the iSchool (circa 2006), LightsOn, made it to 3 iterations before the final project was due; we only had to test with 3-4 potential users each time. As I left graduate school, it seemed we were ready for agile environments, but developers and engineers were not ready for us.
It’s a combination of multiple facets that has prepared us for this meeting point where:
- The users have a stronger voice, demanding better experience
- There are enough designers to meet the call of duty
- The developers and engineers understand where their skills end and a designer’s begins
So what can we designers do to improve our downward dog, be agile and flexible, and meet the demands of a fast moving software development team? In response to McCoy, I detail a few techniques that I use to apply myself effectively to my teams and have seen implemented at a variety of top start-ups:
- Involve developers and engineers in your process: Your teammates are more likely to value your user personas and user feedback if you actually explain to them who the users are. Some of my teammates have told me they really don’t care, “just get me the requirements”, while others have joined me in developing activity diagrams, data requirements and new design ideas. There’s a reason this advice is emphasized across the best product design books and blogs; it’s critical.
- Become a partner in design: In line with #1, if an interaction or data requirement is outside of your expertise, it’s a great way to involve the developers and engineers in your work. Ask, “Is this interaction even possible? Can we implement it this way?” Explain why it has to be done that way, and negotiate a solution. Be partners in design. The worst thing for you to do is to design a new feature, hand it to a developer, and, then find out the implementation is technically impossible. You just wasted a week, and probably another.
- Test with anyone, at first: You need to define user experience to be able to accommodate it. In one project, I put together a simple lo-fi prototype to test the intuitiveness of a new feature’s interaction. I met with one of our sales representatives for 1-hour; the meeting revealed a list of design changes, as well as new ideas given her experience with the product. You don’t necessarily need a representative from your user community to get valuable usability feedback – your product should explain itself, not rest on inherent knowledge of experience. Sketching user experiences, and a variety of user experiences at that, will help you see how a range of people will interact with your product.
- Ignore LOUD users: The worst thing a company can do is adhere to the complaints and demands of a few loud users. A business-side employee pushed through a new feature that permanently locked text notes because one client did not trust his employees to make edits. It was a PR disaster. We rolled back that change in less than 24 hours, took 1 month to rethink and research, then relaunch.
- Cultivate a strong relationship with Customer Support and Community Leaders: It’s really simple. The people on the phones everyday with the users know why the users want the changes they have requested. They are always my first step when researching a new feature request. When your product design is user-centric, as any good designer will make it, then who else can better tell you the needs of your user-base?
- Learn the Basics of Objected-Oriented Programming and Database Structures: My 4-5 semesters between undergraduate and graduate school did not make me a trained software developer, but understanding 0…* relationships and class diagrams, as well as being able to speak in “if”, “else”, “while” and “for” gave me the tools to walk the bridge to my teammates’ side of the chasm. If you can, take a ux design course – they can be invaluable in teaching you the basics that will allow you to much more efficiently communicate with your colleagues.
- Take a Tip from Business Development: When you start a new business, you value your first few customers more than any others. You never raise their fees and you service their requests in a timely matter. They repay you in recommendations and referrals. Do the same with a handful of users that you keep in touch with. Politely call them with questions about new features and bugs; it’s cheaper than running community-wide surveys and less intensive than deploying poorly designed features and processing all of the complaints.
- Teach Nielsen’s Usability Heuristics: I’m a firm believer in Jakob Nielsen’s Usability Heuristics and the Heuristic Evaluation. After running a project with 90% of my coworkers with my last employer, we all shared a common language to discuss new product features.
- Develop a Style Guide: Marketing and Advertising departments have style guides for the way the company logo can be used, so you should maintain one for the way the software should function. It maintains consistency, and becomes the de facto guide for any developer left to their own design-devices. They detail the shape, size and color of buttons, whether a link should open in a new window versus the existing window, and how the navigation system should function across all levels of the site hierarchy. Remember; consistency is the definition of good product design. You don’t want to end up with a product that looks like it was designed by nine different people; it will do nothing but confuse your end-user.
- Finally, be well rounded. What makes me good as a designer is that I have tried a little of everything: I’ve pressed send on marketing e-mail campaigns, designed logos, built websites, and met with customers to up-sell them on products. Creative product design is my core skill, but in an agile environment, I can fill in on any team that is lacking a particular talent.
A good product has a firm foundation in good design, and a good designer has to be flexible to the needs of their market. Knowing when and who to listen to may not always be the most intuitive skill, but it’s one I’ve found invariably pays off dividends down the road. For more thoughts on the matter, McCoy posted a slide deck that addresses even more ideas for integrating with a lean environment: