Mo handoffs, mo problems
The first of a two-part interview with UX designer Shamsi Brinn, creator of the No Handoff method
I remember the exact moment when I knew the traditional UX handoff process — when a design is given to developers for implementation — was utterly broken.
Back in 2014, I worked on a large e-commerce project. It involved integrating tablets into cash registers. I helped on a team developing the app that would manage all sales transactions.
The end client hired a very well-respected, well-known design firm to design the app experience. The firm did an excellent job putting together a 150-page-plus document outlining the app’s entire look and feel. That’s the good news.
The bad news? It took them a year to make that design handoff document. A year.
By the time we were handed the document, mobile technology had moved so quickly. Parts of the design were already out of date. And because it had taken a year to get to this point, the client wasn’t willing to wait more months for design revisions.
The previous story is an example of the classic siloed waterfall handoff. But even in an “agile” sprint workflow, the handoff still persists today as the dominant interaction pattern between UX designers and developers.
Even worse, no one has really tried to reinvent the handoff process. Sure, software tools such as Figma or Zeplin help ease handoff challenges — but at the end of the day, it’s still a handoff with lipstick on it. (In fact, I’d argue Big Agile has a vested interest in preserving the handoff status quo, but that’s a topic for another article.)
Over the years, I’ve only seen a few designers and developers propose alternative methods to the traditional handoff, such as Ryan Singer’s Shape Up. In his book, Singer proposes a different interaction pattern between designers and developers, and challenges the sequence of performing design and coding tasks.
Since that fateful story from 2014, I’ve been keeping my eye out for designers — or anyone really — daring to question the handoff status quo.
A few months back, I stumbled upon the work of Shamsi Brinn, a UX designer/manager who runs nohandoff.org. In true Dan Heath fashion, she believes in solving the problem upstream by eliminating the handoff altogether.
Her website launched in 2019, and in that time, she has iterated and refined her thinking on the handoff process through various articles she has published.
Are you curious to learn more about the No Handoff method? I surely was. I recently had the opportunity to interview Shamsi about why the handoff process is broken, and how to fix it.
Nelson: Shamsi, thanks so much for agreeing to talk.
Shamsi: Hey Nelson, thanks for taking the time to talk about project handoff, and how we can do things better! It’s a topic I am really passionate about.
Let’s start off with just learning more about your background. What did you go to school for, and how did you get started in UX design?
I started my journey at art school — Moore College of Art and Design in Philadelphia — where I studied photography and graphic design. I graduated in the early 2000s, as corporate budgets were shifting from print advertising to websites, and my work turned digital almost overnight.
Working on digital projects is very different from the more “traditional” design work I had been trained to do in school, and I quickly noticed that the tools in my toolbox were not adequate for the new tasks at hand. We were building websites around, essentially, client whims — and that was not a good guide! So I initially shifted to UX because I felt that a user-centered approach would help me to build products that had value, that people used, that did what they set out to do. And that was largely true, but of course new obstacles emerged.
What prompted you to launch nohandoff.org? Was there a specific moment that triggered that inspiration, or was it a feeling that just built up over time?
It is definitely a way of working that I have built up over time, with many mistakes and tweaks and shifts over the last decade. I was working at an agency when my thinking began to shift. I had been moved into a project manager position that worked across the design and development teams, as well as interfacing with clients. My mandate was to help design and development work together smoothly. This was a hard role, but very formative for me, because I came up constantly against the negatives experienced by designers, programmers, and clients.
I remember trying many things that did NOT work, including bringing designers into developer meetings, and bringing developers to design reviews. Instead of understanding each other better, it left each team feeling unmoored and like I was wasting their time, which was true though not my intention.
One thing that did work was finding a shared Northstar. Initially that metric came from client goals. When I shifted to a UX management style, then the end user goals informed our Northstar, and that was one of the most important early transformations.
Sorry to interrupt, but do you remember where the idea for a Northstar came from? I ask because where I work (Lextech), a similar idea came up that also helped our clients. But I don’t remember it from a book or a specific source.
Yeah, when did that phrase blow up?! I first learned about it from a manager. She wanted us to simplify, like Facebook had with their monthly active users metric. I love the minimalism of the Northstar, it helps me not get lost in the insane complexity of building digital products.
Got it. Please continue.
There was still a really big gap between the developers and the designers. I didn’t have the vocabulary to name it at the time, but what I observed was two completely different perspectives stuck in antagonistic postures. And each perspective made sense.
What designers experienced is that they worked really hard to understand the user goals and to build a wonderful design that somehow, miraculously, also managed to get the client’s OK. Then — in their eyes — the developers would mess it all up.
What developers experienced was that they would be handed this complicated artifact with little context, not enough specification, a looming deadline they had no control or say over, and an emphasis from the design team on pixel perfection which was the least of their worries.
Meanwhile, the client would naturally have new ideas and thoughts, and the project would be shifting while we had not yet finished coding up the initial design. I feel frustrated just remembering those projects! Our stated goals (meet user needs and business goals) and our process (handoff-based, visual design first) were at odds.
The next breakthrough for me was when I learned about XP. This idea that you build fast, test, learn, and repeat.
By XP, you mean extreme programming?
Yes, that’s right, Extreme Programming. It is the sort of system that at first sounded very complicated, but once we dove in then the cruft fell away and we were left with the power of iterations.
I first implemented XP with the development team, shifting from a “big reveal” style of client interaction to rapid iterations and frequent inputs from the client and users. This worked so well that the dev team quickly outpaced the design team. We would learn about a new functionality that was needed, and the devs would have a rough version in place for user testing before the design team had begun. The downside was that the gap between the teams grew even larger.
So how did you address things because of that growing gap?
I had to question more fundamental aspects of our process: Why two teams? Or, if it turned out we did need two teams, why design first? I began testing a reverse process, handing the client specs to the development team first, then design skinning later. That was more satisfying for the client and we could have stopped there and called it a success. But the resulting websites, though highly functional and cost effective, were uninspired. Too technical, too feature focused.
To a hammer, everything is a nail. So to a programmer everything has a programmatic solution. Both programmers and designers are very creative problem solvers, but the pendulum had swung too far towards programmer-led solutions. We were missing the creative thinking that the design-heavy process brought in the earlier days. We needed to balance the two.
No Handoff addresses that by bringing both product and engineering into the same team, working on rapid iterations and learning together. There are a whole slew of small techniques I employ so that can actually happen, but that is the where and the why of No Handoff.
What are the downsides of handoffs in your view? As a counterpoint, one could argue that the launch of many successful digital projects involved traditional handoffs.
The main downside of handoffs is they are very inefficient. Waterfall is a great method when the specifications are clearly defined and stable. But how many projects do you work on where that is the case? For me, it is none. When there are a lot of unknowns then waterfall is extremely risky, because you are likely to get your first attempts wrong and it takes a long time to go through the whole process to find that out. The engineering world has largely gone ‘agile-ish’ for this exact reason; agile at its core is a risk management practice.
With No Handoff, those practices are enlarged to bring in discovery and design, too. And each discipline brings their own methods and talents, they can spot different risks and offer new solutions, so iterating together on one team is even better than parallel tracks.
No Handoff is simple but not easy. For example, it challenges the tools we have come to rely on in the design field like Figma that have handoff baked into the process. To iterate together we need to speak the same language… and that language is a web site, not Figma boards.
I have to confess, I’ve used Figma a lot, and reading your article about Figma is what got me to discover your web site in the first place. You then wrote another article that talked about functional prototyping, which seems to be a key aspect of your No Handoff method.
Prototyping is key, and if you are not used to working that way then prototyping can feel quite unnerving. For developers too, because you are continually sharing your unfinished, half-baked work in order to learn quickly. It requires vulnerability. That is psychologically very challenging until you get used to it.
You need a surrounding structure that is supportive of a culture of learning, that does not demand the theater of perfection, or false promises to deliver unknown value by an arbitrary date. So it is challenging for business leadership as well.
The company I work for (Lextech) works primarily with business leaders to improve employee experiences. I’m interested in some of those challenges you’re referring to. Can you share a few ways a business can help its product teams adopt a No Handoff workflow?
Definitely. One of the key elements is to foster an atmosphere of trust, where people feel comfortable sharing work in progress and unfinished ideas, or where the bugs are not all worked out yet. That type of culture flows from the top.
Businesses can also offer additional support to their design team, to learn prototyping. Designers may need new training, new tools, or to be paired with a front end dev. These new skills won’t grow overnight; it’s a long-term commitment.
And last but not least, businesses need to support continuous research, user testing, and feedback mechanisms. They might be accustomed to cramming that work into a single design sprint or research phase. But continuous user research needs a different level of support. That’s something business leaders should be aware of and plan for.
I thank Shamsi for taking the time to chat with me. In fact, she dove so deep into talking about the problems with handoffs, that this interview splits into two!
In the second half of our interview, Shamsi talks about how her thoughts on No Handoff have evolved over the years, the feedback she’s gotten from other designers and product leads, and what product teams can do if they’re struggling with handoffs.
If you want to read part two of that article, follow Shamsi on Medium. She has the second half of the interview, so we can share both parts of this interview to a wide audience.
And to learn more about her No Handoff method, visit nohandoff.org.
Finally, what’s your take on what Shamsi said? What did you agree or disagree with what she said?
If there’s a question that I should’ve asked in the interview but didn’t, or want to share your own thoughts about the handoff process, let’s continue our conversation in the comments. Both Shamsi and myself may be able to respond directly to your comments!
Nelson Taruc is a design lead at Lextech, where they help some of the world’s most admired companies end enterprise workflow chaos. With Lextech, employees become more effective, efficient and engaged in the enterprise.
