Product Designers in Scrum Framework

Do product designers fit Scrum? It depends, but most likely not.

Matrix organizations and functional teams have become pretty popular these days. The idea behind a cross-functional team is to combine experts from different areas to achieve a product goal and deliver it with quality and as soon as possible. And, there’s always a place for a product designer. Someone has to move pixels around the screen, draw fancy icons, and talk about product hypotheses from time to time (that’s probably how engineers define the job of a product designer).

Scrum Framework

In cross-functional teams, engineers often use the Scrum framework. Actually, I have never seen them use anything else. It goes to show how good Scrum is, at least for engineers. However, if something works for one group, it doesn’t necessarily work for everyone.

I am not a Scrum expert, project manager, or someone who has fully mastered Scrum principles and has a burndown chart tattoo on my back. Yet I have worked in different teams with different processes and have some thoughts about how Scrum fits product designers.

Product designer role

There are a lot of variables, depending on a company type, size, team, market, etc. But basically, in a digital world, a product designer is a person who designs products (applauds goes here). I would replace the word “design” with “shape” to avoid confusion. Now, it’s a person who shapes products with the other product team members (product manager, at least).

Shaping process

The initial shaping process is too abstract. You operate with things like vision, quantitative & qualitative research, domain knowledge, business goals, experimental data, technical specifications, and your friends’ advice (because everyone is an expert in designing products from birth).

Sometimes your working day looks like you watch an empty wall while your brain processes all this data into a single knowledge base with one goal: achieve the objective.

You shape your ideas alone or with the product team, and the process is far from linear and predictable. Of course, there are many frameworks, such as Design Sprints, to solve everything you need in 5 days, including statistically significant validations. But, c’mon, let’s not delve into that. Anyway, you’ll probably use a few of them during ideation, but still, it’s really hard to commit to something at this stage.

Your eyes will be wide closed for a long time until you’re done shaping.

• If you can plan your work, decompose it by tasks, and commit estimates, it means you’re already near the finish line.
• If you have structured tasks or understand what to do with detailed requirements from the start, it means someone else made the essential designer work for you. And hopefully, it was a lead designer, not a product manager or anyone else.

Let’s try to visualize the very rough design process.

By shaping, I mean some basic R&D stuff:

• Collecting business requirements and analyzing existing data
• Market research and customer development
• Gathering feedback from stakeholders and insights validation
• Identifying opportunities
• Designing an information architecture
• Preparing concepts
• Providing design specifications
• Producing prototypes
• etc….

But the real design process will look more like this in practice.

Product designers are constantly in a shaping stage because product development is a complex work that consists of a few parallel processes dependent on each other. Here, any estimation attempt looks more like betting. You’ll have a higher win probability betting on FIFA than estimating during the shaping stage (Mind you, gambling is banned in some countries).

Does it fit Scrum?

The scrum process (the very basic overview, please don’t blame me):

1. Break down all the work into tasks/stories/etc.
2. Estimate tasks in hours/days/story points/ex’s lastings/whatever.
3. Set a goal for this sprint. What do you want to achieve at the end?
4. Fill the sprint with tasks aimed at that goal until the available capacity (sprint cycle duration) is over.

I’ve just checked our engineers’ Jira, and almost all tasks there start with these words: Check, Add, Create, Fix, Update, Highlight, Support, Move, etc. Sounds very straightforward, with clear actions of what to do.

Of course, this is not always like this; engineers have to do shaping work too, but the share is much lower. And a decent amount of shaping is done before they even start the first sprint.

Product designers also have those actionable tasks, but the proportion is opposite to shaping (as illustrated below).

Following this context, we can conclude

• The key goal of an engineer is to DELIVER.
• The key goal of a product designer is to DEFINE what to deliver.

Scrum implications for product designers

Based on this, it doesn’t make sense to try to fit designers into an engineering framework. Developers will be out of the loop during designers’ updates at daily scrums as designers move at least a few weeks forward in the product scope. There are more suitable ways to make engineers informed of product design progress — more structured and complete and not pointed out of the global context.

Scrum attributes, such as velocity factors and burndown charts, are useless for product designers. In most cases, designers just keep getting underfoot, ruining engineers’ indicators. The connection between designers’ and engineers’ tasks in Jira appears useful, but in practice, it doesn’t work due to the inherent uncertainty at some design stages.

Product designers conquer chaos, and chaos is completely opposite to what Scrum is about. Simply put, there will be more mess. Such frameworks are of little help to product designers because they are based on the idea of commitments.

The only designer’s commitments are to

1. Unblock development. Shape enough scope for engineers for the future sprint, collect all the requirements, handoffs, etc.
2. Support engineers. Provide them with support in their sprints with the tasks they choose to do. Solve detected edge cases, give additional specifications, tell them their work on mouseovers is important, etc.

Therefore, I have to conclude that the Scrum framework may not be the greatest fit for product designers.

Short disclaimer

I’m only talking about my(HUGE) modest experience. I know my explanations may be flat and basic, so don’t take them too close. Just catch the thought and try to think how it applies to your case.

With ❤️ from 🇺🇦 Ukraine