Be in the work.
No ifs. No buts. There is no-one else who can do it like you can.
I was asked yesterday: ‘Mark, do you design anymore?’. I had to pause. ‘What do you mean?’ I replied. Of course, they meant do I make things with pixels, directly. Do I spend time in Figma making things from scratch. No, I don’t. But I still design. Just in different ways.
Design leadership is not (always) about navigating the echelons of company hierarchy. It’s not (always) about line management or running a team. Running a design company is not (always) about pipeline or sales. I see, hear, and read much of the design leader playbook and it never talks about the work.
For me, it is all about the work. And you have to be in it to see it. To feel it.
That doesn’t mean you have to micro-manage. It doesn’t mean you have to impatiently take over if someone is not getting your feedback or going too slowly. It doesn’t mean you have to do it yourself. You probably shouldn’t if you’ve spent time building a team more talented than you are.
Be careful about being in the work around the work.
Being in the work is about seeing and feeling where you are. On the path to better quality. Giving a gentle nudge here or a firm correction there. On the path to building better experiences for your customers. Being in the weeds should never feel beneath you. That is where the work is and the further away from that you are, the less able you are to influence the quality of it.
Note: these are notes to myself. Sometimes made years ago as a result of something or other. But this one was from yesterday and my reflections since.
]]>Years ago, I started writing down the things I’ve learnt being a designer and running teams and companies. Mostly so I could articulate a challenge, a thought, a mistake. Like a little handbook. I found it the other day, and listening to the talks for the past couple of days at Leading Design has spurred me into action to add to them, but also to type them out, and publish them here.
I miss writing. I think it’s one of the most under-valued skills a designer can have. Writing something down in as few words as possible, encapsulating a thought, message, or idea, is a skill that takes decades of practice. And I’m out of practice.
So bear with me whilst I shake off the rust in public and share what I’ve learnt. Please don’t take me for being rude, but it’s not for you. It’s for me. Warts and all.
Here’s what I have managed to decipher so far from my scrappy little notebook. I’ll update this as I go.
Don’t under-estimate the value of routine.
Routine can be an anchor in rough seas. When things are hard, simple routines provide a comfort. It could be having a coffee at a particular time of day, or sitting with your cat for a quiet 5 minutes. But routine can be for others too, and they can also be for your team.
Started by my ex-colleague Christian Palino, every Friday afternoon I post an update to my team.
There are the usual reminders and logistics. Updates on going projects or company news. But often - with communication already high in the team - I’m repeating myself. I was asked this week ‘if you have nothing to say, then why do them?’
Even if there are no real updates there is always something to say. In those moments, I write about something that happened to me this week. A small anecdote. Something human. Something grounding. No design mic-drops. No condescending words of wisdom.
Just a few words, regular as clockwork.
An anchor in rough seas.
]]>Does it pass the morning test?
The morning brings clarity. A step back. A precious moment unencumbered by the work of the day.
Chasing a solution like following the string. One poor design decision leading to another. Before I know it, the work is myopic and unfocussed. Chasing my tail all day long. And, often, I’m blind to it.
The morning provides a pause that I take advantage of every day. Looking at the work from the day before and asking the simple question:
Does it pass?
No? In the bin it goes.
Yes? On we go.
]]>Andy tweeted this earlier today:
Whenever I see the portfolio of somebody who describes themselves as UX/UI, it's almost always 90% UI.
— Andy Budd (@andybudd) June 16, 2021
As I wrote about on Monday in my weeknotes, the idea of a portfolio has been on my mind for a while now. It seems to resurface every year or so. I’ve reviewed hundreds – maybe thousands – of portfolios in my career. I’ve also presented mine a good few times.
As it’s been on my mind, I replied:
What does a UX portfolio look like?
— Mark Boulton (@markboulton) June 16, 2021
(he says, retreating slowly backwards into a bush…)
How do portfolios fit when you are the only product designer in cross-disciplinary product team? How do they work when you are the UX lead in the digital team in a science organisation? What do you show? What do you write about? What if you think you are a terrible writer? What if the only output of your work is a few deliverables like a service journey map and a few wireframes? What if the reality of your work has been to grease the cogs of a challenging organisation under the guise of being called a UX Director? Where is the portfolio here?
I’d like to unpick a few of the issues that I think are the problem with the expectation of portfolios for different roles.
If you are a product designer applying for a senior product designer role, then, yes, your portfolio should prioritise design craft. First and foremost, this is about ability. But a close second, more so than methods you might have used to gain insight, or what the commercial outcomes might have been, is an explanation of the context of the project: the client, the team, the goals, the approach. That’s it. It doesn’t need to be lengthy.
But if this is a UX role, or a UX manager role, do not expect to be presenting pixel perfect mocks. And if you are the hiring manager, it’s your job to make sure that no-one is going to waste their time doing so. Set expectations.
This is why UX/UI is such a terrible role description. It represents a continuum and, without qualification, can lead to a lot of wasted time.
Expecting well-crafted long-form stories of projects is not an inclusive position. If it is expected, it should be in the job description.
Portfolios have always been about demonstrating ability, yes, but mainly they are a sales tool. And good sales methods are conversations. Your portfolio should invite inquiry. A reviewer should leave wanting to know more. The best portfolios I’ve seen were not complete job histories and thousands of words long. They were snapshots of contexts, approach, and skill. And I always wanted to know more.
A good portfolio is a foot in the door.
When interviewing for a role, you don’t walk through your entire education and work history. You may be asked to present on a particular thing, or be asked to walk through a project or two. The portfolio can then act as supplementary material to the discussion you’ve just had, but this is different to the portfolio you used to get the interview. That’s a sales tool, remember. This other portfolio is follow-on.
By having a bank of projects at your disposal, you are able to curate collections of work applicable to the job you are after.
Well, this is a big ‘depends’. Do you even need to be a designer to lead a design function? In many big tech orgs, I’m not sure you do anymore.
If you ask me, if you are the design leader of an organisation, then the quality of that design output ultimately is your responsibility. If your time is spent inching that seat ever closer to the table, it is not spent nurturing the quality of the work. By time spent, I mean focussing on the environment, the diversity of the team and their backgrounds, pushing the quality, and empowering designers to do what they do best and get better at where they are weakest.
That’s what a design leaders portfolio should be. Stories of how they’ve built diverse teams, delivered amazing work, and moved the needle, whatever that needle is: profit, share price, charter renewal, NPS score (shudder).
So when job descriptions for VPs or Directors of Design crop up asking for portfolios, I try not to wince. This is how I look at it. They are asking for some stories.
Nobody has enough time. Ever.
In my first job, the art director reviewed new portfolios in moments. They sat on a big pile on the desk and were sorted into two piles: ‘no’, and ‘let’s ask them in for a chat’.
For the ‘no’ pile, no feedback was given. Just a ‘no thanks, we’ll keep you on file’. We didn’t. Nobody did.
I’d like to think things are better. When I’m reviewing portfolios they are still sorted into two piles, but I try to give written feedback if I have time. If I’m reviewing design work, I’m looking for a couple of things:
And, really, that’s it. I am less interested in methods and being able to apply the right UX method at the right time. Or how lovely your journey map looks. Don’t get me wrong, those things can be useful examples to help explain a project, but they are transitory artefacts and, often, too much time is spent making them beautiful because they correspond to line items on an invoice to a client.
For those UX roles that require a portfolio, but the applicant only has artefacts from UX methods to show for it, presents a conundrum.
How do you talk about the work when the work is collaboration, workshops, research, and lo fi prototyping?
If you are a good writer, then it’s no bother; write the story of the work, sprinkle in photos of post-it notes and people looking at walls, a few screen grabs of Miro and you’re golden.
But what if you aren’t?
Communication is a critical skill in UX design. I’ve met some very good UX designers who can traverse complex organisations and stakeholders, manage difficult workshops, conduct insightful research, but struggle enormously when writing a case study about themselves and their work. This is not a failing, but a demonstration of preference. For these people, we need to find ways in our hiring processes to include them.
If you feel like this might be you, I’d encourage you to create some simple one-pager written project debriefs. Write them like a sprint retro: short, punchy, and direct. Explain the project, what went well, and what didn’t. Don’t feel like you will be judged on your ability to craft a good story but on your ability to solve hard design problems.
This is what I expect from a good portfolio: