When designing a site, app or digital product, all of the elements on screen need to work together. They need to sing together, harmonise with one another and form something greater than their constituent parts in order for the a user to start and finish their task.
Agile as a methodology tends to focus so quickly on the details of a product that it's hard to get a sense of the bigger picture.
I'm a big fan of agile, don't get me wrong. We use it extensively at Clearleft - or at the very least some blends and flavours of it - and for the most part it works. The practice and habit of daily stand ups, playbacks and backlogs, breaking down epics and designing around user stories... they're all integral to the user-centred design (and production) process that we adhere to. But the process arguably falls short during the start of any project where, as the 'visual' designer, it's your job to conceptualise and articulate the overall design style and visual language for the entire product... before you've had a chance to even start the work.
Working on a current project has seen us adopt agile as the method in which the project will be run. Following a successful 2-week discovery sprint, we've started tackling the prioritised backlog with aplomb. So far so good.
...but there's one major issue, at least from my standpoint as the designer on the project. Through the discovery phase I explored some elements (by way of an element collage) in order to get consensus that we were headed in the right direction. But, as with any initial exploration in a 2-week window, not all the elements - we're talking lock-ups, layouts, typographic scales, grids, iconographic style, patterns and everything else that gives a product its visual style - were locked down. Knowing the width and breadth of what's needed in the project and going ahead and starting to design those things? Surely that would negate the need for discovery in the first place (and it would also mean you had a crystal ball. Go play the lottery!)
So, following a successful exploratory and discovery sprint, the second sprint (and the first of production) starts. And lo and behold gaps emerge in the design process. Diving deep and straight into the details of the user stories, acceptance criteria and the almighty backlog, the bigger picture of exactly how the design system works starts to fall by the wayside. Caught up in the minutiae of the small interactions, the flows, the viewport sizes and responsive behaviours means its difficult to see how the next user story, the one after that and the 30 after that will all come together to form that all-singing, all-dancing and fully-cohesive product UI. How can you when there's no time to take a step back and see what's needed?
I'm not suggesting I have a solution to this gripe. It's just that - a gripe. But if I had to offer a piece of advice, it would be to make sure that all sprints - from the first to the last in your design process - accommodate at least a day's worth of 'design retrofit', followed by the same for front-end development (if applicable, of course).
By leaving at least a day available in a 2-week sprint, you can maintain your velocity and keep your client's best interests at heart. Who wouldn't want to know that the designer on their project wants to make sure that the thing they're designing for you is the best it can be?
By retaining that day's 'designer grace', you're ensuring that the separate, sometimes ad hoc flows and design comps you're creating actually work together in the wide angle lens of the design system.
To put it another way, imagine the worst-case scenario: you to get to the end of your project and realise that that screen you designed at the start of the project looks nothing like the screens you just finished in the final sprint.. yet it's already gone into development. If you have the ability to go back and retrofit, iterate and rationlise your previous designs (and persuade your developers to do the same) it means you'll be delivering the best, most consistent design system you can, throughout the duration of the project... even if it is Agile.
This article was originally posted on my own site.