Case study


Fixing design in squads

A dream of agile

I’ve worked in several waterfall projects in big corporations. Development and deployment happens at a glacial pace. I found myself lusting after jobs embedded in product teams in squad based companies. I dreamed of a promised land full of continuous shipping, feedback and improvement.

But at Spotahome, I experienced the inverse: The squad based model was causing people to pedal fast without having much impact. A string of underperforming features and initiatives weren't leading to the growth expected by investors.

A design project was cancelled after 6 weeks of work, yet the design team were seen as a "bottleneck". The company evidently had some design strategy challenges. With design director Alex Horstmann, and fellow lead designer Kieron-Scott Woodhouse, we helped the design practice to mature, and made sure we were getting the most out of design team.

7 symptoms of squaditis

Designers hurrying with no time to think or plan

Designers visualised ideas in one or two day turnarounds, whilst developers twiddled thumbs. 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 an established belief that it would be quicker to design more quickly in high fidelity. Without evidence to support design decisions, the designer role was frequently reduced to graphics package operator.

Little shared expertise or peer reviews

Designers felt isolated in squads. There was little time to organise guilds, share knowledge and support. They weren't peer reviewing for consistency and standards.

Little coordination across squads

In the absence of design velocity, design time was being allocated day-to-day. Designers didn’t feel able to say no to product managers. The quality of designs suffered. Squads were operating in competition with each other, and PMs ringfenced their designer.

Low quality delivery

There was no planned time for designers to review code. The scope for features could be changed without the consultation and broken up into iterations which never came. Deployments rarely bore much resemblance to the original design. The product was essentially untestable against design intent.

Poor communication

The classic designer problem - no seat at the table. Designers were excluded from product discussions. Briefs were vaguely defined. As designers battled for sign-off, they iterated high fidelity artwork as the full brief was fleshed out en route.

Limited outcomes

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 chunks to small to make an impact. The obsession with experimentation obscured fundamental usability problems.

What I did

  • Design strategy
  • UI team leadership


Unveil the design process

Increase visibility

The urgent 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. Here's the thing: Designers might claim to be skilled in research, strategy, copywriting, prototyping and UI production, but this is rarely true. With a single designer embedded in each team, it would usually mean some tasks would be rushed or skipped entirely.

We tagged our backlog as research, discovery, flow analysis, wireframing and UI. We estimated on each design step rather than the whole task. Stakeholders and PMs had much better visibility of the end to end design process and budget.

The key to getting buy-in from PMs was to assure them that projects wouldn't need to go through every step in the process. We made it clear that we wouldn’t be following a design process dogmatically, and only including necessary steps. We explained that the better a design task was defined, the less time we would spend on initial research (discovery). This helped motivate them to better communicate project aims.


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. Developers didn't miss design conversations cluttering the technical channels.


Design sprints, one sprint ahead

Mindset change

We asked the PMs for fully researched, prioritised and briefed work to complete two weeks ahead of the development sprint. Briefs took the form of user stories, goals and hypotheses and supporting data. If a brief wasn’t fully formed, we could turn it into a discovery task to fill in the detail and test assumptions.

Some PMs were unaccustomed to communicating this level of detail to designers. Being thorough with our briefs and discovery phases benefitted the whole team. Everybody began to focus on the problem rather than the solution.

On more than one occasion, simple research tasks in discovery helped us find evidence that our customers didn’t want the feature. Knowledgeably deciding not to do something has a double impact on resourcing. Not only are you not wasting time building an unsuccessful feature (and removing it later), you're freeing up time to work on things that have value to customers.


Some engineers were worried that they wouldn't be able to maintain the velocity and impact. They attempted to shortcut the process by starting dev early or by bypassing discovery altogether. Both attempts were unsuccessful due to unclear goals and outcomes. We were later able to highlight the problems and reasssert the design process 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. Engineers agreed to wait until work was handed over before grooming solutions. In the end, the new rhythm became clearer. The engineering squads began to prefer more predictable design deliverables.


A seat at the table

Bring the table to us

Designers weren't getting a seat at the table in product planning discussions. To resolve this, we brought the table to us.

We began to run design 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 by the design team if they were absent.

I had initially imagined these sessions might be confrontational. But I realised we were simply there as facilitators of the discussion. The product manager peer group was engaged 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 a discovery phase. PMs were compelled to properly frame problems and project outcomes.

The design board in Jira showed a much clearer, tribe-wide feature roadmap than the engineering boards. it was much easier for the product director to keep a overview on outcomes. He became a predictable and less reactive arbiter in strategic discussions.

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. With the budget clear to everyone, sprint planning ceremonies began to go very smoothly indeed — we’d often finish well before the 1hr time limit.


Some PMs felt that detaching the design process from the engineering process would result in a loss of control over the programme of work. 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 deploying resources more proactively.


Opening communication

Remote teamwork

When the company was smaller engineers were co-located with designers. Technical feedback was informal and unrecorded. But some of the changes were suspect—for the sake of convenience and speed of development. Decision making was opaque and undocumented. 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.

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.

Weekly show & tell sessions

To show work in progress, review work against goals, and accommodate feedback early on.

Ad hoc technical reviews

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.

UI handover

We worked on hi fidelity UI specifications, ending with a UI handover to the FE team. Discussions at this point were centred around usability, content, style and branding. To facilitate the communication of designs, we used a combination of Jira, Figma and Zeplin. For animated interactions, we used Flinto or After Effects and shared the movies in Jira.

UI QA review

before deployment. The outputs are screenshots of the release candidate, a list of small snags in the UI. These were prioritised and remedied before release.


The key to introducing any new process is to learn from mistakes and iterate quickly. It also allowed us to let other people make mistakes, with the confidence that we could rectify it in future.

Get in touch

Want to work with me to create amazing products? Drop me a line

More case studies

Airline app

Product design・How I set a new course for the design of a companion app for an airline.

Read the case study

Throwing out the kitchen sink

Design strategy・How I quadrupled email revenue for an airline with barebones email designs and a hacked A/B test.

Read the case study