Sometimes, those people are engineers. Not always, of course. I’ve worked with lots of engineers who are very excited about the idea of good design and getting user feedback. But occasionally you run into groups of engineers who have yet to be convinced.
In the interest of achieving harmony between the Engineering and UX departments at your company, here are a few tips for convincing people (especially engineers) of the value of user research and design.
To be clear, I am in no way suggesting that you trick engineers or lie to them or manipulate them in any way. I’m working on the assumption that engineers are frequently extremely logical people who just need evidence that things are useful before they buy in.
Involve Them in the User Research
The number one way to get anybody excited about user research and UX is to get them involved with it. Too frequently, the only thing about user research that engineers get to see is a thirty page paper detailing all of the problems with their product. This is boring, painful, and easily ignored.In my experience working with dozens of companies, the single most powerful tool for getting engineers in touch with users was having them sit in on a few usability sessions. The sessions didn’t have to be formal. I’d just put the engineers in chairs in the back of a small conference room and have a participant use the product in front of them.
Without fail, the engineers started to understand the pain that their users were feeling. And, since engineers are not monsters, they wanted to help those people. They would fix bugs they observed during the sessions. They would ask for advice on how to improve screens that they had previously thought were just fine.
Most importantly, the engineers would suddenly understand how different they were from their users! Suddenly, it became much harder for the engineers to believe that they had all the answers to their customers’ problems, since they had seen that they were really quite different.
Work in Parallel
One of the valid problems that engineers often have with design is that they feel that it keeps them from getting to work and compresses their schedules. After all, if product management has decreed that the product must be out by Christmas, every week spent on design is a week that the engineers are not writing code.
Now, I’ve written before about the ways in which design can actually speed up the development process, but it’s true that inserting a long design process between product definition and engineering can extend a project.
So, don’t do that. Start the research and design process while product management is still determining the features. In fact, good UX practices and customer research make feature definition much faster and more accurate. Then make sure that you’re working with the engineering team so that they can start building parts of the design before it’s done.
Look, I know that you want everything to be pixel perfect before you show your design to another living soul. Get over that. You need to get engineering involved with your design process for so many reasons, not the least of which is that they can actually get started building it, if they have some idea what’s coming.
Give Them Useful Deliverables
Ever written one of those three hundred page design specs? The one that you have to update every time anything changes? The one that has highlighting in seventeen different colors meant to indicate which design changes are new and which were made for version 4.3.2.4.3.53 of the document? STOP. FUCKING. WRITING. THOSE.I’m sorry to channel Dave McClure there, but seriously, those sorts of things make me homicidal, and I don’t blame engineers for hating designers who create them.
What is a useful deliverable? Interactive prototypes are great, since they show the engineers exactly how things should work. Once you’ve got an interactive wireframe, you can make a few notes at the bottom of each screen explaining anything that might be confusing or any edge cases. Index cards with specific design tasks are also super useful in an agile environment.
Another thing that’s useful as a deliverable is your time. In other words, don’t dump a spec on engineering and then run off to another project. Make sure that you’re around to answer questions and troubleshoot problems that come up. Being available to answer questions for engineering makes their development process go much faster and prevents simmering resentment and anger when they can’t figure out why you designed some stupid animation that’s going to take them three weeks to debug on IE6.
Understand Their Criticism and Respect Their Time
Hey, you know that really complicated design you created with eighty seven different edge cases, each with its own gradient and scalloped corners? Yeah, somebody has to implement that, and it isn’t you. When engineers push back on your design work, it’s not always because they’re tasteless heathens. Sometimes it’s because what you’ve designed will cause them no end of pain and suffering for relatively little benefit to the user.Listen to their arguments and be ready to compromise. I’m not saying you should accept crappy, stripped down versions of your designs. I’m saying work together to come up with good, usable alternatives that will deliver value to the user without causing anybody in the engineering department to have a nervous breakdown.
Show Them How Good Design Prevents Rework
Remember those interactive prototypes I talked about? Those are great for demonstrating how iterating in the design phase keeps engineers from having to constantly change what they’ve already built.Here’s how it works. First, you build some interactive wireframes of what you would normally have engineering build. Then, you run a usability test and catch any problems with the design. Maybe you’re such a fabulous designer that you never catch any little issues in your usability testing, but the rest of us mortals often find stuff that can be improved and fine tuned.
Then, you fix the wireframes and iterate as many times as you need to until you have something that people like. Let the engineers watch the testing process. When the engineers get the wireframes, they’ll see all the changes you made in the design phase that they won’t have to make in code after shipping.
Speaking from experience, try to refrain from smugly saying, “You’re welcome,” at this point.
As a Last Resort…Pie-Jacking
I am not proud of this last method of motivating engineers, but it’s probably the one that has worked the best for me. At IMVU, I will admit that I frequently resorted to bribing engineers with snacks.This not only made it so that the engineers were happy when I walked into their area (as long as I had a chocolate chip cookie in my hand), it also lured them to presentations on UX, usability testing sessions, and other design related activities. “Let’s go to Laura’s brown bag,” I imagine them saying. “What’s she talking about?” “Who cares? She brought cookies!” I would then talk about UX for as long as it took them to eat the cookies. Note: bring a lot of cookies.
It got quite blatant. Engineers had a lot of autonomy about what they built and released at IMVU. A well-timed pie ensured that my features made it to the top of the list. This happened so frequently that they started referring to it as pie-jacking the development process, which is considerably less dirty than it sounds.
I guess what I’m saying is that building bridges between Engineering and UX is important. If all else fails, try bribery.
Like the post? Want more like it? Follow me on Twitter!