Why your developers should think more like a designer

Software exists to create an experience for a user, be it solving a problem or some other business value. Any development process that loses sight of that experience, even for a second, will miss opportunities to create something great.

Agile and Lean practices are crucial to creating products with great experiences. They put the customer at the center of the process and encourage team collaboration.

While those methodologies certainly don’t ignore users, or the design process, they don’t align the goals of designers with developers. This creates friction on development teams which slows our progress.

At D-I we have a few key truths that allow us to create great products for our customers:

• Teams have a shared understanding of the value they are creating together;
• Designers use their instincts to invent new ideas;
• Design ideas are validated through feedback from users;
• Developers and designers collaborate on implementation.

Agile and lean processes have allowed us to get to where we are today, but recently we’ve realized that we have a fundamental problem in the way we structure our work. It’s not the fault of the process, but in the way we, and most of the industry, have implemented it:

• Developers need small scopes of work to be productive. They break features down into small manageable pieces (storycards).
• Designers need to think about the big picture. They have to take small pieces and put them back into the context of the interface as a whole.

By it’s very nature, this process separates the work designers and developers do. How can we ever hope to achieve shared understanding if we're not working together?

Most teams choose one of two ways to solve this problem. They design everything at the beginning and lose insight into development constraints and risks. By the time designers get their hands on the working product, their mind is already focused on the next thing.

When that doesn’t work, design becomes an afterthought, hurriedly painted on at the end of the project. Developers make most of the decisions, and designers are forced into constraints that they don’t understand.

In both scenarios, the team never has the same holistic understanding at the beginning of a project. How can we expect anyone to work on a project without giving them all the same level of understanding from the very start?

Changing how collaboration works

At D-I, we’ve started developing like we design. Developers and designers pair on rounds of improvements instead of individual features. This allows everyone to think about the experience holistically, while still giving developers the ability to break up their work as they see fit.

Step 1: A designer and a developer meet (with coffee or beer) to sketch a vision for what their feature will accomplish. They talk through use cases and scenarios. They discuss what pieces will be trickier than others, and they talk about how it all fits together.

Step 2: Sitting next to each other, they start working together in broad strokes to deliver that improvement in its most basic form. The designer starts wire-framing and toying with graphical ideas. The developer puts some structure and the basic UI scaffolding in place.

Step 3: The developer and designer review what they just created. They talk about ideas for improvement and potential stumbling blocks they may encouter. They agree on what they need to accomplish for the next round of improvements, and start over again at step 2.

Step 4: They ship the feature when the customer is satisfied and start the process over with the next priority.

By changing the structure of our work, we are able to make small improvements to many features in parallel. This results in faster feedback cycles, each one refocusing us on the user-facing need we’re trying to fill. This keeps our minds on the value of the product as a whole, not just the feature we've been heads down on.