When I joined the mobile team at Automattic, we had one designer – Matt Miklic, who wrote about the explerience of leading that team. However one thing I was reminded of following some of the current discussions around product development is how we thought about and approached design at the centre of the team, and how we worked (and continue to work) to create a productive tension between design and development.
Product engineering teams rely on design to function and deliver. What you see when design is not present (or not delivering) is engineering being reactive and short term focused, or rabbit holing on large technical infrastructure projects. This is a common problem, especially as design has become a bigger focus and design organizations try to balance the integration in product teams with creating a community across designers within an organization. The alternative is designers isolated, reporting to someone who doesn’t really understand their work – not great either.
When design and development are both present we can move towards the productive tension of good decision making – the designer deeply understands and advocates for the user, the engineering lead understands the technical constraints. Together, they can agree a path forward that delivers the most user value over time, how best to test and iterate, what is required for V1 and what is required for “done”.
This requires that design has a seat at the table – the team leadership table, but also in every project. The designer needs to be present, integrated, and listened to. It’s easy for engineers to outnumber and overwhelm, which can make it harder for design to speak up.
But equally, there is no value to a perfectly designed thing that is never delivered (any more than there is to a unusable thing delivered very fast). The design has to be balanced with the technical work, the understanding of the components, the APIs that can mean seemingly small UI changes vary in time estimate between months and days. When I worked as an engineer on a deadline it was normal for me to go through the mocks with the designer, explain what was a component and what was not, offer alternatives and timeframes and let them decide what was shippable and what was an enhancement. It allowed us to deliver much faster, in a situation where we both understood – and agreed – on both what and why.
Matt and I muddled our way through creating this on one team, based on our own gut feelings, good (and bad!) experiences and a few examples. Then we set off to deliberately recreate it on another team. This really cemented it for me as a straightforward and workable model, but also highlighted the need for three things: staffing, focus, and competence.
Staffing: You can only take on the projects that you can staff, but if design is going to be this central to the team then design needs to be accepted as a limiting factor in what you can potentially take on. You can’t just allocate your projects and then divvy them up amongst designers and hope for the best – no-one delivers their best work when overloaded, and making design a bottleneck breaks trust, and leads back to the situation we started with – engineering working around them to deliver something (anything!). Navigating a really understaffed design team was an ongoing challenge for us, and heavily influenced what projects we could take on, and within those projects how we would approach things. If we couldn’t staff a designer at the start of a project (never ideal), what could engineering get ahead on? If we didn’t have enough designers for each projects what could we take on that did not require design?
Focus: Changing the way of working always requires a lot of focus, changing that way within some real constraints (such as understaffing) meant that we had to remain super focused and deliberate on the end goal. This requires a lead who is willing to say no, and being willing to disappoint people short term in order to be able to deliver a better experience overall. However it also required some pragmatism and balance, citing a far off ideal that is clearly infeasible any time soon just makes people impatient. To mitigate things like that, Matt allocated one day a week to doing trash pickup, so that little things weren’t kept waiting on design forever, but could keep moving forward.
Competence: This is not a statement on working with competent people in general (although like most people I much prefer that). But this model meant building leadership as a competence in designers, and user awareness as a competence in engineering. Both designers and engineers need to learn how to negotiate, and how to communicate pragmatically with one another.
The thing to remember is that a strong delivery team is cross functional, in a way that may or may not be reflected on the org chart. However when your teams differ from your org chart, the responsibility for developing and coaching needs to be super clear, along with the lines of accountability. For example, whilst onboarding a developer is primarily the responsibility of the engineering lead, onboarding a designer is a responsibility shared between the design lead and the engineering lead; it’s important that they support each other in that, and that the new designer knows who to go to for what.
So how do you create that productive tension? Some key points and milestones:
- Get clear on the users your team serves – user research, data, insight from support all help here.
- Define your team and design within it – make sure design has a leadership role.
- Educate the engineers on the users – their goals, their problems. Build user empathy as a team competence.
- Empower the designer as the user advocate.
- Engineering needs to engage with design from the start, providing sensible information on what’s easy and what’s hard, and understanding the nature of early exploration – which needs to be nurtured, not shut down.
- Make the space and relationships to have the conversations about goals and trade offs.
- Integrate design into the process – engineering needs to keep design in the loop on progress, share builds, and shouldn’t make adjustments to the agreed design without discussion.
- Ship together – it’s not just an engineering milestone, but an everyone milestone.
- Involve design in post delivery analysis – what does the data say people are doing vs what we hoped? What do we need to adjust?
Thanks to @MattMiklic, @Folletto, @lynneux and @skamille for their feedback and support.