Design driven development—using design as a tool for teamwork
What is design-driven development?
Here are some scenarios.
Scenario: A problem with solutions thinking
Your team has identified a customer problem. You quickly take a divergent approach to brainstorm as a small, diverse group spanning product management, design, technology, and sales to develop different ideas for solving the problem. Through group discussion, you identify the three most valuable ideas. Your designer quickly creates a design artifact or clickable prototype OR 1–2 developers create a quick and dirty coded prototype.
Scenario: Testing of solutions & learning
You identify a small group of customers, and through 3–4 quick rounds of user testing, you learn how to improve or change the feature to better meet customer needs.
Scenario: 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 before coding.
Why highlight design-driven scenarios?
As teams and companies can fall back into more traditional and ineffective ways of working, highlighting design-driven scenarios is a good reminder of the different ways that design fits into the product development process.
I’m humbly reminded of the topic of design-driven development when being a witness to companies that consider engineering paramount and think of the design process as something that gets bolted on. It’s almost impossible to think divergently in environments like this, and for many companies, this eventually meant taking several steps backward and re-engaging at the start.
The landscape has evolved over the years, but many designers, still struggle to empower the companies they work for using effective design processes.
Some companies fail to see the design process 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 product or don’t identify a product vision worth investing in.
Using the design process 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 software development. The design artifact can be a sketch, a low or high-fidelity mockup, a clickable prototype, or even a quick and dirty coded prototype. Any artifact that helps you get feedback from customers to better inform what you’re building before building it will work.
Using the design process 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, the design process needs enough space to create definition before coding. One excellent example of this is making sure that designs should be finalized more or less when your Sprint starts 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 prioritize accordingly and allow for the time required.
Melissa Perri phrases it brilliantly.
“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.”
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. Great products are the kind that makes users feel like heroes. When users feel like heroes, they will tell other people about your product, and word of mouth is the best marketing kind. 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, integrity in the design execution is often 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 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 do not think deeply and analyze 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. It’s not a matter of design anymore; it’s a deeply embedded process problem.
Some scenarios to avoid when it comes when hiring design talent.
- 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 utilizing 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 incoherent product)
Design process considerations
Some scenarios to avoid when it comes to design process.
- Thinking of design as something applied after the fact, instead of an essential 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 develop technical definition
- Not allowing design, prototypes, and user research to answer product questions before coding
- 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
If it’s not working, change it!
Building software is such a humbling experience. It’s tough 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.
Happy building! 😀