The agile design process incorporates different ceremonies to ensure a successful user experience and foster greater shared understanding among the product team. These activities are:

• Hypothesis Creation
• Collaborative Design Discovery
• Testing Day
• Testing Review

When conducting these ceremonies, there are two things to keep in mind: attendance and cadence.

In a perfect world, you would be able to invite your entire cross functional product team to all of your design ceremonies so that every perspective was always represented and there would be no gaps in shared understanding. Practically speaking though, this is usually impossible and also not the best use of your full team’s time. 

What I’ve found works best is that you can pretty safely include most Business Analysts and Product Owners on most design activities. With developers, aim to do some research ahead of time on which devs you might be working with the implement a design idea you’re working through and target them intelligently with an invite. 

With cadence, attempt to run most of these at least once a sprint when applicable. This has some wiggle room however. I’ve found doing discovery activities twice in a sprint has had a positive effect on team shared understanding and my own personal design output. I think it also helps to pilot activities and ease into them. Starting all these activities in one sprint cold turkey could result in disaster. Pilot one ceremony at a time and expand into others when the previously established ceremonies are running more smoothly. Hypothesis and Discovery seem to be the most logical first ceremonies to pursue, adding the most value with the least overhead. A sample of cadence could look like this:

Hypothesis Creation

Starting with a hypothesis gets the entire team aligned from the beginning with a clear strategic vision for the problem that needs to be solved. It changes the team’s perspective from output to outcomes.

Declaring Assumptions

Starting with assumptions in the design and discovery phase is important because it helps change the team’s mindset from coming up with immutable requirements to finding solutions that can be tested. Get the team together to declare assumptions early on. Four areas to focus on for assumptions involve business outcomes, users, user outcomes and features.

Collaborative Design Discovery

One of the most powerful things a designer can deliver is shared understanding for their product team. Using collaborative design studios is one of the best ways to ensure that the team is aligned on the problems that need to be solved and how they should be solved. Discovery sessions tend to work best with groups of around 5 people. 

The design studio serves a few practical purposes as well. It gives the designer a broader well to pull from when putting together a design. The best solution for a problem your team faces should never always be coming from the same person. By collaborating on a design to solve the problem, you are pulling from a pool of diverse experiences and perspectives that can come together to deliver the best possible design. It also elevates the design IQ of the entire team. The more comfortable the full team is with design, the more empowered design will be when decisions are being made. It will also enable designers to warrant better feedback from their team.

Although there is no one method to do when running a design studio, some that have been previously successful are:

Group Sketching

Do some context setting about the problem to be solved and then have the group participate in a group sketching exercise like Crazy 8’s (although I’ve found Crazy 6’s might work better.) After the team spends some time sketching, have members present their ideas. Refine and iterate and you should come to a consensus about a general design solution to the problem.

Rose Thorn Bud

This can be helpful when you have a full team together to look at a design that needs enhancement and get feedback in a productive manner. Have participants use Pink (Rose/Good) Blue (Thorn/Negative) and Green (Buds/potential ideas) to markup an idea or a design to get some alignment on where to go next.

Priority Mapping

This is helpful for when you are exploring how to prioritize different ideas. Put together a list of different ideas to pursue, potential elements for a page and list each one as an individual sticky note. Have each participant order the stickies in order of priority prepared to explain why. Have each participant explain their order. An example of this process can be found here: This process can also dovetail nicely into an importance/difficulty matrix.

User Story Mapping

User story mapping helps you and your team get quickly aligned on the vision for a product and allows for conversation into the “Whys” of a process in an accessible manner for a whole team.

Concept Mapping

Concept mapping is helpful for breaking down a complex process or concept into something is easily digestible and understood by a broader audience. This is very helpful in an industry like insurance where it’s easy for one person to become a silo of knowledge on different topics. To do concept mapping, break down a topic into a few smaller pieces and approach them with an eye towards: Who, What, Why? Have the full team participate in note taking.

General White Boarding

Sometimes, less structure is helpful. A designer is more specifically suited to helping facilitate shared understanding amongst a team than any other role in product development. For this reason, it can be helpful to just get the right people in the room for a conversation on a topic and to build out the conversation visually as it takes place.  

Abstraction Laddering

Abstraction Laddering is a helpful exercise in reframing a problem statement or solution idea. Many times at BriteCore, we are given requirements or ideas like, “This page needs X feature.” Put this statement at the center of an abstraction ladder. Go up the ladder by asking, “Why?” and down the ladder by asking “How” until the subject is explored fully and a potentially better solution arises. 

Testing Day

For user testing to become a regular part of a sprint cadence, you must adopt a “Test what you got” mindset. This way you are able to gather a steady stream of insight, which is more valuable to an agile team’s health than one off research initiatives. 

Select a testing day or days that make the most sense for your cadence and put whatever is ready in front of users then. Invite a small group of your cross functional team to participate if able. There are various methods and artifacts user testing can be done on:

Sketches

Sketches can be used to validate early concepts. Helping move abstract ideas into something more concrete. There’s a lot of value here and sharing sketches shouldn’t be discounted.

Static Wireframes

Testing wireframes is a good opportunity to assess information architecture, content and the first inklings a user might be feeling towards a pages usability.

High Fidelity Mockups

These can provide you much of the same value as static wireframes, but with the added layers of visual aesthetic and content. Feedback in this stage will likely feel more critical and is a good opportunity to refine details.

Prototypes

While prototypes can range in fidelity from sketchy to high fidelity, the value in testing a prototype is in giving your users the ability to simulate a workflow and see how they interact with the interactions you’ve designed

Testing Review

One of the most important parts of testing once it is complete, is to make sense of the findings. Instead of preparing a report or document synthesizing research findings, it is better to review the research findings with the members of your cross functional team together.

One of the most effective ways to do this is via a whiteboarding session. Put up all the different research findings and observations from all the team members onto the board as stickies. Organize the stickies into groups or themes that emerge. From there, decide what actions need to be taken. There are three things to keep in mind here:

Look for Patterns

Patterns reveal areas where further exploration and design is warranted. Any findings that don’t fall into a pattern are likely outliers.

Don’t worry as much about outliers (yet)

It’s not practical to act on any outlier your research discovers. They are either lower priority findings or are part of a pattern that has yet to reveal itself. If outliers begin to form a pattern after consecutive tests, then you’ve found something worth actioning.

Verify your findings

If you’re not convinced about the validity of findings coming from one test or channel, determine whether it warrants further exploration and use an alternate test or channel to verify its validity.