I’m a Principal Designer at Co-op digital.
I work in the web platform team. Our mission is to create a consistent web experience for both users of the platform (digital teams and content publishers) and give Co-op customers a seamless user centred experience online.
As a new year started we had 2 team days to reset our vision, team goals and revisit things like our ways of working.
Toward the end of the second day we had a session on roles and responsibilities where each member of the team wrote down what they did. Then the group was asked to explain what that person did before they themselves stuck the post-its and explained them.
When it came to me there were some answers – but more silence.
At that moment I got a bit worried.
Am I not contributing as I should? Is the work I do not actually helpful to the team and our goals?
Luckily someone pointed something very helpful out to me.
To paraphrase, “you have a more behind the scenes role now, more enabling – so we don’t always see what you do”.
In that moment another blog post formed.
What does a Principal designer do?
The image below is what I wrote on the day as the answer to what I do.
Let’s break each post-it down.
Clearly repeat why we’re doing this work
Clearly – because it’s my job to help our stakeholders and the rest of digital understand why this is the right thing for our users. Sometimes that’s slides, blog posts like this one or generally telling people in the street how great we are.
Seriously – this is important. Especially the repeat bit. It’s easy to loose sight of good work and the context that work was delivered in. Repetition is a well worn propaganda technique. Propaganda is not always bad.
Make sure user and business needs are met across products on the platform.
I help to ensure we’re doing the right work for the right reasons by asking:
- does this solve a user’s problem?
- does it align to our strategy and that of the wider Co-op?
- is it helping the business deliver something (within the bounds of the first 2) in a cost effective and iterative way?
- is this actually being designed and built in a best practice, scalable and flexible way?
If it isn’t – it’s my job to question why, and give evidence as to why we should do something differently.
Let’s get real though – if you have any kind of job – you’ll know that’s not what always happens. That doesn’t mean we should stop trying. See: repetition.
Understanding what our users say and do
It’s important I know what our users think of our services through face to face, remote usability research and our analytics. If I’m asked about how people use and want to use our service. I should know the answer.
If I don’t. I’ll be honest and try to find out. There’s a pretty cracking team around me who will know.
I help to form the strategy and vision of the web platform
As with everything here, I’m not the only one involved in these things. I help to set a direction along with our head of online, product manager and others. We also get input from our whole team and secondary stakeholders like the head of digital and head of design.
We’re currently tweaking our strategy which is something I’m excited to talk about the detail of in a future post.
I facilitate workshops, project kick-offs and weekly design critiques (crits) — and encourage others to do it too
I’ve split these activities up as I tend to see them slightly differently.
Workshops can take many forms and consist of a range of design related activities with aim of trying generate ideas to solve a problem. These ideas can then be researched. Often the people invited are subject matter experts in a totally different area to ours and may not feel comfortable identifying as having design skills. I can then tailor activities to help generate ideas without making people feel out of their depth.
Kick-offs happen at the beginning of a piece of work. They’re about a group of people getting a shared understanding of particular problem we’re trying to solve and the boundaries in which we are going to try to solve it.
“We have learnt that users want to do X so we’re going to build Y. But we have technical limitation Z”.
Design crits give the whole team the opportunity to feedback on whether they think the solutions put forward are best to achieve the goals we’ve set. It’s and open safe space that has rules. Everyone’s opinion is important and useful and is an important activity for any multidisciplinary team.
Equally these are not things I exclusively should run. If someone else is better placed or just wants to get experience they should do it and I will help them if they need it.
Which leads me too…
Line management, mentoring and pairing
Each Principal designer covers a specialism in design – interaction design, user research, content design and front-end – my area. A principal must have a good grasp of all these disciplines.
It’s matrix management so I manage the permanent front-end colleagues and contractors across digital but within my project team I’m responsible for all the disciplines in design.
Line management is hard and every book you read tells you it is something few people take too naturally. I certainly didn’t – but I think I’m getting there.
I can’t tell you what it is and it isn’t. I’m still finding out for myself as each new person has different needs and goals I try to help them with. For me that’s the key. Find out what they want now and for the future. Find out what makes them happiest at work and attempt to create the conditions where they have that.
Mentoring is part of line management but I pull it out because it’s a big part of what I do every day within the web platform team. It tends to be quick conversations about direction or to sense check something.
I used to find managing people really hard and it made me super anxious.
These days I actually enjoy it.
I literally never thought I’d say that.
I am responsible for the front-end discipline
At the moment this is the hardest bit of the job.
Keeping up to date when you’re not in the code everyday is hard. Side projects help – but working on the same stack as the team is more important. It’s not just to feel on a similar level. Actually it’s more about understanding the challenges people might face with our set-up and being able to usefully input in technical discussions.
Plus it’s fun and pretty therapeutic just building something once in a while.
To be honest the same can be said for design – although most of the design I do now are sketches to quickly get ideas across when mentoring.
I also:
- I try to recruit the (not hire) the right people into the right teams with the right skills
- run the front-end community of practice
- help to set the direction of our shared front-end tools
There’s enough to say in these three bullets that they may warrant their own blog post at some point in the future.
In summary
It really is a lot of activities around ‘the work’ whilst also doing a bit of the work as well.
Ultimately my goal is that either my direct product team or those I manage have the safety, freedom and back-up they need to do their job to their full potential.
It’s a tough gig – but I wouldn’t have it any other way.
