Diamonds are Forever

Marrying a Design Process with Agile

Put a Ring on It

There are two types of processes that at times may seem to be incompatible or even competing forces. On one side there is the dapper Agile. Agile is formal and popular:

• “I don’t need an introduction”
• “I’m solid like a ring”
• “Iterative”
• “Fast”
• “Nimble”
• “Google”
• “Facebook”… (drops mic).

Then there is Product Design, nearly the opposite. Product design is not as formal:

• “Who are you again?”
• “Be like water”
• “What’s all the rush?”
• “I have so many questions”
• “All the feels”
• “Zen, bro”
• “beautiful like a diamond”… (pass a brownie).

At first glance it might seem like it would never work out between these two. I’m fortunate to work with an awesome product design, product management, and engineering team at Sumo Logic that became match makers to marry both processes (awww!). We discovered that diamonds go perfectly on rings (duh)! What do I mean? Let me explain…

You see, Agile or even Lean are (ring) processes that focus on efficiency via increments of design, build, test until the outcome is as expected. While the Product Design (diamond) process is focused on ensuring quality of the solution via iterations. Incrementing (finished subset) vs iterating (cycling on the whole) is explained well with the “Mona Lisa” example. The takeaway is that the scope needs to be identified early in the process. There needs to be time to clearly answer critical objectives and scope even if they start somewhat vague.

They Start Dating

A large portion of the design effort before we put pixels to screens is ensuring we have the time for design thinking. This requires answering critical questions that ensure we are building the right solution before we start delivering on a plan. Our current process is a Sumo Logic Agile adaptation of the Design Council’s Double Diamond Process, which is a divergent/convergent design process aimed at improving the direction and quality of a solution. A huge shout out to the design community for all the great references, and Dan Nessler for this awesome article on hacking the double diamond.

Key aspects of the Product Design Process

• Design as a methodology for solving problems
• Design as a process rather than a task
• Combining a scientific method with creative design thinking methods
• A focus on alignment

Two Diamonds Are Better Than One

At its core, the main objective of the Product Design Process is to ensure that two main questions are answered in the process of developing a solution.

Are we building the right thing?

The first question, “Are we building the right thing?” ensures that we understand the problem and value proposition based on the customer’s feedback. In some cases the customer is represented by a subject matter expert or someone with a innovative idea and very strong intuition (common Steve Jobs analogy goes here). Even in those cases I would caution that what matters is the ability to formalize (articulate) the value vs. risk and how the team will test the hypothesis (even in “gut feeling” scenarios).

Are we building it right?

The second question is focused on answering “Are we building it right?” In order to answer this question, critical flows and touch points require teams to explore options and consider technical and other constraints. It also requires a series of iterative testing to see which resonates better with customers. Not all parts need to be fully tested. In order to speed up the process, you can take advantage of the criteria outlined in the strategy phase to identify the highest risk and friction points. My suggestion is to ensure these areas are well “greased” via exploration time before worrying about other lower priorities. In a lean method you would quickly build out some hypotheses and test. Once explorations are narrowed down to a chosen path the team starts to create. Depending on the product development model you are running, a series of deliverables and expectations are set. The main idea from a Product Design standpoint is that there are enough design specs such that delivery is not facing any bottlenecks.

It Gets Serious!

One of the challenges for teams that are accountable and hence delivery-focused is understanding what they should expect from each stage. Telling a team ready build that you “need time to brainstorm, think, define, etc” could sometimes be perceived as ‘fluffy’ conversations. Detailing out the different tracks and deliverables driven by clear objectives converts the conversation to a discussion of “tangible” concrete deliverables. Each stage is broken down into four lanes:

Objectives — At the end of the day what questions do you need to answer in order to be drive value to your customer? These questions drive the other lanes. Too many times we get lost in the solution without understanding what the question is.

Research — What kind of research will provide the answer to the objectives? In the early stages most of the time it is a combination of quantitative (when available) and less strict qualitative methods. As the product matures the user testing rigor becomes strict. What’s important is to research and test during the whole process.

Deliver — Product Managers and Engineering leads love this lane because it provides a clear set of tangible deliverables that they can use to make decisions. Deliverable fidelity should match project maturity. Many times teams are too focused on high fidelity deliverables when the best deliverable for a quick decision is simply sketches or low fidelity prototype.

Decisions — What decisions need to be made before moving on to the next stage? Who makes these decisions? What KPIs are needed to make these decisions? Note to self: add a KPI lane :).

Till’ Death Do Us Part

Like any good relationship, its important to make sure we have everything we need for each date (flowers, reservations, ring, check, check, check!). These “dates” are milestones in the product life-cycle, and reflect the maturity of the product.

Trigger

The trigger for a given project should be identified and clearly outlined. This is where the designer and the PM usually start the initial conversations that will set the stage for important KPIs to measure against. From a design standpoint its important to distinguish the overarching goals. For example, if higher adoption is a business trigger then we immediately know that emotional design will play a critical role. We then prepare our customer interviews to understand the emotional mental models. Other times, the trigger could be driven by customer support tickets of users screaming for help. In each example, the success criteria could look very different. This could force the conversation with upper management on the expected outcome. The Product Designer plays a critical role in using design thinking methodologies to connect the dots between the trigger and understanding the problem.

Vision

The key to this milestone is to ensure that objectives and success criteria are well-communicated. The deliverable format is not as important as ensuring all stakeholders agree on the direction. Enough information should exist to define the problem, define value, and identify high risk points. Depending on the size of the project this is also a point to break down the solution by areas of incremental chunks.

Solution

Celebration time! You have now delivered a solution that your customer will love. How do you know this? Because you are going to use quantitative (metrics) and qualitative (user testing) data against the Trigger and KPI’s you defined in the first Discovery stage.

And They Lived Happily Ever After…

This process is a living document created with direct input and collaboration with the Product Management team. It is driven by the goal of delivering value-driven solutions to our customers. The Product Designer is a facilitator that brings the whole product team to champion for the customer. The power of the process is to serve as a framework to collect cross-functional feedback to reach the right solution. It has allowed us to incorporate input not only from customers (#1), but also from stakeholders, domain experts, and almost every key customer touchpoint (Sales, Customer Success, and Product Management).

Finally, This is not a process only for “designers” this is a process that helps organizations move as John Maeda refers to from Design to De$ign. When done correctly, the output is the best user experience possible within time constraints (time is never on our side). Good Luck!

Tip:

If the linear format scares your team (Aaah! Waterfall!) Here’s a circular one we created to keep the Agile warm and fuzzies. Guess what?! It worked LOL

We love giving back to the community. If you liked this article and would like a copy of the Sketch file for your hacking needs email me at: dcastro@sumologic.com