These days I spend my time fulfilling my role as Head of Interaction Design within DWP Digital. Specifically making sure things are joined up and consistent across services.

There’s a lot going on*.

The approach to consistency

We follow an agile method of working. By that I’m describing the real agile, the being agile *not* doing agile.

If you follow government design, you’ll know that we work through stages. These are discovery, alpha, private and public beta and live. They are stages through a services life-cycle.

The theory is;

• discovery – finding user needs (heavy amount of user research)
• alpha – as many approaches to fulfil the user needs (heavy amount of user research and prototyping)
• private beta – focused approach which meets user needs (invited user groups and a heavy amount of user research)
• public beta – the approach and researching hypotheses (heavy amount of user research)
• live – the approach and researching very precise hypotheses

This higher level approach is tried and tested. It works.

Yet, I find the more granular areas are where it becomes unstuck. This is mainly down to process and team set-up.

The Nitty Gritty

A multi-disciplinary team is just that. Your team must have the correct complement of professions to achieve its goal. Each role should know their responsibilities. Each role in the team needs to have empathy for the other roles. If your team hasn’t had a session on describing the work they do to each other then take this advice, do it as soon as you can.

Why?

Because a good iterative approach is a team sport.

Imagine empathy being the oil that helps everything run smoothly. It causes relationships between the team to be like smooth gear changes in a car or the way a pianist moves their fingers across keys.

Working in sprints

We work in two-week sprints. Having done this for a lot of years it is a natural amount of time.

The best way to break a two-week sprint down is to use a process wheel. This will get you going and then everything else becomes natural.

You can mark out your ‘wheel’ with the 10 days you have available (two weeks minus weekends). Include the following (in no order);

• sprint planning
• backlog planning (and scoring if its development work)
• design
• creating a prototype
• organising user research (this can increase depending on the type/place/audience for research)
• research days
• analysis
• playback
• iterating
• development

Work with your product owner to prioritise what goes into a sprint. This means you can create your prototype and do your user research. Then run your analysis, play the information back and keep iterating.

During this, the other members of the team may be doing other tasks. These could be stakeholder management, future planning or development.

The design team should be pulling information from all corners of the team. Discussing things with developers, business analysts, data analysts and more.

Design and research must be communicated to the product owner. Help them understand where the design is meeting user needs. Communicate where it isn’t and any hypotheses which have arisen from findings.

Documentation

At the end of every sprint, the team should document their work. Everyone has been in the position of trying to remember why something was done a certain way 6 months ago.

If a new piece of design is created and becomes a pattern, this should be shared. This could become part of your organisation’s design system.

Good product development

If you follow the advice above, if you use a process wheel, your service team will start working in a more joined up way.

All parts of the team will be working in parallel. Hitting sprint goals and delivering over and over again.

Download the Product Development Wheel.

*Hat tip to Anna *Rzepczynski who originally showed me the wheel as part of the “UR Wheel”.