Rubber Duck [UX] Debugging
The basic premis is that you debug your code by explaining it to a rubber duck, line by line, and hopefully realise where the bug lies in the process.
If you’re going to be spending $75 per person on user testing, then you’ll want to make sure you’ve spotted as many “buggy” interactions as possible before anything gets built.
As this is intended to be a practical guide, I’ve created a fictional mobile app to use as an example (so just squint and pretend it’s your own app).
Step 1: Define your flows with User Stories
Be clear about what your app does. For my example app, I wrote:
{name of app} is a point of sale app for iPhone that enables waiters to take a drink and food order at the table and charge customers directly.
Then, you’ll need to have at least one user story like:
As a waiter, I want to take an order of 3 green teas, 1 water and 1 sandwich so that I can charge the customer.
These user stories define the flows through the app that we’re going to be testing. If you want more information on storytelling in design, check out Braden Kowitz’s post.
Step 2: Wireframe your flows
I’d normally start this process in Omnigraffle. Maybe you prefer pen and paper or some other app like Sketch. (If you use something else, leave a comment about it here).
Taking the order of 3 green teas, I work out all the pages I’ll need to complete the transaction. I also loosely work out how they will connect to each other i.e. what order the appear in (the flow).
This gives me a todo list of pages I need to create wireframes for.
You could (and probably should) use this fidelity of wireframe to start testing, but I’m going straight for the final, eye candy version with a “here’s one I made earlier” approach.
Step 3: Prepare your fake screens
So I know which screens I’ll need and I know what data goes on each screen. Next I’ll take those wireframes and start the glossy design with shape, contrast, spacing and type (far left) before moving on to applying brand and colour. I use Silkscreen for previewing on devices as I go. Final design:
For each page, I’ll use Photoshop Layer Comps to show variations e.g. a receipt page and the same page with a “paying” popup over the top.
Step 4: Fake it ‘til you make it
Next up you’ll need Keynote and Liveview (for mac and ios).
This is the Rubber Duck Debugging part. It’s important to note that it’s not the final output that’s important here, it’s the building of fake app that will highlight interaction bugs as you go.
So let’s build that fake green tea order:
- In Keynote, create a new presentation.
- Open the Inspector.
- Resize your presentation to match your phone. 640x1136 for iPhone 5 for example.
Now you’re ready to cut/paste from Photoshop to Keynote. Switching through your Layer Comps, follow the user stories and flow you defined earlier to get a list of sequential slides in your presentation.
You’ll end up with something like this. To test my “3 green teas” order, I ended up with about 15 slides. Some were almost identical with just a different total price showing so it’s not as much work as you think.
Most of the time your fake app will be linear flow. If you want to double-back through the app (re-visiting the start page for example) you can do this by using a transparent shape enabled as a hyperlink to another slide:
At this point, if you play the slideshow, you should be able to click through the app and fake taking a real order.
Congratulations! You just rubber duck debugged your flow.Hopefully by forcing yourself to mimic a real flow, you will have spotted some early UX problems. The kind of stuff you want to find before a developer spends a week putting a basic feature together.
Step 5: Take the red pill (optional)
As nice as it is to have a flow running on your screen, wouldn’t it be even nicer to actually test it on a device? As I work remotely I also film using the app to share with stakeholders so that they can view the functionality first hand.
You’ll need to modify Keynote preferences and “Allow Exposé, Dashboard and others to use screen”. This will enable you to move the LiveView capture area.
Launch LiveView both on your mac and your iPhone, set it to “High Quality” and Interactive:
Your Keynote should now be being broadcast live to your phone and it should feel as though you’re actually using the app (bonus points if you used Keynote animations to make it more iPhone-y).
As I mentioned, I also film using the app to send to my team so they can comment on functionality. My setup looks something like this:
Unfortunately, I don’t seem to be able to embed video, but you can visit this Vimeo page to see the kind of results you should expect.
To give you an idea of the kinds of bugs you might find using this method, here’s what I found when making the above point of sale app. I noticed a problem where every time I selected an item, say a tea, a coffee or sandwich I aways went back to the top level menu (rather than staying on the drinks menu for example). This is logical because you can’t infur what the next item would be.
However, this gets annoying if you want to select 3 coffees. I only noticed this when I went to add 3 green teas in a row. Once I found this UX bug, it was easy to fix, but I wouldn’t have thought this problem until much later on in the dev cycle, rather than at this early design stage.