Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
Cennydd enumerates what design sprints are good for:
And also what they’re not so good for:
If you’re intrigued by the kind of design sprints I wrote about recently, here’s a handy collection of resources to get you going.
- Pre-sprint
- Understand: Gather existing knowledge, expose assumptions and unknowns
- Diverge: Illuminating all possible paths
- Converge: Choose the right path
- Prototype: Quickly build the right path
- Test & Learn: Test the right path
Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.
There’s a really good point in here about starting with small-screen sketching:
For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.
If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.
If you nail the small screen design, the larger sizes will be easy by comparison.
Jon writes about the difficulty of maintaining an overall design vision when you’re working to an agile methodology, slicing up work into sprints.
This pairs nicely with Mark’s recent podcast episode: On Agile.