Shaping design work (with STAR)

Shaping design work for others, rather than tackling it yourself is a hard balancing act. Shape the work too much and people are too constrained. Too little and people get lost. Or scope is so large it’s difficult to show progress and value.

It’s not something a formula can solve. But there are things you can use to help.

I’ve started to use a format when writing up and shaping design work. This was in response to at times feeling like some work was better shaped than others. And what an ideal statement of design work would be for me.

The format I’ve started to use is STAR. This isn’t a new thing. Though it wasn’t designed for shaping work.

The STAR format helps write up case studies as well as structure interview responses.

It stands for:

• Situation
• Task
• Activity/Action
• Result

It’s a sort of narrative helper. Useful to structure retrospective stories of how someone tackled something. And what results they got. STAR isn’t the only format, there’s a quite few around.

As with any narrative structure, it’s not only useful for when you’ve done something. It can help shape what you, or other people, can do to tackle work. Before you’ve done it.

It’s something I’ve started to use. But I’m finding it helpful. To get my thoughts in order. To direct teams and individual teams to kick start work. Big and small.

How I use the format to shape design work

I use the format to break down work into each section. Which together helps create the size and shape of the work. This can then help someone to tackle work. Or act as material for kick off workshops and other meetings.

It also doesn’t have to be completely formed and can be created together as a group. And there’s no reason it needs to 1 person’s work. Or 1 role.

Situation

Like many stories. Start at the beginning. Writing down all known facts about a problem or opportunity. This might be something like a preliminary problem statement. Or. It could be a raw set of constraints and hunches.

I’ve found it works better to throw in a few lines of what’s going wrong. And the issue that is being caused over a formal problem statement. But that might be a personal thing. I try too hard to get problem statements perfect.

In the situation section I also like to be clear where a request has come from. If it’s a policy, something observed in user research or a request from a product manager. Then say it.

If an opportunity needs some selling then that needs to be clear. Either internal buy in or validation. It helps teams know what they’ve got to do next.

If a request has a rigid scope that is also worth calling out. Again, it helps teams know what the situation is. And if it’s a “go do it” sort of situation and the reason is less than clear. That should be clear. It helps the team understand what to do. And how other people will understand the work.

Task

The initial scope of the work. This helps make it clear what I’m expecting.

But I’m open to challenge.

This is the section I leave the lightest. I like to use a phrase with a verb that defines the scope of the task. So something like:

“Understand why 25% of users are dropping off at the file upload page”

Or

“Design how we add second factor authentication to the sign up flow”

The verb acts to say what the scope is. Understand/design/review etc. This shapes the work of the team. Where the limits are. If it’s about understanding, that means we review as a team with next steps. If it is design, there’s a sense that we need to work on showing what the future should look like.

Activity

This is the part where you shape the sort of things you or the team should do.

If you’re shaping work for others, this is the most sensitive section. And where you want to be most aware of how much direction your team needs.

For teams with some experience you can call out the key milestones. Things like:

• Create range of options for how to tackle [problem]
• Agree with product team which option to take forward
• Take design through assurance workshop


For very experienced teams you could give even less. This section allows you and them to talk about process and must-dos.

For people or more junior teams you can be even more specific and shape how to tackle a problem. And the order. For example:

• Map existing entry points
• Review user research into entry points
• Compile analytics for bounce rates and journeys
• Review how other sites provide entry points
• Create presentation summarising findings and next steps
• Review work with [team] at team huddle

The key of course isn’t to dictate exactly what to do. It’s to create a strategy for how to solve a problem or make the most of an opportunity. For those with less experience, you give them their tactics. For those with more, you let them devise the tactics, but make sure key things are still covered.

With this section, whether for yourself, an experienced team or not, you’ve made the tactics clear.

If the situation tells you where you are. And the task how far you want to travel. Then activity is a description of what to bring when you travel. And what route to take. What’s left is the ultimate destination.

Results

This section makes clear the outcomes or results you think the work should create. What we should achieve.

In the traditional STAR method, it’s about measuring success. In this model, it’s about the outcomes you want to create.

It’s about asking “How do you want to judge success?”

This can range from metrics like:

“Reduced drop offs at checkout page by x%”

To task based things like:

“Got buy-in to redesign triage flow”.

I find sketching the results out also helps shape the activities too. And it can be useful to write this before the activity.

As with the others, this section is another conversation starter with a team to get a shared sense of success. Of what done looks like.

Creating a size and shape of work

After working through this format. You should have a good sense of the size and shape of work.

You have a documented sense of what you know, how far you want to go, what you need to do and what outcomes you want to create from a bit of work.

The format can be a workshop. A team effort or solo enterprise.

I’ve found it helpful to shape work for others. To make things clear. And make context obvious. Particularly compared to projects that I’ve not used this format.

If you find yourself needing to shape your own work or work for others. Use a format to structure your shaping. Try a format like STAR.