Design Thinking and Atomic Project Leadership

IDEO sees design thinking as three lenses through which we can view design: desirability (human), viability (business), and feasibility (technical). Atomic’s project leadership roles (Design, Delivery, Development) share a significant alignment with these dimensions. That alignment strengthens our long-held belief that everyone on the team has a place in the design conversation.

IDEO’s Description of Design Thinking

Tim Brown offers two useful quotes to explain his organization’s approach to design thinking.

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
—Tim Brown, President and CEO of IDEO

“… a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”
—Tim Brown, President and CEO of IDEO | Harvard Business Review | June 2008 | “Thinking”

In those definitions, we hear some repeated concepts:

• People’s needs
• Technological feasibility
• Viable business strategy

IDEO has codified these into a Venn diagram, which looks something like this:

Innovation happens where all three circles overlap. This common ground shows where the product is a “win” when viewed from all three perspectives described above.

Atomic Project Leadership Roles

Now, let’s look at the roles on an Atomic project team. On a typical team, we have three lead roles. They’re not always played by three different people–sometimes, it’s more like putting on different hats at different times.

There is a lot of alignment between these roles and IDEO’s design thinking lenses:

Design Lead – desirability/user

• Learns about product users and their needs
• Helps the rest of the team understand who users are and what they want
• Creates low- and high-fidelity artifacts to guide product development
• Tests assumptions against real users—do they really want this?

Development Lead – feasibility/technical

• Understands software and technical trends
• Helps the team understand what is possible and what is easy/difficult
• Feeds insights into the design to help simplify or align with tools that will reduce complexity and cost
• Provides estimates that play a crucial role in determining what is viable to build

Delivery Lead – viability/business

• Serves as the expert in understanding our customer’s business
• Helps the team frame the context around decisions to identify risks and opportunities
• Works with our customers to manage timeline and budget, which feed back into design for a release

This alignment doesn’t pigeonhole anyone or lock down the perspective or value that our team members may provide. We hire broadly-skilled people: designers with technical experience, developers with a good design eye, and delivery leads who were designers and developers not long in the past. But our roles on a project reflect where people lean on us to deliver value in the course of design for a project.

A Fresh Perspective

Thinking about our project leadership roles in this light provides useful insights and tools. For example, it helps create a focused design conversation or critique by contextualizing feedback into one lens or another. At times when all three roles aren’t present, we can also use these lenses to come up with questions that help us look at a problem from all three angles.

Here are a few of the questions I’ve collected:

Desirability/user

• What need, desire, or problem does this feature address?
• If you have personas, which personas are affected by this?
• Where does this fit in a user’s journey though the product experience? How does it change it?
• Is there a need we haven’t identified that this approach doesn’t meet?
• Is it possible that users don’t want/need this?
• Will users think about this from a different perspective?
• What will users be doing when this release is ready? How is that likely to affect the release?
• Who will be the naysayers on this decision? Why?

Feasibility/technical

• Is there a change we could make to better align with tools we’re using?
• Will this be technically challenging to accomplish?
• Does this have a ripple effect in the software that we should be mindful of?
• Is this comparable to something else we’ve built? Or that someone else has built?

Viability

• Will this take too long to build?
• Are there other ripple effects to the business that we should be mindful of? e.g., Consumer support? IT operations? Other products or product categories?
• Is it possible that this could affect the business model?
• What will the business be doing when this release is ready?
• Does this change the equation of how value flows in the business ecosystem?

Atomic’s project teams approach design with a full-team perspective that provides excellent value to our customers and shares a lot of alignment with IDEO’s thoughts on design thinking. I encourage you to read more about applying design thinking methods to your design work and team in Kim’s series: Design Thinking Toolkit, Part 1 – What Is Design Thinking?