Since I joined The Lab nearly two years ago, I have been keen to try out and experiment with iterative learning processes such as Lean UX and Design Thinking.
One of these processes is called a Design Sprint, originally used at Google Ventures. The Design Sprint process follows a collaborative 5 day sprint with a co-located team.
For the Design Sprint which I ran in The Lab, I generated the Design Sprint Plan pictured below. The aim was to help the people on the sprint and in the workshops understand what will be happening on each day through out the week, and it worked.
On the plan there are big arrows which hold the post-it note tasks for each day. The circles at the base are for the people who are on the sprint each day and the two half circles off to the right, are for the outcomes of the sprint, primary and secondary.
I posted this photo up on my @jezsherwin twitter account and it is now in O’Reilly’s new Design Sprint book, which is a great book and a must have if your thinking of running a Design Sprint.
5 Day Design Sprint
Last year I was walking through a book shop and this book jumped out at me, maybe it was the title ‘Clicking’ or the impact of the bold graphic cover, whatever it was I ended up getting it.
The book Clicking was about how and why some people click. The book talked through different scenarios, such as hostage situations, sharing interests and even sharing DNA patterns such as thumb prints, all very interesting.
After reading this book one thing really stuck in my mind, a story about computer user testing, it went something like this…
Tests were done with two sets of people group A and group B
Group A where asked to use a computer that was running slow and struggling with an standard user error messaging, then the users were asked “how does this computer make you feel?”, key emotions such as frustrated, annoyed and even angry.
Group B were given the same struggling computer, but this time the computer communicated to the user how it feeling, it said something along the lines of “I know you want me to run faster, but I am really struggling at the moment, I’m so sorry if I could go faster I would etc.”.
This time, the results were totally different, the computer had created empathy, this empathy left the users feeling calmer and some even felt sorry for the computer.
So this left me thinking, as UX designers are we really clicking with these powerful human traits?
Encouraged by her sister, my wife ordered the weekly shop online for the first time last week. She seemed to get frustrate at certain points asking for help, but in the end she completed the order and set the delivery for Thursday.
Job done, now all she had to do is to sit back and wait for the nock on the door.
When the order arrived, she was quiet shocked to see the size and quantity of some items she had ordered:
- 3 large broccoli trees enough to do a Sunday roast for the hole extended family
- 2 big boxes of size 4 nappies, only hope my son doesn’t grow over the next 2 months
- 3 big pieces of ginger which should last us till Christmas as my wife doesn’t really like ginger
- 2 packets of grapes, this was a results as the kids love grapes
- 2 packets of large apples when normally we would get the small ones for the kids
- A great big bag of basmati rice
- Well you get the picture…
Over ordering on your first shop seems to be pretty common practise with the people I have talked to. A chap at work ended up with two big carrier bags of aubergines. Even the delivery man said “you seem to like a lot of broccoli in your family? Don’t worry I made the same mistake on my first order”
So is this poor UX Design or master plan to make more sales?
Whichever it is, it is a learning curve, for the new weekly online shoppers.
Why Design For Feedback (DFF), why not design to finish, it needs to be finished sometime?
When I first arrived at my current employers, I found some digital designers would pick up a design project at the beginning of the sprint and demo it at the end of the sprint to the product owner. I remember seeing one piece of design work being finish and demoed three times in a row. This meant that three weeks later the designers and product owner were getting frustrated with the lack of progress.
Design for feedback was the key, using white board rapid sketching we created a visual conversation with the product owner. This allowed both the Agile team (Dev, Design, IA etc) and product owner (client) the opportunity to build up a conversation around the problems, the solutions were discussed and visualised through rapid sketching on the whiteboard.
Capturing the white board scamps, we then started creating low fi designs, with the aim of discussing the evolving designs every 2-3 hours.
Remembering that we were still designing for feedback we took out the unneeded complicated design elements and the Design For Feedback process evolved from low fi designs to polished ideas.
This constant Design For Feedback process kept evolving far after the site pages went into user testing and then live. Every day the pages were live they were giving valuable user insight back into the evolution of the living pages.
In a nutshell Design For Feedback added value by improving communications and speed, whilst reducing design waist.
Also see continues delivery