Apples-to-Oranges or Apples-to-Pears?

That software developers and user experience designers see things differently will not come as a surprise to members of either discipline.

In part, this is due to a cultural shift in the way we make interfaces: from the earlier “usability engineers” to “user experience designers” now, implying a shift from the science of research, based in engineering, to the art of design. With this shift came specialization, as the disciplines that developers and designers belong to moved gradually farther apart while working on the same projects.

But are the two really so far apart? Both groups, clearly, have “skin in the game,” and I’m going to make the argument that developers and designers should engage each other during the development cycle more meaningfully, and earlier.

For this article, I’ll define user experience design—with intentional simplicity—as a process of iterative problem solving, a means to an end.

In its outline, then, this process of design seems compatible with software development; however, at the top of mind for a developer, there might be concerns about hard constraints, deployment timelines, edge cases, for instance. And between concepting and building, software development sometimes has a hard break in its middle. So when and how do these two groups meet and take advantage of what they have to offer each other?

Connecting Through Process

Teams will benefit from a foundation of shared experience in usability testing. Here, the designer, whose work it is to envision possibilities, and the developer, who implements that work, have valuable partners in each other, like the left and right hands. Usability testing, furthermore, has the ability to bring the ground level truth of each team to the other.

Developers can’t hope to understand how users interact with a front-end without being in on a usability test because even the best instrumentation can only provide data in need of context. Often designers are well-equipped to provide that context, and a usability test is the best place to see the implications of context at work with the project. For example, a designer draws from that discipline’s unique cognitive lens when she administers a Task Load Index assessment, which measures the burden on the user during task completion—a piece of information that might turn out to be important.

But if designers grasp the context of users, developers help define what’s possible. Informants often generate new ideas during testing, enunciate previously unspotted needs, or uncover edge cases. If developers are present, then they become aware earlier of which solutions are being proposed, and have the opportunity to chime in, help determine the feasibility of proposed development directions, and create awareness of latent efficiencies. Developers can help designers to test prototypes and concepts drawn from usability testing “in the wild” in short sprints.

Whether it’s the developer learning something new about her users, or the designer becoming aware of hard constraints in the back-end, for both teams there’s a benefit to moving a siloed piece of information into a shared process. Together, teams can cut time between deployments through conserving and guiding production efforts.

To accommodate this shared effort, the members of the process should embrace some essential values:

• Reach out earlier in the project, as soon as the teams are formed, even.
• Create the space for dialog by inviting counterparts to relevant meetings.
• Share  accountability for the product and never “hand off” as a means of shedding responsibility.

The meetup talk "Engaging Engineering Teams in Design" by Josh Teague was the inspiration for this article. Thanks to him for a great talk.