Maybe you’ve recently been hired by a company who wants to “do usability.” It could be that you’re a UI designer, business analyst, or front end developer who’s been conducting impromptu hallway usability tests and you’ve started to think you might be on to something. Or perhaps you’re a product manager who’s realized that the key to a better product is a better understanding of the people who use it. Whoever you are, wherever you are, one thing is certain: You’ve got your work cut out for you.
Creating a User Experience (UX) process can be a very rewarding journey; it can also be a nightmare if approached from the wrong angle. Initiating a culture-shift, overhauling existing processes, evangelizing, strategizing, and educating is an enormous undertaking. Often it’s a lonely path the UX advocate walks, especially if you are the only one who is driving that change from within the company. But that path is ripe with opportunities to improve your company’s product creation process, as well as the product itself.
So, where do you start? What approaches work? What pitfalls can be avoided? How can you stay motivated, encouraged, and professionally connected—even if you’re flying solo?
Why Create a User Experience (UX) Process?
Understanding why you should create a UX process is a good place to start. If you’re already in the initial stages of UX startup you probably have a number of answers to that question already. It’s important that you know why using a UX process is valuable because you’re going to be explaining it to everyone. A lot. Many companies are just starting to realize the value of keeping their end users in mind before, during, and after the product creation lifecycle. If your company hasn’t quite figured this out yet here are two of the most powerful arguments you can make:
- A UX process helps build products people want and need
You’ll create a product that’s a good fit for the people who end up using it—instead of for the developer who built it or the CEO who envisioned it. This is particularly important if your users also spend their hard earned dollars to buy your product. - A UXprocess saves time and money
Your team will save valuable time and resources by getting it right, or mostly right, the first time. And they’ll be faster doing it.
Keep in mind that both arguments have a strong tie to something many people in your company already value: Money. Whether it’s money gained through sales or saved through efficiency, financial impact is a very tangible way to illustrate the value of UX activities.
Start Small
Starting small will keep you from biting off more than you can chew, but it also allows you to focus your attention on building your process from the ground up. You’ll be nurturing both your growing process, and the people with whom you work, as you go. A gradual introduction to UX methodologies is much more effective than trying to completely change everything about the existing process all at once.
If you attempt to immediately overhaul the existing process you risk overwhelming, intimidating, and offending many people who could otherwise be turned into UX allies. So pick a smaller, less visible project where you can start integrating new techniques while showing your team how to build products with your users in mind.
Be sure to document and track the progression of UX activities and outcomes so that you can use that information in the future to illustrate how your process works.
Find Business Drivers and Track Against Them
Simply put, numbers talk. Find out what your company’s goals are and align your UX goals accordingly. When you know what’s driving strategy in the finance group, or what targets the marketing team is aiming for, and you can show how your work helps achieve those goals, you’ll be speaking their language.
For example, if one of the primary initiatives company-wide is to reduce costs by reducing the number of tech support calls, make one of your primary UX goals for the next release improved usability and a higher rate of self-support. Get a current baseline for how many tech support calls are being received on the current product and at the end of your project do a comparative analysis for the reduction in tech support calls.
Plan UX Activities Upfront
Another great reason to pick a smaller project is that it’s more likely you’ll have some influence on the project planning. By working with your project manager in the early planning stage you’ll be able to prepare the team for the UX activities you will be leading. If you don’t show up early and stake a claim to the dates and gates on your project, you’ll end up squeezing your research and design activities into a process that already exists—without you.
Ideally, you’ll plan an ideation phase or “iteration 0” where you help clarify business requirements by researching the real people who use your product. Iteration 0 may include some initial conceptual design work as well. When project iterations begin, you’ll have negotiated what sorts of UX activities are going to take place as you move from one iteration to the next.
Go Deep, Not Wide
A common pitfall to avoid is spreading yourself across too many projects. If you’re the only person doing UI design and usability research, it’s tempting for project managers to want you to consult on all of their projects. Avoid this at all costs.
Distributing a single UX resource across multiple initiatives is destined for failure for two reasons.
First, by working broadly across many different projects, you compromise the quality of your UX work. You run the risk of producing mediocre results on many projects, rather than doing a great job on one or two projects. You need strong examples of success, especially if you’re trying to convince others why a UX process is valuable.
Second, you will rapidly become burnt out and frustrated because you never have the opportunity to impact any real change. When your role on a project is limited to someone emailing you for your opinion, or briefly running an idea past you without any deep contextual understanding of the project, it won’t take long for you to become disillusioned. Your role on a project needs to be more than just providing the UX seal of approval.
It’s difficult to find the balance between advocating a UX process and having to say no to some projects. You may feel like you’re delivering a mixed message because one day you’re explaining how important UX activities are and the next day you have to say no to a project. But here’s the twist: As demand increases, it provides more support for growing your UX team. Every time you have to say no in order to keep your focus deep, remind those around you that it’s a sign you probably need more UX resources.
Be Realistic and Flexible
Do a reality check and figure out how much support exists for UX activities in your organization. Then adjust your expectations accordingly. If many of the people with whom you work are new to the concepts of user-centered design and usability testing, then you probably won’t be able to spend months on ethnographic research or thousands of dollars flying around the world to conduct elaborate usability tests on site.
Stay flexible. Make your points and recommendations, but show that you can see all sides and are willing to compromise as needed. Avoid dogmatic thinking that says there’s only one way to correctly do usability research or design. At this stage it’s less important that you do everything by the book, perfectly, formally—and more important that you integrate the user’s perspective to make your product better. Keep your idealism in check and introduce people to UX methods gracefully instead of beating them over the head with it.
If you’re a perfectionist you may feel like nothing is being done the right way at first. There will be a lot of kinks to iron out before your UX process runs smoothly, so try to go with the flow during this awkward stage of your evolving process. Remind yourself that the smallest amount of UX activity is light years beyond no UX activity at all. In this early phase, even the smallest bit of user perspective can have a profound effect on the outcome of your product.
You’ve heard it a million times before: There’s a lot of low hanging fruit. Don’t get too caught up in worrying about how it’s being picked, just make sure it gets picked!
Watch Out for Toes, but Don’t Avoid Them
It’s inevitable that, over the course of building a UX process, you’ll bump into others who feel you’re encroaching into their area of contribution or expertise. No one wants to hear that their way of doing things results in a bad product or the company losing money. No one wants to hear you telling them your way is right and their way is wrong.
The key is to show, rather than tell; persuade, rather than dictate. Use a screen/video capture tool, such as Morae, to make video snippets of users struggling with that widget everyone on the team thought was so cool. Convince your developer that you can make her job easier and save her time by doing the conceptual design and sketching out some prototypes before she ever starts writing a line of code. Show your product manager that you can help him define his business requirements by talking to end users and finding out what their needs really are.
Once you’ve built credibility with the team and have diffused any potential rivalries, you’ll all be on a level playing field. Then they’ll look to you for your perspective, input, and expertise rather than being threatened by it.
Be Patient and Set Clear Expectations
Being patient can be one of the hardest things about building a new UX process. It doesn’t matter how committed you are, how many hours you work, or how persuasively you evangelize…it won’t happen overnight. It’s important to set realistic expectations with others, as well as yourself. Set clear, attainable goals with your manager at your yearly review. Review those goals together quarterly and make adjustments if needed. Communicate openly about deliverables and milestones with your project manager and other stakeholders. Then deliver.
With every expectation you meet, or exceed, your case for the UX process will be building momentum. Visibility and understanding will increase with every win you publicize. But be patient.
You’ll probably have days where you question whether you’re making a difference, whether you’re making any headway at all. You’ll have days where you feel frustrated and confused. When you start to question the impact you’re having, remind yourself how far you’ve come since the pre-UX days.
Get Creative
Because you’ll almost certainly have limited resources, it pays to get creative. Show your team that UX activities do not need to be expensive or time consuming.
- Is anyone in your company a representative user? Grab them and schedule a feedback session on your wireframes. There’s no need to recruit strangers to help with usability research unless your end users are highly specific and there are no representative users available.
- Do you need global perspectives but have no budget for travel? Conduct remote contextual interviews and usability sessions. Webcams and online software such as WebEx and UserView make it easy to connect to users all around the world and gather valuable information from them.
- Have you been told there won’t be a budget for hiring more UX professionals in the next few years? Teach your developers some UI design best practices, show business analysts how to conduct usability tests, lead participatory design sessions with your team. If you know you can’t hire more UX practitioners, start teaching others how to make good UX decisions.
- No budget for expensive software and research tools? It’s amazing how much you can learn using paper, pencils, pens, and sticky notes. Learn more about paper prototyping and guerilla HCI.
- Email video clips from usability sessions. This is always a great way to spread the UX message because it’s hard to argue with the real live people who are shown using your products.
- Make posters showing common UX mistakes and great UX solutions.
Document Your Wins, Then Publicize Ruthlessly
This is probably the most important thing you can do to sell the value of UX within your organization. This is where you put it all together. You’ve focused deeply on a small project, planning and tracking UX activities from beginning to end. You understand what’s motivating your company and you can show improvements in the user experience that support those goals. Because you measured the user experience of your original product against the new product your team just built, you can prove how much better the new product is for your users. And you can clearly tie those improvements to the UX process your team employed during the project.
Once you have one UX win, no matter how small, that you can clearly map to your process publicize that story ruthlessly throughout the company. Be sure to credit the entire team for their role in the UX work that contributed to the project’s success. And get ready for more work to come your way.
Amy, great article. I agree with all of it. I personally have the hardest time with “Go Deep, Not Wide”. I’m a perfectionist by nature and it’s hard to say no to something when it clearly needs design help. But I’ve learned the hard way (over and over again, in fact) that less is more. I’d rather work on fewer projects and really dedicate myself to them then try to touch everything and not be satisfied with any of it. It just takes discipline and lots of it.
This is an amazing article. Serendipitously I have found myself in a position where I can directly apply many of the lessons of this article. I work for a large company with many large and small projects. We have recently discussed improving our usability process and I have been tasked with the implementation. I will be keeping your article in mind as I do so.
Perfect timing!
This is one of the best articles I have read on B&A in a while. I have recently found myself in a “pioneering” role, and truly appreciate these succinct and actionable pointers from an author who obviously has deep first hand experience with the subject matter. Thanks Amy!
Amy, great article. I too have walked this lonely road (with some success0, but it continues to be an uphill climb. Good to know that I am not alone. Thanks.
Very good article, though I disagree with one part of it (more on that in a moment). Very good point about tying to business drivers, and the deep vs wide distinction is critical — at the end of the release, you need to have visible wins, and going wide hurts your chances of that. The point I disagree with is this, “Your team will save valuable time and resources by getting it right, or mostly right, the first time. And they’ll be faster doing it.” I don’t really disagree that this is true, but I disagree that it’s a useful argument. Most companies are worried about THIS quarter, not next year. And the time saving payoff for doing good design isn’t immediate — good design takes more time and effort than bad design. I think telling stakeholders that this will save a lot of time… in two years… can do more harm than good. The other thing that I think is important to emphasis during the evangelism phase is that by including customers in the design process you help to build buy in for the product even before you ship it, which can include customer references that you can market as early as the day you release. This can make a big difference, and it’s something that The Powers That Be can easily get their heads around.
Terry,
Thanks for your thoughts on this article–it’s great to get some additional perspective from another UX practitioner who’s spent time in the trenches. 🙂
I can’t say I agree with the argument that presenting time/$$ savings would “do more harm than good” when advocating a UX process. In my experience it’s always been one of the biggest selling points. But you do have to present those claims carefully. A critical component, as I mention later in the article, is managing expectations. Being honest with yourself about the level of acceptance for UX methodologies at your company, and on the team, is important. Take small steps first, on less risky/visible projects if necessary. Clearly communicate throughout the entire process (especially when you’re in the very early stages of introducing these new concepts). And then connect the dots for everyone so that they really see and understand the time/$$ savings.
If you have past experience proving the ROI of UX activities it’s a great way to show exactly how your process has worked before. If you don’t have a case study in your back pocket, find one–there are many examples of how a UX process has saved other companies time and money, online and in many of the great UX books out there.
One to check out is Cost Justifying Usability, by Bias & Mayhew: http://tinyurl.com/36836g
In the end, I think much of it comes down to communication. (As with much of life, I’ve found!)
It’s funny, but often I find myself observing and analyzing the user experience of my own team and company–and applying a similar approach to my teaching/advocating as I use in my research and design of a new product. I talk with my coworkers to find out what the current process is, how they feel about it, what’s working and what isn’t (contextual research, requirements gathering); I test the waters and explore different ways of applying these methodologies (conceptual “design”, user validation); and I document how the process worked before and what the effects are after adopting a UX process (baseline evaluation, comparative results reporting). Sometimes, it almost feels like a process within a process. 🙂
One great point you make is that UX activities serve as an excellent PR opportunity! In hindsight, I might have added that as another argument to be made in favor of a UX process. Talking with customers serves multiple beneficial purposes. You gain an understanding of your end users and ultimately build a better product, but you also get to start making a positive impression on them before you’ve even built that product. People really take notice when a company cares enough about their experience to ask them what they think. It’s win-win for everyone. Excellent comment, thanks for adding it to the conversation.
Here’s a shorter, hopefully fully active, link to the Bias/Mayhew book: http://tinyurl.com/36836g
Giving this a little more thought, I suppose organizational maturity is the deciding factor on which way to go. I completely agree with you that what you want to avoid is UX being seen as a cost center. That’s an unpleasant place to be. We want to (accurately) be seen as a revenue generator and/or cost reducer. In fact, a few years ago I did a presentation about UX ROI where I made both those points – I used “non-defect” (i.e. usability) in-field problem reports to show how much money we spent on usability problems and I used market intelligence data to show that improving UX market drivers would increase revenue by specific amounts. It was very effective… for that particular team. But (like many people) I’ve also worked with teams that think that future service costs are either a) someone else’s problem, or b) something we can worry about after we get the code out the door. Future cost savings arguments went over like a lead balloon with those folks.
Thanks for the interesting article and discussion. Now if I can just figure out a way to remove those strikethroughs from my previous comment….. hmmmm, is that a functional defect or a usability problem? =)
Excellent article, and good advice. My mantra has been “add value”. Think about what you can do that adds value to developers, marketing folk, technical support, and so on. By asking yourself (honestly) whether you can really make an almost inarguable improvement, don’t do it. By only acting where you know you add value, you build positive memories in people that are a basis for further cooperation in the future.
Basically, this is the “low fruit” you talk about. In a more mature situation it’s harder to make obvious improvements, but in the early stages (and in many companies these “early” stages could be many months, if not years) you can really benefit from being perceived as a problem solver rather than a hassle. Someone who makes less work, not more.
And good luck to everyone taking this on!
I found this article particularly timely – so thank you Amy! As someone in this position now, many of the things written ring true.
Many good points, especially the wrap-up about promotion after the success is achieved.
I’ve gone through the evangelism and department building process more than once, with mixed results, but have learned each time. The one thing that really helps moves things forward is establishing yourself as a credible resource that can deliver on the plan. Once your organization believes that you are truly a subject matter expert on the topic, they become more inclined to support you. Some things that I’ve found help on the credibility front include:
having implemented a similar process elsewhere
reading/writing articles and books
Good article, Amy and B&A Staff. It is always important to remember how to evangelize the IA and UX practice. I have found that lately our community (we) have been focusing on Enterprise IA or IA/UX for major projects, but, what about small projects? What about small-to-medium businesses that are just learning what IA/UX means? Or don’t have an idea of what IA/UX is?
In my case, I work for a non-profit organization. I have introduced these new concepts onto their project management methodologies, but it has been a very tough road. A major roadblock was that my clients were used to work with Business Analysis documentation and deliverables, and I had to modify my IA/UX findings to look and read like BA documents. While I found this frustrating, I understood that, I had to speak their language first before they speak mine. Now, my documentation is looking more like IA/UX deliverables, but like I said, it took some time to achieve this.
One of my best days at work was when my supervisor (PM) was training a new employee and she was introducing IA/UX methodologies to the new team member. That’s when I knew I was making a change!
Keep up working on evangelizing our profession. While I feel that large corporations know about it, we still have to educate small-to-medium businesses about IA/UX methodologies and the ROI of implementing them. Like Seth said: “Often times, it’s more about the person than the process.”
Amy, you say many important things here. Thanks for an excellent review. However, the first of your two arguments, “A UX process helps build products people want and need,” while true, is not always convincing. This is because the CEO or developer or product manager who dreamed up an idea usually believes that this IS a produce people want and need. Why hire a UX expert just to tell them something they already think they know?
Napoleon put it well when he said, “There are two levers with which one can set a man in motion – fear and self-interest.” Hence, if the CEO or developer is accountable to somebody (or some body) higher up, you can play the fear card quite successfully – “What if people DON’T want or need the product you are promoting? I can help you make sure your product becomes the success you envision.”
Another card you can play is “UX is the key to getting your innovation process moving.” Most companies these days get all starry eyed when they hear the word “innovation.” And true innovation ALWAYS solves a problem. If not, so-called “innovation” will invariably create a problem. And the CEO doesn’t want problems. It’s a back-door kind of approach, but it can be effective.
Sorry to sound so crassly political here, but these are often political decisions. And while money is always an important consideration, contributing to the personal success of the stakeholders is usually more compelling.
Great article. Very timely for me. As some people already commented I also have a problem with the “Go Deep, Not Wide” part. I was hired to start a UX process, and it is implicit that I don´t get to say no to projects. In spite of that, I have one small project in which I´m paying special attention.
Like everyone else, I was very impressed with your article. Our company is going through the beginning stages of UX implementation, and I reviewed your article with my team. We agreed with every point you made, with one minor caveat. You recommend starting small, and we agree in principle. When working with a wide variety of corporate groups like business and IT it’s essential to get buy in by showing the value of UX in small projects. We wouldn’t have a chance of changing established processes without complete buy in.
However, we had the opportunity to manage and implement a large web project with an external consulting firm, and only required minimal participation from our own IT department. This allowed us to bypass the established processes for our first project. The advantage was that we were able to use the video from usability testing and the results of the successful website to show the value of UX in a project. That got us buy in from upper management, and opened the door to using UX in smaller projects within the existing processes.
So far this has been very successful. If you have the chance to show how UX can work outside the constraints of exisiting processes, then its potential is available for everyone to see. Of course, the expectations are high too, but that’s a much better “problem” to deal with than fighting to gain acceptance.
Thanks for the great article!
I’ve just recently started a new UX practice in a rather large company and can agree whole-heartedly that there is a great temptation to go wide very fast. Having made a significant impact very early, the desire to have me involved in every new and on-going project is great. There are ways to get involved on a wider spectrum with limited resources, though. What we’ve done is focus on developing an internal process and create guidelines for future projects to adhere to. There’s also a recognition internally for the need to increase the resources that are dedicated to UI design and usability. Fortunately, I’ve benefited from being in an environment where the need is apparent and the company is enthusiastic to adopt the practice.
Great article, again very timely – this is exactly the position I’ve been in for the last few months.
“Because you measured the user experience of your original product against the new product your team just built, you can prove how much better the new product is for your users.”
Quick question: How can you ‘document wins’ for a new product on which you’ve been implementing UCD from the start? This is the 1st time the company I’m consulting for has used this process, when it’s launched (to great success, I hope!) how can I prove / demonstrate how much of it’s success is due to taking a user-centred approach, rather than it simply being a great proposition that would’ve succeeded anyhow?
A good look at the subject with maybe a bit too much stress on the loneliness. Not all UX processes are created by individual UX practitioners. For a look at how a 10-person UX team created its process in a web/software development setting, have a look at these resources:
The slides from my 2005 IA Summit presentation “StUX – integrating IA deliverables in a software development methodology” at http://www.peterboersma.com/blog/2005/03/my-ia-summit-presentation-stux_10.html
An article in ASIS&T Bulletin of Feb/March 2005 on the same topic, titled “Introducing User-Centered Design to an E-Government Software Development Company” at http://www.asis.org/Bulletin/Feb-05/boersma.html
And if you don’t have time to read it all, remember only these lessons learned:
– Don’t copy our diagram/deliverables; the value is in creating your own, with your people
– Set up your own standards team; a few motivated people with some spare time is all it takes
– This should scale up & down; the only limitation is paper size, and that can be fixed by taping pieces together
– It will take time; brainstorming, consolidating, documenting, deciding on name conventions, endless tweaking to make it clear, promotion, etc.
Wonderful article and insight! I think anyone who has been in this space for a while has been in the position of being the “first marine on the beach” when it comes to proposing UX as integral to a company’s success. I’d add a few comments though (what a surprise!).
You mention motivators early on when you talk about users spending their hard-earned dollars to buy your product. It’s also important to be aware if those dollars can easily be spent on someone elses product. I’ve found that reminding people that the competition is a click away get’s their attention.
Another advantage to starting small occurs when there is a shorter horizon for results. The sooner you can get those numbers, the better. Your example of call-center improvements is a good one. Sometimes just analyzing and revising or eliminating error/alert messages can move the needle on service levels pretty quickly.
Deep vs. Wide as you say – difficult, especially when you see so much opprotunity for involvement. The drawback to too much breadth is that you’re prevented from making all but the most cursory assessments. Later on you discover some probelms that might have been avoided if you had the time to carry your thinking to conclusions that were just a few more questions down the logic path. That doesn’t help your cause.
Promoting UX is a double-edged sword. It’s often hard to draw a direct cause/efect relationship to UX improvements and product success. Claiming a win is a little like Sherlock Holmes’ deductive reasoning mantra; eliminate everything else and what you’re left with is the answer meaning, all things being equal, if the only thing done differently was the inclusion of UX practices then that must be the reason for success. Unfortunately, that’s not usually the only thing done differently on any given engagement. That, said it’s still possible to take a bow when the numbers come in. By the same token, it’s also possible to divorce yourself from the failures which goes back to what I think is part of the real difficulty in acceptance; Accountability.
UX practioners, unlike business owners, don’t usually have P&L responsability for the products they work on making it easy to be marginalized. As Seth G. points out, it can be the person more than the practice. If you can establish yourself as a trusted advisor, you can build that influence.
I like to say that the buy-in is a process of evolution vs. revolution. You can logiaclly explain the benefits of UX to someone but the minute the heat gets turned up on a project, they run back to what they know. But, if you can foster UX involvement to a conclusion that is supported by success, people begin to get it, have faith in it and stop questioning the need for it.
this was a great point in a terrific piece, and i can speak to personal experience with making it work:
“For example, if one of the primary initiatives company-wide is to reduce costs by reducing the number of tech support calls, make one of your primary UX goals for the next release improved usability and a higher rate of self-support. Get a current baseline for how many tech support calls are being received on the current product and at the end of your project do a comparative analysis for the reduction in tech support calls.”
yes, yes and yes: make the support staff and their heads your friend; they ***already know*** the ui issues and online stopping points that are generating the most calls; if you can present them ways to eliminate the top 5 banes of their existence, they will turn around and demand that it be done asap … i’ve been there and done that and it was totally roi based and sailed right on thru; and it was deeply cool when the changes were made and the calls dropped
Amy, great insight. I am the “new” and only UX’er at my job. Some of the points you make will help with my formulating arguments for changing the current inclinations… I hope. 😉
thanks for this awesome article, amy. as a developer who is now at a new position in a very small company who is being enstrusted with all things UX (almost literally), your comments really help – especially the “be realistic and flexible” section. i tend to have a lot of self-doubt because i don’t have formal training/education (but i do have a passion for it and fair amount of practical experience in the methodologies), so i often get a little frustrated and overwhelmed at the prospect of creating a process and putting it into place, since the organizations i’ve worked for in the past have had varying levels already *in* place when i started. that said, however, your article gave me a lot of encouragement, and i really appreciated the statement that “the smallest amount of UX activity is light years beyond no activity at all.” thanks again!
Dear Amy, having devoured your article in minutes I found my self pondering on your key points.
What I found quite interesting is the fact that you, at most times found yourself in a pioneering role, well Amy, “get use to it”.
We are only a handful in this lonely planet, the www allows us to propel our thoughts and innovations in the UX role, thus, enlightening end users to live with the satisfaction of a harmonious UXD.
Without going into much clasified details about some of my IA/UXD roles I can truely say that there is no definative answer to “Wide Vs Deep”, as you too have identified the key points of the arguement I feel that up and coming IAs can benefit from the fruits of our labours too. KEEP READING PEOPLE!