Fixing design in squads

I’ve worked in several waterfall projects in big corporations, where development and deployment happens at a glacial pace. I often found myself lusting after jobs embedded in product teams in squad based companies. I dreamed of a promised land full of autonomy, responsibility and recognition, constant shipping and feedback and improvement. Sigh… The grass is always greener.

My role: UI Team Leadership

In one of the startups I joined, the squad based model was causing people to pedal fast but achieve little. A string of underperforming features and initiatives had led the start-up to burn through much of its series B funding without showing the growth expected by investors.

After my first design project was cancelled after 6 weeks of work, I realised the company had some serious design strategy challenges. Together with design director Alex Horstmann, and fellow lead designer Kieron-Scott Woodhouse, we devised a way of reasserting the importance of human-centred design and reintroducing some discipline to the design process. I learned a huge amount during this process, and our team is now humming along, delivering great outcomes for the company.

A well trod squad

The benefits of squad based agile are well known, and don’t need repeating here. What the company was doing well was deploying code quickly and regularly. It was responding in lightning-quick time to stakeholder requests and changes in the market.

What it wasn’t doing well was delivering good outcomes. Engineers were focused on shipping fast, not the problems being solved. Feature decisions were being made on what would ship in the smallest possible time. Companywide strategies were rapidly splintered into projects that were focused towards fulfilling the requirement with the least possible development. QA and performance was subservient to rapid deployment. Any doubts about the design solution were deferred — promises of iterations which never came.

Lots of things weren’t being measured, and what was, was being measured in flawed and biased ways. Even what was measured was being communicated in a haphazard way.

The designers, especially, were unhappy with the quality of their output. With no time for gathering evidence, or generating and testing ideas, design decisions would be made on the hoof. Solutions were provided by stakeholders all over the business, but rarely interrogated.

Bizarrely, despite the fact that designers would turn around screens in hours or a couple of days, and there was more design work being done than being developed, the most common word to describe the design team was “bottleneck”. There was an terminal lack of recognition of the value of design to the production process.

The symptoms of squaditis

Overworked designers hurrying with no time to think or plan

Designers were generally being asked to visualise the ideas of product managers and other stakeholders in one or two day turnarounds, whilst developers twiddled thumbs and waited for the artwork. No time for research, problem framing, ideation or prototyping. Design was a single column in an engineering kanban board.

Designing straight into high fidelity

There was a perception that it would be quicker to design more quickly in high fidelity. And if you have UX designers who can also do UI — why not? The designer role was frequently reduced to graphics package operator with stakeholders directing from the shoulder. With no framework to demonstrate the value of design thinking or practice, the stakeholders weren’t going to improve their behaviour any time soon. It was the opposite of the ideals of trust and autonomy promised by squad-based culture.

Little shared expertise or peer reviews

Designers felt isolated in squads, and were so overworked they they felt there was little time to organise guilds, share knowledge and support, and most importantly, peer review each other’s work for consistency and standards.

No prioritisation or coordination across squads

Some squads had no designer at all. With a lack of awareness about design velocity or resource, design time was being allocated day-to-day. Designers didn’t feel able to say no to product managers, and it was the quality of the design that suffered.

Poor quality delivery — no QA step

With all the time spent tweaking high fidelity artwork and fielding new requests, there was no time for designers to review code in staging. At any point during development, the scope could be changed without the designer’s knowledge and broken up into “iterations” which never came. The resulting delivery rarely bore much resemblance to the original design, in appearance or feature set. The product was essentially untestable.

Poor communication

A continuous delivery pipeline, with designers excluded from the few ceremonies that there were, gave little time for evaluation of the design process. Failing fast only works if you learn something. Design mistakes weren’t being recognised, and actions weren’t being documented.

Poor results

For some teams, an obsession with A/B testing and narrow OKRs motivated squads to work on what was perceived as low effort/ high reward jobs, with little overall feature strategy. Larger build tasks were broken into smaller chunks and delivered and A/B tested independently. This obscured major fundamental usability problems that we revealed through qualitative usability testing. The user experience was inconsistent, half baked, unlikeable. Any benefit gained from feature development was small, and for some teams, virtually nonexistant.

Sprint therapy

You may be thinking now that this was just half-baked agile — and you would be right, but it wasn’t the only problem. One solution might have been to double down on resource and recruit more designers, so that there were at least 2 per squad. That option wasn’t available to us. With fewer than 8 designers facing off with around 60 engineers in 7 squads, we would have to think laterally and cross-tribe. The plan was delivered in 5 stages.

Stage 1: Detach the design process from the development process

The short term priority was to give the design process visibility. We created a new Jira project per tribe, which gave us access to a backlog, sprint planning, velocity and retros. Some of these agile ceremonies were happening in the squad boards, but they were engineering focused, and gave little constructive data or feedback for improvement for designers.

Organising design at a tribe level allowed us to pool talent and resources. Designers might have experience working from research to prototyping and UI production, but they are rarely deeply skilled at everything. Some designers are more comfortable working at the research and strategic end of the process, some love to solve problems with screen design and some work with developers to polish up interfaces. With a single designer embedded in each team, it would usually mean some tasks would be rushed or skipped entirely.

We split our backlog into research, discovery, flow analysis, wireframing and UI tasks. This not only gave us a good idea of who would be best working on it, it also allowed us to estimate on each design step in isolation. This gave stakeholders and PMs much better visibility of the end to end design process, and how long it would take, allowing them to prioritise more effectively. We made it clear to stakeholders that we wouldn’t be following a design process dogmatically, only introducing design tasks where they were relevant and necessary.

At a tribe level, we were able to introduce regular informal feedback sessions — peer review is much less intimidating than a guild-level session.

Difficulties with stage 1

There was some concern that having separate design boards might cause confusion by splitting the documentation. We linked the design issues in Jira with their corresponding issues in squad boards. Many developers came to prefer this, as long design conversations and design proposals were confined to a separate channel, rather than cluttering the technical channels.

Stage 2: Initiate design sprints, one sprint ahead

The first few design sprints were galling for the PMs, as they needed to start thinking ahead, supplying us with fully researched, prioritised and briefed work to complete two weeks ahead of the developers.

We were flexible on the content of project initiations, but not on briefs. Briefs took the form of user stories with hypotheses and supporting data. If a brief wasn’t fully formed, we could turn it into a discovery task, to help the PM identify goals and outcomes, to ask questions and banish assumptions using qualitative and quantitative evidence.

For some PMs, this was an education exercise, because they were unaccustomed to interrogating ideas to this level of detail or communicating that detail to designers. Despite some reluctance, rarely could they argue against the case we made for fully fleshed out briefs.

Being thorough with our briefs and discovery phases helped focus everyone’s attention on the problem rather than the solution. On more than one occasion, it helped us find evidence that users didn’t want the feature to begin with, so we could be comfortable terminating the project long before developing it.

We started with no idea of velocity, and the first couple of two week sprints were completed without strict estimation.

The squads needed to work on non-feature work for a sprint or two before the design work came in. We suggested they work on technical debt until the features were ready.

Difficulties with stage 2

Squads accustomed to continuous deployment found it difficult not to work on new features, and some attempted to shortcut the process by starting dev early and by bypassing discovery and design altogether. Both attempts were highly unsuccessful mainly due to unclear goals and outcomes. We were later able to highlight and improve these in retros.

To compensate for the perception of inflexibility in the process, we agreed to hand over work as soon as it was ready, rather than at the end of sprints, and engineers agreed to wait until work was handed over before grooming solutions. In the end though, the new rhythm became clearer, and the engineering squads followed our lead and began to work in sprints as well.

Stage 3: Plan, plan, and plan again

We began to run sprint planning ceremonies where all the product managers and directors in the tribe could review, discuss and prioritise our fully fleshed out design backlog. We encouraged attendance by gently reminding PMs that their work may not be prioritised if they tried to feed their work in by other channels.

As designers, we were simply there as facilitators of the discussion. I had initially imagined these sessions might be confrontational. But the product manager peer group was engaged, reasonable and focused on getting the best outcomes for the whole tribe. In the sessions, poorly thought out ideas were called out by peers and pushed down the priority list or back to discovery, which compelled PMs to properly frame problems and brief their work.

With full and consistent briefs emerging from squads, it was much easier for the product director to keep a view on outcomes, and they became a more effective, predictable and, less reactive arbiter and representative for business strategy.

After two sprints, we introduced story point estimation and after one more sprint we had a very good idea of the velocity of the team. This gave us a very clear idea of the effort that could be spent, and sprint planning ceremonies began to go very smoothly indeed — we’d often finish well before the 1hr time limit.

Problems with stage 3

There was a feeling from some PMs that detaching the design process from the engineering process would result in a loss of control over the programme of work by PMs. We asked for their faith here, and agreed with them that if the new operating model was to prove less effective, we would roll back. Once they had become accustomed to the planning sessions, they realised they still had full control over priority and schedule.

There was the perception that designers were being removed from squads to join a new team. Managers are always fiercely protective of resources. Again this perception was dismissed after the first sprint planning meeting. PMs became much more aware of resources across the tribe, and encouraged each other to justify that resource to their peers, rather than ringfence it.

Priorities in startups change quickly and constantly. Some PMs weren’t happy to wait two weeks to discuss new stories or assess if the sprint needed reprioritising. At their request we added a half-sprint replanning ceremony. But this wasn’t well attended and we decided to stop them. I interpreted this as a change in behaviour amongst the PMs, who had become used to thinking ahead, and deploying resources more proactively.

Stage 4: The ceremonies: Technical reviews, show & tells, wireframe and UI Handovers

In the original embedded design process, engineers felt connected to the design solution because they were co-located. The designer would show designs to developers on the local machine, informally and one to one, allowing constant feedback and iteration in the design. Technical considerations were fed constantly into the design.

But some of the changes were suspect — for the sake of convenience and speed of development. Decision making was opaque and undocumented. Originally the team we colocated in Spain, this way of working became increasingly unsustainable as the team decentralised.

Moving to sprints allowed us to schedule more formal reviews and checkpoints for technical and product oversight.

• Within the team, we requested ad-hoc peer review sessions. Focussed on idea generation rather than critique, these were useful in getting over periods of creative block and stagnation, and were sanity checks on more unusual ideas.
• For the product managers, we booked in weekly show & tell sessions, to show work in progress, review work against goals, and accommodate feedback early on.
• For all of the engineers, we organised technical reviews of low fidelity wireframes. Discussions centred around feasibility, effort and the quality of the solution, and new ideas were welcome.
• Once the solution had been agreed, we worked on hi fidelity UI specifications, ending with a UI handover to the FE team. Discussions at this point could be centred around usability, content, style and branding.
• We asked for a UI QA step before deployment. The product of this would be screenshots of the release candidate, a list of small snags in the UI. These were prioritised and remedied before release.

With UX designers able to operate graphics software, low fidelity wireframing was previously seen as an unnecessary step. But we demonstrated that design ideas and proposed solutions were better assessed as early as possible in the sprints and at the lowest fidelity possible. It allowed back end teams to analyse any new data requirements for the design and to get started earlier. In many cases this meant the data structures and APIs were ready before the front end team started work.

The front end teams could analyse interactions and carry out spikes to discover the effort required to solve them. Any changes that came through technical limitations could be incorporated in low fidelity. The hi fidelity UI step could then be produced much more quickly, with iterations focused only on solving creative problems rather than business ones.

To facilitate communication of designs, we used a combination of Jira, Figma and Zeplin.

Difficulties with stage 4

A technical review isn’t always the best forum for feedback. In general, we found our engineers tend to be an introverted bunch, preferring to prepare responses than in reviews. There’s also not much time to review things in depth. We found it useful to send out links the day before reviews and handover sessions, allowing the engineers to prepare their questions and comment directly on the artwork.

Showing work in progress and low fidelity work through Figma gave access to engineers of unfinished designs. With unlimited access to this work in progress, they became confused about what was ready to develop and what wasn’t. A couple of times, they started development before the designs were ready and had to roll back when the designs were handed over with major iterations.

Although Figma’s cloud file hosting and sharing makes Zeplin redundant in a lot of ways, we found it useful to separate the “in progress” and “handover” environments. Designs that were ready to develop were “committed” to Zeplin.

Stage 5: Retros

No process is ever perfect. Retros have outsized importance when introducing operational changes. Before implementation, we used retros to help persuade reluctant PMs that the process was malleable and adaptable. In the retros themselves, people were encouraged to share their views without blame, and the whole team accepted responsibility for the problem. We made some major tweaks to the process at first, focusing on making estimation more accurate, introducing flexibility into the delivery, and improving communication by adding lots of new sync meetings.

THREE BIG TAKEAWAYS

Squads need more than one designer, or they need to pool talent

It’s impossible to carry out a full design cycle with one designer in a squad — turnaround times are two weeks at most. With all the hats that a product designer is supposed to wear (research, creative, wireframing, prototyping, usability testing, UI design & asset production, QA), something is going to get missed out.

The design process needs to be visible

Predictability must be established in a design process, even if you don’t dogmatically follow one. It was difficult to demonstrate the value of discovery and research tasks until they were recorded and budgeted for in our project management software.

Delivery needs direction

Features, when broken down into agile stories, tasks and sub-tasks, can result in a scattegun approach to the final experience. When we moved our design sprints outside of engineering sprints, feature deliveries became larger, more strategic, and more impactful. By delivering multiple improvements at once we quadrupled conversion in the sign up experience.

Credit goes to Alex Horstmann, a master in organisational change and digital transformation — for protecting, nurturing and encouraging us. And especially Kieron-Scott Woodhouse, whose confidence, communication skills and experience got us through many difficult conversations. He’s a Jira-whisperer, able to bend this unloved software to his will. He showed me that it’s possible to use Jira for good, whilst protecting creativity and thorough design problem solving.

I’m Andy Birchwood, An experienced freelance product designer who specialises in UI, design systems and operations.