What is Design-Driven Development?
Design driven development uses design as part of a process to learn and better define requirements in order to build better, more informed technology solutions. It can also be looked at as a process whereby design and user experience drives the development of a product or software application. This leads to products that people enjoy using and want to tell others about.
A Design Driven Development Scenario
The Problem + Solutions Thinking Your team has identified a customer problem. You quickly take a divergent approach to brainstorming as a small, diverse group spanning product management, design, technology and sales — to come up with different ideas for how to solve the problem. Through group discussion, you identify the three most valuable ideas. Your designer quickly creates a design artefact or clickable prototype OR 1–2 developers creates a quick and dirty coded prototype.
Solutions Testing + Learning You identify a small group of customers and through 3–4 quick rounds of user testing, you learn how to you learn how to improve or change the feature to better meet customer needs.
Product Design Before Development You then take the time you need to thoroughly design the feature with continued customer feedback and internal stakeholder reviews. This creates design definition, and also helps your team flesh out technical requirements along the way all while defining a real scope of work prior to coding.
Why Am I Calling This Out?
You might be thinking “this is already how we work at my company” or “hey, this just sounds like a consultant trying to brand their own services.” Ha, yeah maybe! Really though — I think it’s worth calling out how design best fits into the overall product development process. There are still many designers in many companies that struggle to use design as a tool to drive definition, understanding and technical conversations and decisions. Although it’s hard to see because it’s hard to quantify, an up front time investment in design can save teams time and frustration in the long run. Let’s give it the space it deserves!
I started thinking deeply about this topic a few years ago. At the time, I was working with various startups to design products and new features and help companies make informed decisions while getting these things to market. I started seeing patterns in some companies where technology was paramount; design was something that was layered on after the fact or sometimes not at all. Divergent solution thinking wasn’t happening most of the time; product solutions were something that internal teams created without much customer input. For many companies, this eventually meant taking several steps backwards and reengaging at the start.
We’ve come a long way in the past few years and generally, it feels like as a collective we’re much smarter about how we build products. Many designers though, still struggle to empower the companies they work for using design. Some companies fail to see design for what it really is — a toolkit for building businesses and finding a solution that really nails a customer problem. As an extension of this, some companies don’t integrate design into the overall product development process well and generally mangle the design practice.
Why “design driven development” is such a good phrase.
I like the phrase “design driven development” as it speaks directly to where design and solution thinking should fit into the sequence of things. It speaks literally to how design should “drive” the product process.
Using Design to Learn
Using design to learn means allows the business to gain insights to better inform product design and technology decisions before investing heavily in the software development. The design can be in the form a sketch, to a low or high-fidelity mockup, to a clickable prototype or even a quick and dirty coded prototype. Anything you can put in front of a customer to get feedback and better inform what you’re building before you build it.
Using Design to Guide Development
Design can significantly help drive the process after the learning phase as well. While design and development need to work together to be successful, design needs enough space to do its thing and create definition prior to coding. One really good example of this is making sure that when your Sprint starts, design should more or less be finalised and can be used as a tool to guide development. You can be focused on shipping features AND having a solid design and validation process, so long as you prioritise accordingly and allow for the time required.
I like the phrase design driven development most of all because it elevates design and the value it adds in a way that is hard to come by when we talk about “Agile” and the software development process in general.
— Melissa Perri phrases it brilliantly in a post she wrote.
“Look at the way we measure the success of our workers and our companies. All of our metrics are geared towards production of code or product. Even Agile stand-ups — ‘What did you do today, what did you do yesterday?’ If you haven’t delivered your items on time, you get penalised. If you have delivered your items on time, you get rewarded. If you can produce more than another person, you get promoted.”
Experience Matters
Creating a product that solves a problem or generates revenue is only part of what makes a product successful. The experience the product delivers is the type of value add that sets mediocre products apart from great ones. Great products are the kind that make users feel like heroes. When users feel like heroes, they will tell other people about your product and word of mouth is the best kind of marketing. Often times the features that make customers feel this way comes from conversations with the customer. A design driven development process is one of the only was to ensure a great experience gets delivered. If a product team is feeling pressured to close tickets to complete a Sprint and needs to cut corners to do so, often times integrity in the design execution is one of the first things to go. Great experiences cannot be created in a rush.
The Build Trap
Without design driven development, it’s easy to build many bad experiences into a product and more importantly, miss the mark with solutions completely. In the absence of design driven development, teams are focused more on building and shipping — often blindly. If product managers and teams are not thinking deeply and analysing what they intend to build and why, they’re coding without a cause. This is commonly referred to as “the build trap.” Building features, without proper design or validation that end up offering little to no customer value. At this stage, it’s not a matter of design anymore; it’s a deeply embedded process problem.
Successful design driven development starts with hiring and is tightly integrated with process. Let’s look at some pitfalls related to both — so you can avoid them!
When Hiring
Some scenarios to avoid when it comes to design and hiring.
- Not hiring a designer at all or hiring one in piecemeal (e.g. hiring a designer on contract to create a design system, then expecting the development team to use it to design the software, with no actual design direction) — skipping steps to “save money”
- Not hiring the right designer (one that has the strengths to match the weaknesses on your team, one that can help implement a design driven development process if one does not exist)
- Hiring a designer, but not utilising them correctly (telling them what to design instead of allowing for autonomy and letting them use design as a tool to validate and drive development and product decisions)
- Contracting design: hiring many different designers over time (creating an inconsistent experience and and incoherent product)
Design & Process
Some scenarios to avoid when it comes to design and process.
- Thinking of design as something applied after the fact, instead of an important part of the overall product development process
- Thinking that design is only used to create design definition, not thinking about how it can also be used to create technical definition
- Not allowing design, prototypes and user research to answer product questions prior to coding
- Including design and development for a feature in the same Sprint (not allowing design and learning to take place prior to the Sprint and drive as well as guide the development process)
- Letting the HiPPO (highest paid person’s opinion) dictate the features that get built and the processes used by the product teams — bypassing the value of design completely
Booking.com believes in “guidelines, not rules,” and offers employees complete freedom to decide how and what to test. They throw HIPPOs (highest paid person’s opinion) out the window in favour of increased democracy within company decision making. — Source
If It’s Not Working, Change It
Building software is such a humbling experience. It’s really hard to get right. The power of hindsight helps me do a better job in the present. One of the biggest lessons I’ve learned is: if something is not working on your team, change it. Don’t wait until “the right time” because there will never be a right time. Do it now before it’s too late.
I’d love to hear your tips or stories on the subject — feel free to leave them in a comment!
Happy building.
