How agile teams can design together

Team designing together

Do you work in a team that doesn’t have a UX/UI Designer assigned? Is it hard for you to understand who owns the design part in an agile team?

Well for the first question, if the application UI work is too intensive or is too complex to leave the design decisions and work to the developers or product owner, you should reconsider getting someone specialized in this area. According to Norman Nielsen Group, a typical ratio is 1 UX researcher for 5 UX designers for 50 developers. Which is about 1 designer for 10 developers. But I know having these roles are not always possible to have, I work in a team that doesn’t have any, therefore I had to become a UX team of one myself.

For the second question, every single person in your team is responsible for the value your product delivers. The team should be cross-functional, avoid working in silos, that applies for quality, design, planning and so on. Which means, everyone is responsible for the design, not only the product owner or the UX person. Design is a highly collaborative field, if any of your teammates uses as an excuse that they are not creative, doesn’t mean they don't have a perception of what good and bad user experience is.

A month ago, I was given the opportunity to help with the UX efforts in a team. I’m not an UX expert but I ‘ve read a lot on this matter since pandemic began! So I thought it would be great to sign up for this challenge to put into practice all the newly learned knowledge.

When I got to the team, I found out that we were already behind schedule and they needed some design work to be done as soon as possible so they could make some progress on the implementation — First lesson here! This is the real world, books will tell you what the right process is, but at the end is on you to juggle things around to make them work. At this point the only information I had gathered was the project overview, and I did this through the UX Questionnaire method from The UX Team of One, by Leah Buley.

Moving from doubt to certainty

Later, a concern popped in my mind! How was I supposed to start designing if I haven’t done any research work yet? All we had were assumptions! And then the answer came up while reading the Lean UX principles by Josh Seiden and Jeff Gothelf. Everything is an assumption until we prove otherwise! And that removed the roadblock in my head. So I decided to begin with doubt and then proceed to validate as soon as I could.

Shared understanding

This is another Lean UX principle, it builds upon the fact of having the team work together so everyone is up to speed with the product, the users and the surroundings of it, this helps make faster decision making later in the road and avoids extra meetings. This gave me the answer on how to approach design work, it wasn’t my job only, but the team’s too. So I scheduled the first session, I tried to squeeze everything in one hour but it wasn’t enough, so that was learning number two — Use the time you need, if you use less you’ll find yourself rushing. But close enough was lesson and challenge number three — meetings consume people’s calendars, making the space in everyone’s calendar is hard, but if people are really interested and up for the outcomes of your workshop, they’ll make the space, in return I try to switch things up a little bit so they don’t feel like in “another meeting”.

Designing a workshop to design as a team

At this point I had a bunch of information from books like The UX Team of One and Design Sprint, in both of them they encourage designing as a team. So I grabbed what I thought could work for us and here’s the recipe for it.

Figma - Design Workshop | This workshop focuses on the Design phase and includes a series of…

Average time: 2 hours and a half

• 1 hour to search for demos and preparing board
• 1 and a half to run the workshop

Prework steps

1. Prepare the board. You can use the one I created as reference, I did it in FigJam
2. Pick a decider or two to help with decision making, this is usually the product owner, tech leads or whoever has a great vision of the product
3. Understand the challenge of the design workshop
4. Schedule the session
5. Prepare lightning demos, if you have enough time ask team members as part of the prework to bring ideas of products they think would help as inspiration for the challenge. If you don’t, you can find them yourself and post screenshots in the board
6. Let the team know ahead of time that they will be drawing so they can have nearby paper, sharpies and a phone to upload photos of the sketches to the board. They can also use any drawing or prototyping tool. I always recommend paper because you can easily throw it away if you are unhappy with the results and start from scratch easily

The workshop

Most exercises where taken from the Design Sprint written by Jake Knapp, John Zeratsky and Braden Kowitz. I will indicate which ones so you can search for them in the book if you want to dig deeper on the reason of being.

1. Set the stage with inspiration

This is based on the lightning demos from Design Sprint slightly modified

• Start by reviewing the ideas you or the team brought, show screenshots and if needed show the site in action
• Ask the team to take notes of big ideas

2. Define the scope

• Ask the team questions to help set the ground for the sketch session. Align everyone on the same page. Here’s where you clarify opens, doubts, what’s part of the MVP (if you don’t have an MVP — Minimum Valuable Product, you should suggest your team to define one, it’s part of the foundations of working with Lean UX) you should write everything down in a sticky note, if someone brings things outside of the MVP write them down too for future reference, but indicate that those should not be part of the design session to avoid waste and distractions.
• Ask the team to agree on the scope and move to the next exercise

3. Let’s sketch!

• Get started with the sketch session, ask the team to draw several ideas and pick one or two at the end if they can’t decide on just one
• Ask everyone to paste the sketches in the board. People could feel ashamed of showing their drawings, if that’s the case ease the situation by telling them that this is a non judgemental space and that all they have to draw is boxes, lines and text, so they should be fine. If this doesn’t work, tell them they can use tools like Paint, Balsamiq or any other they know

4. Heat Map (Design Sprint)

The heat map is a great tool to help with decision making and highlight ideas without bias, noticed that up to this point people haven’t explained their sketches. Here are the steps:

• Don’t talk
• Ask team members to review each sketch and place stars or dots in the ideas they like the most, if any.
• If there are ideas they like very much place 2 or 3 stars or dots
• There’s no limit on the stars or dots they can use
• They can vote for their own drawings
• If there are questions or concerns ask them to write them on a sticky note below the drawing

Heat Map example

5. Speed Critique (Design Sprint)

This exercise helps to review heat map observations and highlights, the person who did the drawing should speak until the end.

• If you are the facilitator, ask for a volunteer to help you capture notes since you’ll be busy narrating drawings
• Facilitator narrates each sketch, points out highlighted ideas on heat map as well as questions and concerns
• Open it up for team feedback, volunteer takes notes
• Person who did the sketch adds anything not covered or misunderstood

6. Straw Poll (Design Sprint)

• Based on the amount of decisions you need to make give each team member a dot
• Ask team members to place their votes on the ideas they like the most. One vote for each decision
• Ask each team member to explain the vote, this should not take more than 1 minute
• Give each of the deciders three supervotes (in screenshot are the +1) per decision and ask them to place their supervotes on the ideas the team will commit on executing, this could mean you end up with an entire sketch as the final decision or a merge of multiple sketches.

Straw Poll example

And that’s it! Now you have a north to follow, I took the sketches and created mid fidelity mockups which I later used to validate with the team and a user. Remember we started on assumptions, so we can’t stick with them forever, we need to validate them.

Also, stick to your MVP, if you don’t have one, define it with the team, that lets you reduce waste and keep the team focused on a goal.

With Lean UX, the designer role becomes more of a facilitation role and that enables UX tasks to blend in with less friction in agile teams.

Lastly, mix and match exercises as you feel is needed, all the books I referenced here are great resources to feed your facilitator toolkit, they offer great recipes and ways of working but only you understand your constraints, you may find it’s impossible to get all the time you need for a workshop in everyone’s calendar, office politics, low resources, or any other limitation. Work with what you have, cut open conversations and start delivering value!