Developers and Designers Can Pair Too

Plenty of people are talking about how organisations should capitalise on design, yet few are talking about the practicalities of what it looks like to actually deliver it. Pairing developers and designers removes the natural suspicion between them, is fun, easy, and presents value to customers faster, making businesses—and teams—happier.

Problem

For digital projects, ‘speed to market’ is often hailed as the be-all and end-all metric, but we think this isn’t quite right. Instead ‘speed to value’ is often a more accurate measure of what organizations are setting out to achieve.

Developers and designers are often contributors on the same projects, but it’s unusual to see them actively working together, despite them both working towards the same goal of providing value to their customers.

This is a missed trick.

Just as two developers might pair, developers and designers can (and should) pair too.
Tweet this

Charles Korn (developer's perspective): 

The first thing that struck me when I first started on a project with a designer was the fact that they were never there, which made it very difficult to implement their designs. Even the simplest questions required a painful series of emails and phone calls back and forth which stretched what should have been a two hour task into an ordeal spanning many days.

This slowed our progress and led to us avoiding getting their input for all but the most important details. Even worse, because we were communicating via Photoshop mockups, we were often unaware of the context behind the design—the ‘why’—and so had to make assumptions about how to implement features rather than understanding the intent of the design.

 Greg Skinner​ (designer's perspective):

It all began in a meeting with the client: familiar territory for a designer. We’d prepared a few comps in Photoshop, they looked good. There was a good balance of negative space, the typography was clear, and the affordance to click stuff was high. Winner, we thought. The client opened the mobile mockup on her phone as a full-screen pdf. She started touching it. Nothing happened. Aha. Those comps had taken ages, nudging pixels and choosing the right shadows.

Some little tricks you can’t even do on the web. We needed a way to give the client a realistic flavour of what to expect. We sat there and looked blankly at each other for a moment. Surely someone can do an online thing that kind of does stuff when you push the buttons?

We need developers.

And so the pairing began. It wasn’t really pairing to begin with, it was more, “I have a problem, can you help?” which is humbling for me to ask. But soon, the developers started asking questions as well. Who would use this? Why should it be like that? How do you know? Another “Aha”. They had a problem of their own: not enough exposure to users.

Maybe we could help each other out. Then it became pairing.

The idea

Pairing developers and designers is a part of creating cross functional teams that should be called out as especially useful in the fast-paced technology environment in which businesses find themselves.

Too often we see that designers are tempted to create pixel-perfect visions and chuck them over the wall, with developers comfortable to take them without question so long as that pesky designer doesn’t start poking holes in their code, leaving the BA  to sheepishly mediate and the QA enraged and confused. How siloed! Time and time again we see these consequences are amplified when each role is played by different third parties who are just delivering to contract—not collaborating to provide value to the customer.

Nuts and Bolts

Developers and designers come to a project from different angles, which means sometimes pairing a developer and a designer looks like normal developer pairing, but sometimes it doesn’t.

Earlier in the project, there might be a teacher / student relationship as each begins to get to know the other, but that’ll change to a driver / navigator soon enough. This applies to more than working at a computer: it also works with activities such as running collaborative design, usability research and testing.

It’s good to talk to users throughout all stages of the project—before you get started, during the project, and even after it’s done. For these cases, the driver might be the designer—their empathy and experience around getting the right information out of the user is crucial. A developer makes an excellent navigator: this also serves as an opportunity for them to get to grips with what the customer is really after and the technology to suit it.

On the other hand, when it comes to the code beneath what the user sees, the developer makes the better driver, with the designer navigating, relaying the findings from research and using her skills to guide them both towards the best user experience.

Then there’s collaborative design, which is about getting key stakeholders’ ideas out there and filtering the best ones into the product. Either developer or designer can drive this with the other participating, but both can call out opportunities or scenarios to the other. It’s good to alternate in these sessions too, ensuring you get the most out of your stakeholders and customer research.

There are plenty of scenarios that are usually associated more to one role than the other yet either can drive or navigate. Having both a developer and a designer in the room leads to better results, as their distinct perspectives combine to produce a result that neither would have been able to create independently.

Results

But does this actually work? In projects we looked at where developers and designers had paired or worked closely, results were faster: value was delivered to the customer more swiftly (one example to check out is the Woolworths innovation lab).

This didn't mean it was perfect first time, but because both minds understood the task (they'd both seen the code and the user), they could iterate faster and respond sooner, which ties in with Agile’s utility in responding to change.

Iterating directly in working software reduces waste—core principles from Lean and Agile—because Photoshop comps aren’t working software.

However, like anything, it doesn’t make sense in every situation: we’re not advocating designers navigating a systems migration in COBOL, or developers driving the typography weight for your wordmark. 

Charles Korn, developer

A major breakthrough was getting our designer in the same building as us. This shortened the feedback loop to minutes instead of hours and enabled us to produce a more polished product—all of a sudden, we were able to get their thoughts just by swiveling around on our chairs. Furthermore, the fact that they were sitting right there with us meant that they were involved in informal discussions and were able to provide their input into the decisions we made. We even started to pair with them - rather than getting their designs and turning them into code, they could just sit with us as we brought the design to life in living, breathing code. This also allowed them to develop an understanding for why some things were quite straightforward to implement while other seemingly similar things were quite difficult to do, which enabled them to start thinking about how to deliver the most value for our users in the simplest possible way.

Greg Skinner, designer

For me, the eureka moment was taking developers with us for usability testing. This enabled developers to begin thinking of technical solutions early: viewing the use case directly, as a person tried to use the software, removed the requirement on the developer to interpret a story card or document.

This also enabled developers to ask questions of the end users, which were naturally more technically focused, yet understandable by a user and useful in product development: examples included questions around data retrieval and load times.

As designers, we got far more insight into customer requirements when developers came along and asked questions of our users too. And they loved it - it directly informed their work and got them away from the grayness of code for a few hours. Win-win, really.

Conclusion

So there you have it—pair developers and designers and get great results faster. This approach will enable you to get insights from your customers, help your clients see what needs to be done, adapt to change and, most importantly, deliver value faster.

View the slides from Greg and Charles’ Yow Connected presentation.