Presenting Design Work by Donna Spencer captures everything I’ve learned about that harrowing process of presenting a web design for review and turned it into a six chapter book you can read over two lunch hours.
I am thrilled that this book emphasizes rigor in the craft of creating and presenting designs.
So many times I’ve sat through reviews where the designer couldn’t tell me what the business problem was, why the user needed the changes, how the user would get from place to place, or what the unhappy paths looked like. They failed to take notes (sometimes showing up without even a note-taking device, like, say, a pencil or a laptop), gave me a tour of our components on the page instead of telling me how someone would use it, and thanked everyone when done — but never followed up to let us know what they’d decided. Then, later, they complained that the product manager steamrolled their input on designs or ignored their feedback.
This book demands a lot of the person who wants to be successful. You have to think about your audience, practice presenting, take notes (or find someone who will), understand the problem you’re building against, understand the feedback you’re given, and be rigorous in your feedback decision-making process.
It also works. It works so very well. And it garners trust between us and our business and engineering peers way better than any less-rigorous process is capable of doing.
As soon as I started reading it, I started messaging people I know mentoring designers and said “yeah this book? this is the one you want.”
Look, I’m just going to point you over to the review I wrote on The Interconnected, because I loved the book and I think you should read it… but I don’t feel like cross-posting it at 3am.
I’m doing a lot of writing design guidelines at work right now — essentially codifying in words the things we’re already doing. Paving the cowpaths if you will.
My June 28 post on The Interconnected is about where to put design guidelines when you write them, what application to write them in, what to put in them, and why nobody’s going to read them but you.
Read Back to Basics: Writing Design Guidelines on The Interconnected
Alex Duloz, who was one of the brains behind The Pastry Box, asked me to participate in his 2017 project The Human In The Machine. He’s doing a look at productivity and how we handle it, with a post every day about productivity from a different author.
For my post, Preconditions, I thought about my daily routine and what things I do to set myself up for a productive day. Some of them are physical and environmental, like the way my desk is set up or how warmly-dressed I am. Others are about the work itself: is it ready to be worked? How do I know? The list goes on from there.
I don’t have any expectation that anyone else will use my process. More, it was nice to quantify the process I’m using and see it out on paper (well, electrons) so I could confirm it. And a little bit, writing it down helped me look at it and decide whether everything really was of value.
The last of my three rants about Big Up-Front Design discusses the conditions in which big up-front design is a really good idea.
It’s not always be a good idea to do big up-front design. Conversely, it’s not always a good idea to skip it. Th trick with this technique as with all techniques is to know when to use it and when not to.