The no-handoff method: bridging design and code

Project handoff is often compared to throwing your work over the fence for the next team to catch. Handoff is a near-universally recognized period of inefficiency and frustration. While user-centered frameworks like Agile have broken down barriers between development and the end user, in practice the divisions between designers and programmers still persist.

It’s part of a larger societal pattern of fragmented thinking. That it’s led to fragmented web development teams is not surprising, but a shift to a more integrated mental model challenges many of our standard operating procedures. However the rewards are literally endless and lead to overcoming many false barriers we often take for granted to create truly integrated teams.

In the teams I work on I am innovating an agile method of building websites I simply call no-handoff. Building on the fundamentals of Lean UX, Dual Track Agile, and Minimum Viable Product (also see Jussi Pasanen’s fab diagram), the no-handoff method is anther logical step for designers adapting to agile thinking.

The problem to be solved:

Stop throwing our work over the fence! Credit: canitbesaturdaynow.com

Web Development teams are complex and include multiple disciplines. For many teams the miscommunications between designers and programmers are a particular point of inefficiency. Iterative workflows often end up looking, as Marty Cagan puts it, a series of “mini waterfalls” rather than a truly collaborative process. It is more efficient than traditional waterfall but there is still a handoff, that perilous period where you throw your work over the fence and hope someone is there to catch it.

I think UX project management can solve this issue, but there is a piece missing from our current public discourse. Cross-discipline communication in the UX sphere has mainly focused on two areas:

  • Improving the available toolkit and moving to programs like Invision or Sketch (good toolkit overview by Tridip Thrizu, “API design is UI design“, UXDesign.cc).
  • Or being smart and creative in our communication techniques (Rachel Andrew, “Working Together“, Smashing Magazine).

Both approaches offer valuable insights into improving how we work, but neither new tools or improved communication techniques address the underlying problem: that there shouldnt be a rift between designer and programmers in the first place. The no-handoff method tries to address the root issue and offers a framework for integrating UX, design, and development.

So what is no-handoff?

Below is a project diagram illustrating a recent no-handoff project and how each discipline’s involvement ebbed and flowed as the project progressed. Exact levels of involvement and specific phases will shift depending on the project, the critical factor is that all members are involved from start to finish.

no-handoff integrated team chart

The brilliant designer Alan Hori once told me that art and graphic design have nothing in common. But after years in the trenches I find that I dont agree. I think they share almost everything in common. To take this further, so do all disciplines in the organic process of development. I began my professional life in art and graphic design, then learned development, and lastly took on UX project management to try and reconcile the two. Ive focused on overcoming some of the falsely manufactured barriers my teams face when bridging disciplines. No-handoff is the result, an agile method for more fully integrating cross-functional teams.

These three steps help teams make the mental shift, build a shared vocabulary, set shared goals, and select a shared primary communication tool.

1) Shared vocabulary and banishing “design”:

Have you ever played the classic game ‘Taboo’? The first step on a no-handoff team is to throw out the word “design” from your project vocabulary, and making it a game is a great way to kick off.

The words we often use to discuss design are limited in their usefulness — developers probably dont need to think about gestural marks, nor do security specialists need to mull over the proper amount of negative space — but the goals of design are universal. Reaching users with a message, evoking a response, providing a positive experience, are things we all care about.

Ironically banishing the word “design” leads to better design. When all team members, including web designers and UI specialists, can discuss the work based on its user experience implications then the team will be speaking a shared language.

For example “Hows the design coming along?” becomes “Are you finding that this navigation reduces frustration for users?”, or “What is the rationale behind the signup form coming before the gallery in the wireframe?”, and “Tell me how this toggle element supports user goals?”.

2) Shared UX goals:

The second step is to set team-wide goals framed in terms of user experience. Design is a shared goal, and so are Security, Accessibility, and all Functionality. Framing each discipline’s tasks around UX from the very start makes clear that the north star for the entire team revolves around the user, everything else is just a tool to get there.

Many agile teams already employ user stories for this purpose. Setting UX-focused OKRs is a great practice. The technique is not as important as the goal.

3) Living wireframes:

Last, but most important, is using living wireframes from the very beginning. In our no-handoff projects we no longer use Sketch, InVision or similar mockup tools. All interface reviews are done in-browser with an interactive, responsive wireframe.

This doesnt mean to aim for final, polished interfaces. On the contrary, embrace minimum viable interfaces, build lo-fi, and gain as much feedback as you can with minimal effort from front end development.

Selecting a front end framework that will help you rapidly prototype should be one of the first steps you take. There are so many options, from the popular Bootstrap, to the minimal Bulma, to the open source Fomantic-UI. Your organization may well have it’s own framework. The only criteria is that it supports fast wireframing and prototype development.

Both front end and backend develpers will work on the same prototype. There is literally no handoff, the wireframe will just organically evolve and gain fidelity as the project progresses.

Front end developers take on a more prominent role and get involved much earlier in the process than in a “traditional” project. On my teams I encourage designers to also learn the basics of using the front end framework to knock out layouts and cut out the middleman. Working prototypes or wireframes immediately leapfrog right over so many potential issues, leverage their power to communicate from day one and the skip the design tools altogether.

Blurring lines and roles

As the painter Mary Corse wisely says “I think as time goes on, physics discovers what artists are already painting or doing.” Similarly, I think web development is slowly discovering techniques designers have employed for millennia. Artists sketch, in web development we rapidly iterate. Artists seek beauty, we seek to minimize user friction.

A painter fills and builds up detail over time, just like in the no-handoff method there is no strict division between lo-fi and hi-fi wireframes. We start simply and move towards our shared goals, refining as we go. All kinds of lines are blurred, including divisions between when sketching ends and refinement begins. There is no point at which the project is handed off from designers to programmers.

The role of UX guardians

UX in a no-handoff project needs to be touched on a little more in depth. Briefly, UX and user-behavior is the thread that runs throughout the project. In the no-handoff approach “UX” is not a team, a task, or a function. Most importantly user experience is not someone else’s problem. The purpose of UX is improved user behavior. And what influences behavior on the web? Everything! UX is a shared goal that the entire team strives for together.

There should be an individual or team that focuses on UX. I use the term “UX guardians” to distinguish between the team and the shared goal. A UX guardian’s job sometimes looks like a project manager and convener, sometimes like a user researcher, sometimes like a evangelizer in chief, and always as an enthusiastic resource. It is the role of the UX guardian to cast the wide net of user feedback and retrieve results from many sources, sort and filter and communicate their findings and share them effectively.

The UX guardian also ensures that backlog lists are consistently groomed and oriented towards reaching those goals (Im using Scrum terms, but the concept translates to any agile process).

Like all roles in a no-handoff project the UX role is iterative. As projects progress there is more to test, more user data is gathered and insights gained, and the criteria for meeting goals may shift and backlog lists be adjusted accordingly. What remains constant is that each project phase and all changes throghout are viewed through the lens of the end user experience. UX guardians do not make all decisions, not at all, but they leverage their expertise to keep the focus of all team decisions on the end user.

Conclusion

Collaboration is the biggest challenge for any project, or any human endeavor for that matter. We have deeply entrenched ideas about disciplines, roles, and hierarchies to overcome and the no-handoff method will challenge teams in some new ways. More integration is coming further into the light, especially seen in Agile’s increasing emphasis on collaborative teams.

The ability of the UX guardians to communicate the universality and central importance of user experience promotes integrated thinking and unites team members around shared goals in an organic process without false handoff requirements.

Project handoff is compared to throwing your work over the fence for the next team to catch, and is a period of inefficiency and frustration the world over. While user-centered frameworks like Agile have broken down barriers between overall web development and the end user, in practice the divisions between disciplines like design and programming still persist.

It’s part of a larger societal pattern of fragmented thinking. That it’s led to fragmented web development teams is not surprising, but a shift to a more integrated mental model challenges many of our standard operating procedures. However the rewards are literally endless and lead to overcoming many false barriers we often take for granted to create truly integrated teams.

In the teams I work on I am innovating an agile method of building websites I simply call no-handoff. Building on the fundamentals of Lean UX, Dual Track Agile, and Minimum Viable Product (also see Jussi Pasanen’s fabulous diagram), the no-handoff method is anther logical step for designers adapting to agile thinking.

The problem to be solved:

Stop throwing our work over the fence! Credit: canitbesaturdaynow.com

Web Development teams are complex and include multiple disciplines. For many teams the miscommunications between designers and programmers are a particular point of inefficiency. Iterative workflows often end up looking, as Marty Cagan puts it, a series of “mini waterfalls” rather than a truly collaborative process. It is more efficient than traditional waterfall but there is still a handoff, that perilous period where you throw your work over the fence and hope someone is there to catch it.

I think UX project management can solve this issue, but there is a piece missing from our current public discourse. Cross-discipline communication in the UX sphere has mainly focused on two areas:

  • Improving the available toolkit and moving to programs like Invision or Sketch (good toolkit overview by Tridip Thrizu, “API design is UI design“, UXDesign.cc).
  • Or being smart and creative in our communication techniques (Rachel Andrew, “Working Together“, Smashing Magazine).

Both approaches offer valuable insights into improving how we work, but neither new tools or improved communication techniques address the underlying problem: that there shouldnt be a rift between designer and programmers in the first place. The no-handoff method tries to address the root issue and offers a framework for integrating UX, design, and development.

So what is no-handoff?

Below is a project diagram illustrating a recent no-handoff project and how each discipline’s involvement ebbed and flowed as the project progressed. Exact levels of involvement and specific phases will shift depending on the project, the critical factor is that all members are involved from start to finish.

no-handoff integrated team chart

The brilliant designer Alan Hori once told me that art and graphic design have nothing in common. But after years in the trenches I find that I dont agree. I think they share almost everything in common. To take this further, so do all disciplines in the organic process of development. I began my professional life in art and graphic design, then learned development, and lastly took on UX project management to try and reconcile the two. Ive focused on overcoming some of the falsely manufactured barriers my teams face when bridging disciplines. No-handoff is the result, an agile method for more fully integrating cross-functional teams.

These three steps help teams make the mental shift, build a shared vocabulary, set shared goals, and select a shared primary communication tool.

1) Shared vocabulary and banishing “design”:

Have you ever played the classic game ‘Taboo’? The first step on a no-handoff team is to throw out the word “design” from your project vocabulary, and making it a game is a great way to kick off.

The words we often use to discuss design are limited in their usefulness — developers probably dont need to think about gestural marks, nor do security specialists need to mull over the proper amount of negative space — but the goals of design are universal. Reaching users with a message, evoking a response, providing a positive experience, are things we all care about.

Ironically banishing the word “design” leads to better design. When all team members, including web designers and UI specialists, can discuss the work based on its user experience implications then the team will be speaking a shared language.

For example “Hows the design coming along?” becomes “Are you finding that this navigation reduces frustration for users?”, or “What is the rationale behind the signup form coming before the gallery in the wireframe?”, and “Tell me how this toggle element supports user goals?”.

2) Shared UX goals:

The second step is to set team-wide goals framed in terms of user experience. Design is a shared goal, and so are Security, Accessibility, and all Functionality. Framing each discipline’s tasks around UX from the very start makes clear that the north star for the entire team revolves around the user, everything else is just a tool to get there.

Many agile teams already employ user stories for this purpose. Setting UX-focused OKRs is a great practice. The technique is not as important as the goal.

3) Living wireframes:

Last, but most important, is using living wireframes from the very beginning. In our no-handoff projects we no longer use Sketch, InVision or similar mockup tools. All interface reviews are done in-browser with an interactive, responsive wireframe.

This doesnt mean to aim for final, polished interfaces. On the contrary, embrace minimum viable interfaces, build lo-fi, and gain as much feedback as you can with minimal effort from front end development.

Selecting a front end framework that will help you rapidly prototype should be one of the first steps you take. There are so many options, from the popular Bootstrap, to the minimal Bulma, to the open source Fomantic-UI. Your organization may well have it’s own framework. The only criteria is that it supports fast wireframing and prototype development.

Both front end and backend develpers will work on the same prototype. There is literally no handoff, the wireframe will just organically evolve and gain fidelity as the project progresses.

Front end developers take on a more prominent role and get involved much earlier in the process than in a “traditional” project. On my teams I encourage designers to also learn the basics of using the front end framework to knock out layouts and cut out the middleman. Working prototypes or wireframes immediately leapfrog right over so many potential issues, leverage their power to communicate from day one and the skip the design tools altogether.

The role of UX guardians

UX in a no-handoff project needs to be touched on a little more in depth. Briefly, UX and user-behavior is the thread that runs throughout the project. In the no-handoff approach “UX” is not a team, a task, or a function. Most importantly user experience is not someone else’s problem. The purpose of UX is improved user behavior. And what influences behavior on the web? Everything! UX is a shared goal that the entire team strives for together.

There should be an individual or team that focuses on UX. I use the term “UX guardians” to distinguish between the team and the shared goal. A UX guardian’s job sometimes looks like a project manager and convener, sometimes like a user researcher, sometimes like a evangelizer in chief, and always as an enthusiastic resource. It is the role of the UX guardian to cast the wide net of user feedback and retrieve results from many sources, sort and filter and communicate their findings and share them effectively.

The UX guardian also ensures that backlog lists are consistently groomed and oriented towards reaching those goals (Im using Scrum terms, but the concept translates to any agile process).

Like all roles in a no-handoff project the UX role is iterative. As projects progress there is more to test, more user data is gathered and insights gained, and the criteria for meeting goals may shift and backlog lists be adjusted accordingly. What remains constant is that each project phase and all changes throghout are viewed through the lens of the end user experience. UX guardians do not make all decisions, not at all, but they leverage their expertise to keep the focus of all team decisions on the end user.

Web development is an organic, creative process

As the painter Mary Corse wisely says “I think as time goes on, physics discovers what artists are already painting or doing.” Similarly, web development is discovering techniques that designers use in their creative process. Artists sketch, in web development we rapidly iterate. Artists seek beauty, and in web development we call it minimizing user friction. A painter fills and builds up detail over time, similarly in the no-handoff method there is no strict division between lo-fi and hi-fi wireframes. We start simply and move towards our shared goals, refining as we go.

All kinds of lines are blurred, including divisions between when sketching ends and refinement begins. There is no point at which the project is handed off from designers to programmers.

Conclusion

Collaboration challenges our deeply entrenched ideas about disciplines, roles, and hierarchies. But, as seen in Agile’s increasing emphasis on collaborative teams, its not just becoming the norm it’s an operative necessity.

The ability of UX guardians to communicate the universality and central importance of user experience promotes integrated thinking and unites team members around shared goals.

The no-handoff method is an organic process that helps designers and programmers integrate and stop throwing their work over the fence.

Leave a Comment

Your email address will not be published. Required fields are marked *