Designing in sprint
Just over a year ago, we began designing in sprints and we fully believe it’s making us a high performing and effective design team.
For those who don’t know, a sprint is a pre-determined amount of time (normally 2 weeks) where the team commit to getting a list of tasks completed. Sprints, along with working in an agile way will be familiar with most tech agencies, yet it’s relatively new to bring into design and other areas of an agency.
White October has been an agile agency for 7 years, however design always needed a separate model and different requirements. This didn’t sit well with our processes or culture as an agency, we’re working hard to align ourselves with the developers in house to ensure we’re working as a team — and designing in sprint on the same tasks together is beneficial for company, client and team alike.
Why do we do it?
As a project team we work closely with our product owner to prioritise stories and tasks from the backlog, giving us a manageable sprint with achievable goals. It makes little sense to spend time upfront designing for features that may never leave the backlog.
Over time, the course of the project changes. Working in this way means our focus is always closely aligned with the team figuring out how to approach the next challenge, sketching out solutions and building an interface that provides a good user-experience through a component based approach.
Not working like this, puts us at high risk of neglecting user needs, wasting client and company resources and limiting the level of collaboration within sprint which has proven to deliver great products.
How do we get a coherent design?
Creating independent components across multiple sprints requires a good foundation, a reliable system, and maintenance. These three cornerstones are explained below.
Foundation
The preparation stage of our projects is called a ‘Runway’. The Runway determines the minimum amount of design and ux we need to do to start the sprint. This differs per project.
The Runway can include: competitor analysis, building personas, reviewing brand guidelines, starting a moodboard, creating a sitemap, designing style tiles and sketching basic (grey box) wireframes. This stage of the project is a bit of a creative supercharge, allowing us time to ask the client questions, understand the content and form a look and feel for the product.
System
Once we’ve got all our Runway assets, we work closely with project managers and developers to refine the sprint. Sprint refinement includes identifying key templates and components, estimating time against each item. This goes into JIRA and is pulled into sprints. Designers, as with developers, flag if there is a user need or if it makes business sense for an item in JIRA to be prioritised. Once the sprint has started, designers can jump in and work just ahead enough of the developers for them to follow up, keeping the work streams closely aligned, often a face-to-face chat and a quick sketch is enough. We continually work on the user flow and components through sketching, creative suite and code, using scrums, slack, JIRA and github to keep in the loop and sign off work.
Maintenance
Designing in sprint is fast, often changes direction and sometimes goes wrong. It’s both hard work and liberating deciding the level of fidelity each component needs. Keeping a backlog of design tasks in JIRA allows us to track what’s coming in, and add ux improvements, testing when required.
Along with fresh eyes, designing in sprint helps the team to step back, see the project plan and highlight areas in need of attention. Without them, the design could easily become disjointed, flabby and the user-experience non-existent.
Designing in sprints is challenging
Why is it so challenging? Designers at White October tend to work on multiple projects at the same time. Sprints can run in parallel, project requirements vary and change and the level of design fidelity fluctuates.
Each project brings new teams together with new processes to learn. At White October we’ve learnt to see this as a benefit to the project, each person carrying over successes and suggesting new approaches from previous projects to help answer important questions such as ‘Do I design a sprint ahead of developers?’ ‘How much design is enough?’ ‘Will we ever get to the ‘nice-to-haves?’
Luckily for us, the good outweighs the bad. At White October we are enjoying working closely as a team, making decisions together, iterating designs and leaning on everyone’s skills. The result is a stronger design focus with the user at the centre.
