Co-creating has drastically improved my designs

How co-design has drastically improved my work

Users, engineers, product managers… I’m not the only one designing things around here

An image of a wireframe, some sticky notes and various cursors, denoting a co-design workshop.

I find defining a problem challenging. Ideally, at the start of a project all the metrics and objectives form a crystal clear statement. But working with high ambiguity in the platform space, I often start with a knowledge gap and a lot of assumptions that need working out.

Doing things quickly with the lights off

Unanswered questions are healthy in an untapped product area and drive some of our most valuable research. This means lots of interviews, shadowing, surveys and quant. analysis to help us to attack important learning goals.

As these activities rumble on, we get a cleaner idea of what needs doing. The performance goal is continually remoulded and sometimes split into pieces. Our problem statement slowly takes shape.

However, the challenge here is that we are treading fresh ground at a fast pace. Projects are sometimes time-boxed to a single sprint. So actioning insights can be overwhelming. It’s easy to miss a detail or distort the truth.

The danger of closing the door behind you

At some point we need to lift and shift our research into design. Ideally we’ll conduct continuous discovery indefinitely. But there are still moments when a designer has to commit to one idea and filter out others.

I hate the thought of handing written requirements to a team of engineers and waving goodbye. Especially when dealing with tranches of data and highly technical systems.

There are two things at this point of departure that trouble me the most:

How do I know I’m right? Is this really what the user needs?
How do I know this is feasible? Have I made this clear to the engineers?

Justin Jolley hits the nail on the head with his piece on co-designs, we all hate rejection. And it’s common if you go it alone. Below, I’m going to run through how I try to mitigate these issues.

1) Co-design the problem

It’s not uncommon for some designers to pack their bags and abandon research prematurely, leaving a break-up note for the user, “it’s not you, it’s me.” Really meaning, “I’ve got what I needed, I’ll take it from here.”

This might happen when they feel they’ve reduced the chaff and arrived at a point of problem definition. The middle of their Double Diamond.

An double diamond diagram. — Double Diamond based on illustration by Digi-ark

But who is the quality control at this point? You could smash it with your research, then fluff the problem definition. If this happens, your designs will be grown from the wrong DNA.

You can validate the problem with users

Because I find my problem definition evolves significantly throughout discovery, I like to validate it with users and then work with them to co-create user stories from it. These stories form the core of our acceptance criteria.

We might draft several problem statements from our research. We map these by value/feasibility as a team, including the insights of engineers, analysts, product managers and other specialists.

We pick our top opportunities (problems to solve), acknowledging any questions still lingering in the air.

At this point I’ll catch up with the users. I’ll present them with these top problem statements to be validated or tweaked. I might also mention the statements we avoided and confirm the value of those we picked.

Explore when these problems occur

I then ask the users to give me a few common scenarios for each problem statement. This helps us achieve context.

Then we go through each scenario and co-create an abstract user story that solves the problem. This also helps us to means-test the perceived value of each solution. If we feel like we know the product metric we’re improving (e.g. handling time), we make sure that metric is alluded to in each scenario.

So the workshop structure goes…

The problem to fix

An example of a problem statement that has been iterated and refined with users. — Rough example of a problem statement refined with users

When does this happen?

An example of how a problem statement might be shown in context by users. — How the above problem statement might be shown into context

How can we overcome this?

An example of an abstract user story co-created with users to tackle a problem statement. — An example of how you can make scenario specific stories to identify value

We try not to cram too many things into one story. And we are careful not to prescribe overly specific solutions, so they really fall in the grey area between problem statement and user story.

2) Co-designing the product

I usually try to keep engineers updated throughout discovery, so there are no surprises when they are expected to start building something.

As I mentioned above, they are involved at key steps such as assessing the feasibility of an opportunity. And they often like to sit in as observers during interviews and shadowing sessions. But at the point of early solution design, they take on a lead role.

Co-designing with engineers (and the team)

We conduct a team-wide (or inter-team) workshop with multiple disciplines. I present the user stories we have now validated. Then participants are split and given different user stories to design solutions for.

We time box the workshop steps. Something like a Miro board is prepared with wireframing assets, simple frontstage/backstage flows and other useful tools. We want to avoid obstacles and empower participants to get stuck in.

Consider what techniques your participants will be most comfortable with. Rohini Malpe’s article on various co-design methods describes some useful approaches.

Example of front/backstage flows with mini wireframes

Questions are encouraged. We set aside lots of time to discuss everyone’s ideas and even arrange follow-up sessions. If there are enough people on the call, I might add a fun competitive element by giving the same user story to more than one person/team.

Co-designs at this stage are great because the engineers, who have already been exposed to the problem and research, are now able to articulate ideas and flag barriers to success. If this was their first exposure the project, half the session would be spent playing catch-up.

After these sessions and discussions are wrapped up, I take away the designs and refine any prototypes, maps and acceptance criteria. I contribute to the tickets that are raised and try to stay involved throughout the build, scheduling time to test when we can.

Conclusion

I might be needy, but validating my ideas and sharing the responsibility of creating things has given me more confidence. And I love how proactive our users and colleagues are at being involved. The design arc needn’t be dominated by designers. We are just here to provide the conditions for problems to be solved. We don’t solve them by ourselves.