CREATING A SENSE OF Ownership
As a design leader I always pushed for Ownership. There’s a number of ways to build a culture of ownership. One where designers feel truly part of creating something meaningful and not just a cog in the wheel or pushing pixels.
It starts and is rooted in how you as a design leader approach your reports.
<Insert Design ActivitY Here>
Many designers are just doing the design activities wrapped in some sort of process. They’re told to wireframe this page, create a user flow, or maybe do some user research. Or ya know: “do this design activity”.
Often it’s a design manager/leader telling designers to do this. Whether directly or through following some design process. The designer create the wires, flows, research, etc.
There is ownership in this way. But designers are more or less following orders. Carrying out a directive. And not to knock the design manager - I’m sure this is down with all good intent from the manager.
In other cases designers are assigned to the project as the designer. Without much design management support, the PM more or less leads and expects the designer to producer designer things - wireframes, flows, pretty buttons.
Being assigned like this doesn’t create meaningful ownership however.
Let it Go, LET IT GO
Ownership is letting go. Less directive, more coaching and guidance.
Instead of:
Conduct user interviews
Document a user flow
Create Wireframes
A better approach is:
Here’s [the product problem]; your job is to work together with the rest of the product development team to ship a an update to the app that solves this problem. We’ll know we’re successful through these indicators …”
The above is light and loose. Hopefully you have some sort of PRD that fleshes out the problem in detail. The point is it focuses more on the actual problem being solved, framing the challenge, and the designer’s role in said challenge.
A Shift
Already the focus is off the design activities and more on the actual product itself. Your designer - and the team - should (hopefully!) understands the designer is going to do design related activities to help achieve the goal. (if not then yikes!)
It’s not about the activities. It’s about the app/product itself. It’s setting expectations and framing the challenge.
It’s a big shift in how you think about the role of a designer. You’re not responsible for the design artifacts per se - but the design of the shipped product that customers use.
Of course add more context.
You’ll want to give more guidance than above. As a hypothetical, here’s what that guidance might look like:
You want to make sure you research the problem. Work with the research team (or conduct your own)
Explore the solution space. Go wide with concepts ranging from simple to complex.
Build confidence in your solution. We want to know what we build we have a high level of confidence in when it’s ultimately shipped.
Bring people along the process - be communicative and collaborative. We as design team are the connective tissue and want to make sure everyone is involved along the way.
Those are a few hypothetical ways to help shape and frame the challenge.
Sweeten The Pot With Personal Goals
If you really want to lean in, you can throw in a designer’s personal goals as part of this project. For example:
One of your personal goals was to grow your presentation skills - when you get to exploring I want you to give a detailed presentation on how you went about it. Invite PMs, engineering, and commercial to this.
Manage The Work // Lead The People
In this set up you become more of a coach / mentor / leader and not managing the person.
It doesn’t mean you abandon them. You’re still with them along the way - overseeing and guiding. Maybe you’re checking in regularly or built in stop gaps to make sure things don’t go too far without you seeing.
Poke, Pop, and Pump.
You can still (and should!) poke around in Figma files. Leave comments, offer design suggestions. But from a leadership view. Less “this design should be like this” or “make this layout like this” and more “is it worth pulling attention away from xyz?” , “what would happen here in [xyz] scenario” , “what problem is this solving?”.
Of course lay out any concerns as well.
Pop into meetings, and check the status of tickets.
With a bit more autonomy things won’t always be on the up and up. There will be frustrating moments - you as a leader know this is part of the journey. So make sure to encourage them and pump up your designers up when needed.
What this approach does is give the designer more autonomy over the decisions and direction of design. They’re not carrying out design activities because they were told to.
They’re choosing the direction, putting together a plan of attack and setting the course to set sail.
As a design leader you might not see too much difference in this, but in the shoes of a designer, it’s huge deal.
And all of this helps build ownership and trust.
Set Em Up, Knock Em Down
An analogy bowling. There’s 10 pins and the job of the designer is to knock them all down. Hopefully in one go.
You don’t tell them how to approach it. Maybe they want to grip it, rip it and throw the heat straight down the middle. Or use the fancy spinning curving ball which I can never get right. Either way. let them choose.
You’re watching them bowl and the scoreboard. Keeping tabs on progress. Maybe your hand is hovering over the bumper rail buttons.
When they’re facing a situation where only a few pins are left up you may advise, but let them choose how to approach it.
The Big Caveat
All this sounds well and good but a key driver in the success of this is you as a design leader. It’s up to you to create and foster a culture where this shift can happen.
This involves leveling up your team’s craft, building solid working relationships with other departments, proper people management, and injecting business strategy into your design culture.
