An Open Letter To The Design Community
I hope that everyone that reads this knows that I am one of the biggest advocates in our industry for user experience. Because I generally work with the CEO’s, VP Product, and product managers of technology companies, I am probably in the best position to explain to them the importance of user experience design in coming up with great products. I am not a designer, and I don’t have a design agency I’m trying to sell, so they know I have no personal interest other than I just want them to create better products.
Over the past several years I’ve put together a pretty strong business case for user experience (UX), and one consequence of working with me is that most of the time the companies immediately try to embrace the role of UX. The companies I’ve worked with have opened hundreds of jobs, I’ve personally helped place dozens of designers, and I constantly advocate for the inclusion of design in the process of product creation.
That said, I could use a little help.
When these companies hire designers, most of the time the results are immediate and unmistakable. But sometimes there are bumps in the road to better products, and often these bumps are caused by designers either inadvertently or mistakenly falling into some common traps.
Here are the major areas where I often see problems:
Know Your Audience(s) – As designers, you basically have three key audiences. Your colleagues in design and product management; the users you’re designing for; and the execs and other key stakeholders. Please understand that these are three very different audiences, especially your execs. To be specific, don’t try to show taxonomies, concept maps, site maps, task analysis grids, design process maps and even wireframes to execs. These tools are all useful for designers, but not for execs. Please trust me when I say they will only serve to freak out the execs. They might humor you and try to look impressed, but then they call me and complain that they have no idea what you said, what the heck you are doing, and now they’re really nervous, and I have to talk them off the cliff. Please people, if you want to succeed at your company, just remember this rule: the only thing that works to explain your design to execs and stakeholders are prototypes, the higher the fidelity the better. Do yourself a favor and keep the sausage making within the design team. Some execs will want to know how you got from here to there, and that’s okay, so long as you start with them understanding where “there” is. Note that this doesn’t mean that you can go dark on your execs for extended periods of time.
Be Sensitive To Change – when your company does finally decide that user experience is important, please don’t come back and propose to your management a three to six month design phase of contextual inquiries/ethnographic research, persona development, concept mapping, undirected user testing, heuristic reviews, and competitive analysis, etc, all before you can get to something they can understand. Now, I happen to be fans of each of these techniques, but you need to be smart about how you introduce these techniques to the process and the organization. The key is to separate out the baseline customer learning activities (which should be ongoing and in the background), from the project specific work. And with customer learning, when introducing this into the organization, look for some quick wins, and always share generously what you’re learning about your customers.
It’s About Customer Learning – people tend to think of UX as usability, but usability is typically the easy part, and, for example, calling it “usability testing” understates the importance and role. You’re responsible for much more. In general, you want to position “User Research” and the UX team in general as the resources that enable rapid and continuous customer learning. You’ve got several tools to learn about customers, some qualitative, some quantitative, some based on prototypes and user testing, some based on split testing and analytics. But it’s all about facilitating rapid and continuous customer learning.
Time To Step Up – the design community has long argued (rightfully) that you need to be included from day 1, but this means that your job is not simply to design pages based on what comes down from the Product Manager in the form of “the requirements.” It’s your responsibility to help figure out what the product needs to be, and this means the requirements. If you tell the product manager to come back once he makes up his mind, you are severely limiting your ability to contribute, and very likely condemning the product to mediocrity from the start. The product manager is ultimately responsible for the decisions as to functionality, but you need to help the product manager identify what’s really required and what’s not. This problem is especially common when the designer comes from either a very waterfall process background, or an agency that is used to doing work based on contracts and not starting anything until the requirements or at least a creative brief is defined.
Role Confusion – at many companies, when I first start working with the execs, they don’t understand the difference between the types of designers. Often, they just have one person (usually a visual designer) in the role and they complain to me about the effectiveness of the design. I find it important to explain to the execs the difference between interaction design, visual design, and user research. Mostly the designers at the company are grateful as they have often been arguing that the company needs to hire either an interaction designer or a visual designer, but it was falling on deaf ears. Sometimes we need to be creative to come up with an effective mix of skill sets. I recently visited with an interaction designer friend of mine at his startup, and he was showing me some of his work and while I knew him to be a very strong interaction designer, his visual designs were always pretty weak. But this stuff was great work. I asked him how that happened, and he confessed to me something interesting. He said that he had a visual designer friend that was at another startup, and that she was in the opposite boat; she had strong visual design skills but never had any training in interaction design. So they worked out a nice little arrangement. He helps her with the interaction design of her projects, and she helps him with the visual design of his projects. The result is that they are both producing much better designs for their startups. This was possible because both of these people were honest with themselves on their skill sets, and they both appreciated what the other could contribute. There are of course some designers that are very strong at both interaction design and visual design, and while I think this is worth striving for especially in senior designers, in my experience this is pretty rare.
Titles – usually one of the first actions a company takes after I engage with them is to start to staff a UX capability. So the execs start searching but they quickly get confused with the potpourri of titles. Honestly it just makes the UX community look like it doesn’t have its act together. From my perspective, we need to pick our battles, and this isn’t one of them. I’ve long ago adopted Alan Cooper’s titles of “Interaction Designer,” “Visual Designer,” and “User Researcher.” I occasionally use the title “Product Designer” for those few that really can represent the holistic design of the product – including interaction design, visual design and sometimes product management as well. Most of the confusion is with the various predecessors and derivations of interaction designer, including old titles like “information architect,” “human factors engineer,” “UX designer,” “interface designer,” “UI designer,” “user interface architect,” and “user interface analyst.” Same problem with “usability engineer,” “usability researcher,” or “usability designer” when talking about user researchers. I am glad to see our industry finally standardizing on “User Experience” for the design organization as a whole. If you’ve got one of these old titles and you want me to help you get a job, you’ll want to use switch to the standard title. Again, I didn’t pick any of these names, and you could split hairs on any of them, but let’s please not waste our energies there.
On the subject of prototype testing:
– always make sure the product manager and interaction designer is present, even if you have to drag their ass to the test. If you’re one of the few people left that still think these people should be sheltered from the actual user you need to either get with the program, or get out of the way because you are hurting your company. Sorry to be so harsh but this is too important. I have seen too many product managers that read your report, and discount your findings because they assume either you are an idiot, or the people you brought in for testing are idiots (or both). Make them watch.
– realize that the moment of greatest learning happens after the usability testing portion of a prototype test. At this point, the user actually understands what you’re trying to discuss with them, and you can have great dialogs. So don’t over script this. Allow the product manager to interact with this user and see where the conversation goes. You just might discover a pivot that changes the course of your company.
– an informal e-mail with key learnings and results sent the same day, is much more valuable to the team than a formal report sent a week later. Don’t bother with formal reports – your time is too valuable for this and they’re hardly read anyway.
– except in very rare cases, don’t propose a round of usability testing just before launch. It’s a no-win situation as it’s too late to do anything about the problems you find. Do your testing in the first weeks of the project, using prototypes, when the results can actually be used. It’s okay to test again after the launch using the live product.
– not everyone will agree with me on this, and it’s the subject of a future article, but I no longer waste time testing paper prototypes or wireframes on users. Just as they don’t work with execs, they just aren’t very useful with users. Push the team to get a high-fidelity prototype as fast as possible. The tools have never been better so it’s not hard, and most importantly, that’s when the real learning begins.
I know that for many of you I am preaching to the choir. But if not, I hope you take these pleas to heart, as they are all meant to help you succeed at your company and enable user experience to be viewed as absolutely central to continuous customer learning and product innovation.
A special thanks to designers Jeff Herman, Kyrie Robinson and Audrey Crane for their feedback on early versions of this article.
