I had to buy a new action book (love these). Simultaneously, I am re-reading a book by Bill Buxton about sketching as a holistic approach to good design and product management.
(Feature photo credit: Sarah Forbes)
I’m perusing Sketching User Experiences again. I strongly recommend it. It’s a great read – but don’t get it on kindle; it contains too many photographs, diagrams and illustrations. Plus, it’s got some great reference material. I’m constantly quoting it to the team, especially to developers needing reasons to use pen and paper.
(Sketching User Experiences by Bill Buxton)
As a product manager, you learn right away that sketching things is a time-saver. Not only does it help you conceptualize the problem, the product, or the experience; it is the fastest form of iteration. Every sketch you chuck in the waste basket is valuabletime saved – what if you had built that?
When I’m developing,I am tempted to think the computer is my only tool. Or rather, it’s my hammer, and every tasklooks like a nail. Wethat it’s the designer’s job to sketchout the user experience flow, and our job to translate it into code. Wrong. An effective team is constantly in conversation – agile and SCRUM are supposed to drive that conversation – and illustration is the universal language. That’s clearly one reason why post-its on a whiteboard areastaple of agile development.
Here is evidence why diagrams and drawings are still a necessary tool to software developers. I’ve recently been tinkering with Reactive programming on Egghead.io. Reactive is a programming paradigm oriented around data flows, and diagramming those flows is essential. Here is an example:
Diagramming the flow of “streams” is so important that creating them in ASCII has become conventional:
(code credit: @staltz on github)
So I’m constantly reminding myself to draw first, code later. You should too.