During the second LDNIA#1 talk Collyn Ahart said that on some project they took an ‘Agile Planning’ approach. It was a short mention but some time later a fellow UXer was ranting about it:
“UX shouldn't use Agile. It's a tool created to ship software, not design” (not literal, I don't remember the exact words)The conversation moved on to excessive research (yeah that's right, excessive), but that phrase stuck in my head on my way home. I've been reading recently a bit about agile and development, and I find concepts like test-driven development, just-in-time design or the Kanban board really clever tools.
So, should designers use those developers’ tools?
Task-driven design
I've been thinking about how to incorporate test-driven development into my design process. The only way I can create a test that fails before I mockup a concept is to use an empty canvas, and that's not very helpful is it? But I can write all the cases I need to cover before I start sketching a page, and treat them as my tests. Having that list in front of me whilst I visualise the concepts helps me stay focussed on the task and, once I've finish, I can go through the test list to make sure nothing is missing.
This can’t probably be called test-driven design, maybe task-driven design. And it may be that every designer except me is doing this, but I’ve taken this approach recently and it helps. I’m more organised, I work faster and it’s much easier for the client and their tech team to validate my work.
Just-in-time design
A lot has been written about just-in-time design lately, as the Lean UX concept has been buzzing the internets. It all started as a way to reduce waste inspired by the lean manufacturing process created by Toyota years ago, and again I think it just makes a lot of sense.The User Centric Design process is quite often long and expensive, so I’m not surprised that many firms just skip the whole UX part and jump directly to graphic design and build. They probably see the benefits of UX Design but find it excessive. A nimble, just-in-time thinking would suit those firms and dramatically improve their products.
Same with Kanban, last year Caplin showed us how they embraced Agile and it was really inspiring. I wonder why we don’t take a similar approach on projects that require design and build.
It just works
Are these tools damaging my ability to solve design problems? Are they specific to the development world, or could they be applied to any other creative process?If a tool works we should add it to our toolbox, regardless its origin. I don’t care if it’s a developers’ tool, what I need is to have the best tools in my pocket as no two projects are the same. I’ll decide then what to use, and that may be something inspired by the software development industry.