Fixing design in squads
By: Andy Birchwood
Tags: Agile Design, Design, Design Operations, Design Process

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.

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.

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.

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.

. 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.