How Do You Marry Superb Design with Great Technology? Design Iteratively

This is the third blog in a four-part series.

Previously, I discussed why organizations should build cultures that support iterative thinking to gain maximum opportunities for innovation. Fostering the thinking around that culture is the first step toward being more inclusive in the idea-generation process. Inclusiveness leads to diversity of thought, which, in the end, will benefit your employees and your customers. The next step of learning how to design iteratively is where the rubber really starts to meet the road.

Customer experience and design are integral parts of building a digital product, yet iterative design is often still a challenge. While Agile development has established itself as the de facto approach for modern software development over the last number of years, designing with agility has neither been prioritized nor adequately solved.

Design sprints are one way to generate and test new ideas. They are intended to be short in duration, likely not run sequentially, and the expected outcomes are to validate or disprove a hypothesis. However, once your initial ideas and high-level concepts have been validated, you need to create and build it.

That's where designing iteratively comes in.

In a typical design lifecycle, your customer research and journey-mapping exercises are often followed by the creation of wireframes and interactive design, which is then layered into the final design.

You might think you have a fully-designed product ready to hand off to the delivery teams. The problem is that it isn’t truly iterative. As a matter of fact, it follows a traditional waterfall methodology to a T. The premise behind digital transformation is to fully shift into a new mindset, where all aspects of your organization can follow an iterative model.

So how do you do it in terms of design?

First, it's important to understand the dynamics of your internal teams. Are they effectively sharing knowledge across disciplines to build team rapport and understanding? How do you keep your design tasks ahead by the right amount of your technical team's development without falling back into an outdated methodology?

The three key aspects that support shifting to an iterative design model are:

1. Transitioning to Integrated Teams

Only when you have all the skillsets needed within your team will you become highly functional. This includes designers and technologists in the same team. Break down the design and technology silos to provide an environment where both disciplines can thrive.

I am not advocating for completely dissolving a centralized design community, but there should be design representation on each customer-focused delivery team.

In the book "Org Design for Design Orgs: Building and Managing In-House Design Teams," authors Merholz and Skinner do a phenomenal job of describing how to create and lead integrated design teams within your organization as well as breaking down the pros and cons of different approaches.

2. Increased Knowledge Sharing

Once teams are embedded, it’s important for design teams to share the UX insights from customer feedback and analytics with the technical team during scrum and stand-up meetings. Conversely, tech teams should share their own difficulties with the design team, so they can be understood, be communicated to the product owner, and allow for future designs to benefit from that knowledge. Once each discipline learns to respect the other's contributions and challenges in creating the product, both will thrive, and the final product will be superior.

3. Shoot for N - 1 (or N + 1), Depending on Your Perspective

Tech teams and design teams are not always in sync when it comes to a realistic turnaround for each other’s tasks. Ideally, the design activities should be performed one to two sprints ahead of the technical activities to allow for a timely, efficient product design/development progression. From an engineer’s perspective, design work should be completed in the previous sprint (N - 1). From a designer’s perspective, development work should follow in future sprints (N + 1). Understanding each discipline’s perspective will help break down communication challenges while collaborating. If teams work to have design activities stay at least one sprint ahead of technology delivery, they will be well on their way to having a successfully integrated team.

Following these approaches will allow your design teams to comfortably share thoughts with your tech teams, while also allowing the tech teams to thoughtfully challenge proposed designs. This is an evolving relationship and one that needs to develop over time.

With consistent collaboration, clear information sharing, and a mutual agreement on when tasks should occur, the new team dynamics will simply become how teams operate.

Once you’ve tackled designing iteratively, you need to address getting the product out to market in a rapid and consistent way. I’ll address delivering iteratively in my next blog.