/ JOURNAL
Why I’m going back to New Adventures
I have a rule about conferences: go once.
Like all rules, it can be broken — usually when Jeremy Keith is involved — but not often. Last year I went to New Adventures in Nottingham and enjoyed a day in a city I didn’t know, discovering its best coffee, mooching around a magazine store, and most of all spending time with people I hadn’t seen in years and miss hugely.
Given New Adventures’ history, it was an unapologetically nostalgic day. As most conferences are, it was hit and miss in places, but Ethan Marcotte’s quietly devastating finale made it really worthwhile.
I left Nottingham that evening as I’d arrived — happy to have been but with no plans to return. Rule observed.
And then New Adventures did something different.
From the outside looking in, the economics of conferences look hard. Safer to go with the most bankable names, when attendees know what they’re getting. Consequently, some design conferences can be like a watching a reformed band back on tour. You’re mostly there for the hits. But this also means conferences can often flatter rather than challenge an audience and the opportunities for learning — rather than confirming what you already knew — are hard to find.
New Adventures is doing something different this time round. Of the lineup announced so far, I know the names of just two of the speakers, and I’ve only heard one talk before. It’s a diverse lineup, and all are designers but working at the edges of the kind of design I do. And that’s where the learning is to be found.
I want more design conferences to do be like this. So, in January, I’ll be back in Nottingham. Genuinely a new adventure. Excited to be breaking a rule.
Units and silos
‘Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan.’
— Eliel Saarinen
Over recent years, I’ve consciously moved back and forth between design management roles and what Americans call an ‘individual contributor’. Wanting to stay close enough to making things; or creating the space as a manager for designers and teams to make things in the right way.
Right now, I’m all about working hands-on in a delivery team, doing the day to day work of a designer.
Being back on a delivery team has had me thinking once more about how we build delivery teams and how we make the user-centred design unit within them function really well.
Planning teams like these played a big part of previous roles, particularly at Co-op Digital and especially a spell where I was charged with recruiting, managing, and assigning designers, user researchers and content designers to delivery teams.
Here’s some things that have stuck with me from helping teams to form.
Good design needs good research. And vice versa. Good design feeds better insight; good research provides the material to design with.
Good design needs good content. And vice versa. Design serves the content. Design and content serve the user need.
Relationships matter. It’s not a given that every combination of user researcher, content design and designer will work well together, have complementary skill sets or basically get on with each other. Without this, it’s really difficult to generate the cadence, energy and alignment you want these partnerships to have, and the positive effect it can have on the wider team.
Partnerships that work are gold. Keeping people who do work well together makes sense for lots of reasons. It reduces the time a team spends forming, when relationships and understanding of how others work are already in place. But more importantly, I think it works for the individuals too: we’re often as motivated by who we are working with as what we’re working on.
Better planning reduces reliance on ‘seniors’. Agile’s emphasis on autonomy and collaboration can lead to teams relying on very experienced individuals in their respective disciplines. That reliance can inadvertently become a weakness. It can lead to professions becoming top heavy and expensive. It can make it more difficult to find opportunities to support interns and juniors without a delivery team feeling like they are ‘carrying’ a member of the team, making it hard to bring through new talent. But it shouldn’t have to feel like that. More conscious thinking about these combinations on teams can help - allowing you to, for example, pair a more junior designer with an experienced, broad-skilled researcher capable of providing some light-touch mentoring.
As design and research have matured and teams have scaled, so has the management around them. Where once there was once a solitary ‘head of user experience’, often there’s now respective management teams for design, user research and content design professions. That’s been for the good - helping to build teams with deeper skills; more structured career progression; better work, better outcomes. But it’s essential, I think, that the management of these disciplines collaborate really closely.
In larger organisations, I worry that this isn’t working as well at the management level as it is in delivery teams.
I don’t see enough thoughtful assembling of teams - designing a thing by considering it in its next larger context - and thinking too narrowly about individual professions rather than the wider design and research practice. The risk here is user-centred design units that aren't aligned around a problem space, or how to tackle it, together. The overlap between these roles should be a real strength: creating a culture of collaboration, critique that benefits the product and its users.
I have a few thoughts on how we might do this better.
Recruit together. One of the best things design and research roles can do is to play an active role in supporting each other’s recruitment, to help think about the potential recruit in terms of the next larger context: the professions they’ll work with not just the delivery team they’ll work in.
Don’t recruit to the delivery team. This sounds easy but is often hard in practice, when the need originates from a delivery team losing a designer. Better to keep the focus on the long-term balance of the wider professions and their needs, rather than the shorter-term interests of a delivery team. Even if that means finding other ways to resource that particular delivery team.
Plan together. At Co-op Digital, one of the most painful but worthwhile meetings we had was a regular review and prioritisation of our work: looking at where all our delivery teams were at, making sure we were focused on the right things, kicking off new work. It took a lot of time and patience, but it meant we didn’t just fill a seat - we assembled teams (or at least tried to) - and it created a good habit for us, as a leadership team, of collectively checking in on how our existing delivery teams were working together and performing.
Forming a team takes time. Moving people between teams can be a drama. It’s better to get it right than do it quickly. I don’t think I always got this right, but talking to people individually, showing your working, explaining your thinking openly always helped. Allowing them to say ‘no’ to a move is critical though. Few things demotivate people more than being treated like an interchangeable resource.
Always re-visit objectives before asking someone to join a team. I found it really helpful to remind myself what an individual was aiming to try and achieve over the course of the year, and to think about how joining a particularly delivery team might contribute to that. One of your fundamental responsibilities as a manager is to support and create opportunities for your team to meet their own objectives. Sometimes it’s obvious - to gain experience of working on a Discovery, getting more exposure to service design - sometimes it’s not. But it helps to see a prospective delivery team through the lens of those objectives and what motivates an individual.
Review how it's going. It can be easy to see planning teams as a fire fighting exercise: a task to be completed, a fire to be fought. Not all delivery teams are an easy sell, not every project feels worth being part of. If we’re asking people to do something politically tricky, emotionally complex, we need to support them through that. We’re not done when the team is formed.
Watch the team in action. Aside from all the usual reasons, show and tells can be a real measure of team confidence. An insight into how relationships within a team are playing out: what’s working, what’s not. The kind of research work they choose to prioritise; whether design is contributing beyond just the user interface; how professions collaborate; and how strong the connection is between research and design decision-making. Don’t just rely on a 1-to-1, observe the whole team in action.
We’ve made real progress in user-centred design in building understanding and appreciation of the professions within it – interaction design, user research, content design and more. There’s a sense, in the sectors I work in at least, of an improved understanding of career paths and what it takes to move from junior to senior practitioner. But we can’t think of our professions, or the development of individuals in isolation. Our responsibility is broader than just our direct team. That user-centred design unit can be so powerful, so it's vital that design, user research and content design leadership shares a collective sense of the values they are trying to instill, recruit for, and better still, demonstrate them at leadership levels.
My thanks to Matthew Solle, Gavin Wye and Simon Whatley for their thoughts and improvements to this post.
The floor
Over the last few years, I’ve been lucky to be a part of different organisations all trying build a delivery culture at scale. And it might surprise you that my favourite example of making that work remains HM Revenue and Customs (HMRC).
Back in the early days of 2015, HMRC’s two locations – in London and Newcastle – didn’t have as much in common as they should have. Different working cultures, different agile maturity.
Not everything was right back then, but what those locations had in common was critical: row after row of delivery teams, all sharing the same space, and a quiet buzz of delivery. The floor.
If you wanted to know anything about government, tax and digital services, you could see it right in front of you.
Designers sat elbow-to-elbow beside delivery managers, business analysts and user researchers, developers and product owners. In London in particular, teams were hunched over laptops around thrown-together desks and mismatched chairs. There were few home comforts: the lighting terrible, the heating erratic, the toilets unspeakable, but the place had an energy I’ve missed since.
In all the time I’d been working around agile teams before that point – this, in my head, was what it was meant to look like.
Although to an outsider’s eye, there’s sometimes an air of lightly organised chaos, the close proximity of teammates is critical in making collaborative working not just desirable but inevitable. This isn’t a team making itself comfortable, it’s readying itself to deliver.
There’s a point in the maturing of an agile organisation where let’s-put-the-show-on-right-here spontaneity isn’t enough, and something more thought through is needed, to build on what’s already good and deliver it at scale. And that’s when having the floor really matters. Teams scattered around buildings tend to isolate what’s good, relationships can't form, it’s easier for struggling teams to suffer in silence, there’s a loss of common purpose.
Physical environment matters as much as location.
When teams share a floor, you very quickly get a sense of how well they are working. It’s not too hard to see when a team is struggling and heads are down: agile by rote, not conviction. It’s easier to feel the teams where the energy is high, the momentum real. And it’s easier for these teams to support each other, easier to share. Show and tells become more accessible, communal events – a thing for everyone can learn from. Walls share the thinking, serendipitous conversations in the kitchen unexpectedly solve problems.
At its best, the floor sustains itself. It becomes a community.
My thanks to Matthew Solle and Michael Owen for their thoughts and suggestions on this post.
Case working and the user
This week, I was back in London to attend Designing Caseworking Systems, a meetup organised by Chris Taylor, one of the designers I’m now lucky to get to work alongside at the Home Office. This might sound like pretty dry stuff, but case working is the thing I’m more excited about in government than anything right now.
We’re in a fortunate, and hard-earned position in government: there’s a maturing design language and patterns for public-facing digital services and a broad understanding of the coherence it has brought to digital public services and the benefit to users: simpler, clearer, faster.
In departments like the Home Office, we’re focussing more and more on how that design language and those patterns might apply (and need to flex) to the other side of these services: the case working systems used by civil servants and agency workers.
We’re designing at the opposite end of the scale in a way: for public-facing services, we’re often dealing with one-time transactions, designing to explicitly avoid our users needing to become experts in our interface. With internally-facing services, we might be designing for experts (and novices who will, in time, become experts), who are using the same digital service all day, every day. It calls for thinking differently about who the users are in this context, the role of the digital service, the actual experience of work we’re involved in creating, and satisfying a somewhat different set of user needs.
Elle Tweedy, one of three excellent speakers on the day, gave a really thoughtful talk on the work Futuregov are doing with three London boroughs authorities to reimagine their complex mix of social care systems.
I was particularly taken with a point Elle made about the opportunity to really rethink the relationship between the case worker, the case working service and the actual user of the service (who I’ll refer to from here on as ‘the service user’). The digital service can often sit as a barrier, sometimes literally, between the humans involved in this process. As Elle explained, it doesn't need to be like this.
If we imagine what a modern digital case working service might look like, it’s probably not something that only the case worker can see to the exclusion of the user. Probably not something where the user only appears as a line, a 'case' in a case list.
It might instead be something that starts from a principle of assuming the service is open to both case worker and service user. With more emphasis on shared screens and an ability for both the case worker and the service user to contribute independently. It might involve designing for different contexts of use, including collaboratively over a shared tablet screen. Of course there will often be compelling reasons why information has to remain confidential from the service user, but you can immediately start to see a chance to change how it feels to be a service user. A more transparent process. A user better able to understand where exactly they are in that process. A user who has agency, is an active participant rather than a passive recipient at the mercy of a contact centre. There’s a more collaborative, informed experience, rather than a user and their case being shunted through a series of process gates and escalations, never visible, never understood.
It can be easy to lose sight of the human, the user, where case working meets digital service. Perhaps we don’t readily think of our service users as also being users of the case-working service itself. Maybe we should.
This Design Life
Late last year, Chris Green invited me to take part in his excellent This Design Life series of interviews with designers. As Chris describes it, it's "a look into the lives of designers. What makes us tick and what makes us better."
Here's what I had to say.
‘The very best decision I made in my career was to quit a really good job and go freelance. I have Leisa Reichelt to thank for that, for me giving me the confidence and the belief.’
Read the full interview at This Design Life.
Older posts Newer posts