Pie-Jacking and Other Tips for Making Engineers Tolerate UX

Obviously, I find UX to be incredibly important. And these days, I’m finding more and more people who agree with me. Unfortunately, in many organizations, there are people who still feel that user research and interaction design slow things down or aren’t really necessary.

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 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!

An Agile Alternative: Embedded Design

Last week I wrote a blog post about a depressing example of non-agile design. This week, I'd like to show you an alternative method of design, along with some examples drawn from my experiences. This is not, by any means, a new concept, but hopefully I can convince a few people who still think that agile development and interaction design don't go together.

I've worked as a designer and user researcher with agile teams on several different projects. The trick is that, instead of doing all the research and design up front and then throwing the work over the wall to the engineering team, the designer stays embedded with the team throughout the entire development process.

How does an embedded interaction designer help at various stages of the development process?

Strategy and Product Definition

At this stage, your designer (or design and research team, if you’re well-funded) should be out talking to potential users about their problems. A designer at this point in the cycle can help you define who your customer is, learn how potential customers are currently dealing with the problem that your product solves, and come up with a small set of crucial features that will solve those problems better.

Could a great product manager also do some of these tasks? Sure, and they should definitely be involved or even leading the process. But, in my experience, being involved at this stage allows me, as a designer, to really understand the problems I’m going to be solving and the people for whom I’m going to be solving them. In other words, to have a successful design process, I will have to know all these things anyway, and participating in the earliest stage of research is the most efficient way for me to learn them.

Example:  One company with whom I was working wanted to add a new feature that would allow users to play music while interacting with the product. From our discussions with users of the product, we knew that people were already doing this, but in a way that caused them all sorts of issues and made many people unhappy. We interviewed current users about things like:
  • How they were currently using music with the product?
  • What benefits did they get from using music with the product?
  • What major problems were they having with music? 
We also looked at the quantitative data that we had about what sort of music was being played, how much people were likely to pay for it, and  what percentage of people were active music users. The answers to all of these questions helped us come up with a new concept for music that would solve many of the problems and add some fun new benefits


I don’t have to go over this one, right? You need a designer at the design phase. You could always let your engineers design all the screens and the interactions, of course, but that strategy often goes very, very badly. (not always, of course, but I’ve seen more disasters in this area than I care to remember…)

Besides, if you’re building in a Minimum Viable Product in an agile environment, the design phase itself can be quite short, since the designers tend to stay only a couple steps ahead of the engineers.This means that there is often considerable overlap between the design phase and the development phase, rather than a clear delineation between the two.

Example: When working with a couple of different agile teams practicing scrum, we would start our design process one or two sprints ahead of the development team. When the engineering started, the developers generally started work on the back-end processes, giving us a little more time to get the user facing designs ready.

A side benefit to this approach was that the engineers had a much better idea of what they were going to be building, since some design was done, and they could give better time estimates for their tasks and make better decisions about product architecture. On the other hand, since they didn't need to wait for a "full" design to be done, they could begin development in parallel with design and speed up the whole process by a matter of several weeks.


Your next question might very well be, “What good is a designer during the development phase?” Well, if you've started your design phase only a sprint or two early, the chances are that your product is not completely designed. And it shouldn't be! Things change during the development process that require design changes, especially when you're constantly getting feedback from real users on the work in progress.

Things also change during the design process that have nothing to do with users, of course.

Example: I was working on a fairly large, important feature that had a lot of user interaction. We were at the point where most of the back end work was done, and we had created a well-tested user interface and visual design that engineers were busy implementing.

Every so often, an engineer would come to me and say, “This thing you’re asking me to do will take 3 weeks. Is it worth that?” When that happened, I could sit down with the engineering team and go through our options. Sometimes the piece was so critical to the experience that we had no choice but to forge ahead with it. Other times, we were able to find a solution that was almost as good (and sometimes better) that would take significantly less time to build.

The most important thing was that having a designer on the team at all times allowed us to make those choices with a full knowledge of how they would affect the final product. It let us make smart, fast changes to the design without losing the overall vision.


I know that QA isn’t always its own separate phase of the product cycle, but at some point, I hope that somebody’s looking for problems in your product before your customers find them. Having an embedded designer at this phase is extremely helpful, since whoever is looking for bugs needs to know what’s a bug and what isn’t, and the person who is best suited to answer that question is the person who designed the thing in the first place.

Example: I can’t tell you the number of times I’ve had a bug that an engineer marked as “as designed” that I've had to bounce back to them with the comment, “Well, I sure as hell didn’t design it that way.”


If there’s ever a time it seems like you could do without those pesky designers embedded on a team, deployment is that time. After all, what is there left for a designer to do?

Plan for the next version, of course! Once the product is in the hands of your customers, it’s the best time to start gathering metrics, observing users, and coming up with the next set of features for the product.

Also, keeping your designers embedded on a particular product over several versions or product cycles allows them to really get to know the users, the product, and the projected feature roadmap. Designers can help make sure that any new updates, features, and bug fixes remain consistent with the core product and don’t contribute to drift.

You Missed Something

“Hang on,” you’re thinking, if you’re paying attention. “Didn’t you miss the part where you test your designs?” I did not. In my mind, iterative testing is part of all the phases of the project. You should be constantly getting feedback of one sort or another on your designs to make sure they’re usable to your potential customer. User feedback isn’t a separate phase. It’s built into all of them.

Time Commitments

One question that often comes up is whether having an embedded designer means that that person has to be dedicated full time to one, single project. Well, it really depends, but in most cases I’d say no. The design workload on a project tends to wax and wane, depending on the phase.

Obviously, the research and design phases can be resource intensive, but the others often require much less time, which can free the designer up to work on other projects simultaneously. I’ve often been on a project full time during the research and design phases, and available for meetings and questions for several hours a week during the development and QA phases.

The most important thing is that there should always be an informed design resource available to handle the questions and tasks that can come up at any point in the project lifecycle.

Tell me your stories about agile or non-agile design in the comments. 

Enjoy the post? Follow me on Twitter!

A Depressing Example of Non-Agile Design

I recently had a really depressing experience. I was asked to work on a very cool application that focused on my favorite subject. That’s not the depressing part. That part was awesome.

Despite a lot of misgivings, I agreed to use the waterfall development process and design a lot of stuff up front, because that’s what the client wanted. Don’t get me wrong. They were doing some development work on the back end, but the goal was to figure out the entire application UX and feature set, wireframe it, and get a visual design done before starting work on anything customer-facing.

The application was quite large and had several different areas. I specifically designed it so that many of the features were modular, which meant that the development team could leave out whole chunks of the UI without ruining the application. They could then add more feature modules in as they finished them, which would theoretically allow them to launch as soon as they had just a few modules finished. Even though we were using a waterfall method, I didn’t want to design something that had to be absolutely 100% finished and built before it was usable. Basically, I was giving them the option to be agile in their development process, if they chose to, even if everything was designed up front.

After a few months of design, we had a great product roadmap, a list of features we ideally wanted in version 1.0, a list of features that would be acceptable for 1.0 (still FAR more than a MVP), lots of fully interactive wireframes, a gorgeous visual design (not done by me, of course), and a lot of data ready to go on the back end. We had also burned through our design budget, so I turned everything over to the developers and moved on to other things.

After several months, the very first version of the product shipped. This is the depressing part. It included exactly 0% of the original design. That’s right. Not a single element I’d designed made it into the first version of the product. Unfortunately, because all the design work had been done up front, I had no idea why the company made the decisions they had made. Of course, if I had been involved with the project all the way through, I could have stripped down the design in a way that at least tried to stay true to the original vision of the product. Instead, it came across as something that had never really been designed at all.

Oddly, there’s a part of me that’s happy that they did what they did. After all, they ended up releasing a MUCH smaller version of the product than we had originally envisioned. I’m not sure if it’s a Minimum Viable Product – only time will tell if it’s viable, after all – but it has many fewer features than we originally envisioned.

But, in another way, I’m sad. If I could have convinced them to go this small at the very beginning of the project, I could have designed their Minimum Viable Product in a lot less time, and, I think, with a lot better result than they got doing it on their own. More importantly, we could then have worked together to build out new features based on learning from the MVP, and we probably still would have had some design budget left to eventually implement that gorgeous visual design.

I guess my lesson from all of this is that I need to be stricter with companies who want a giant, fully fleshed-out product all designed for them at the beginning of the process. I need to be clearer that they’d be better off designing something very small and immediately implementable and then working from there. And I need to encourage them to spread the design budget out over a longer period of time so that they are never left without design resources. Either that, or I need to let go of my designs once they’ve been handed over to the client and acknowledge that they get to do (or not do) anything they want with them. I just find that really depressing.