Ask me Anything

In November of 2013, I did an Ask Me Anything (AMA) exercise with a fellow designer, to help get a new development group on board with the core concepts we were planning to use going forward. Here are some of the questions and answers.

When prototyping do you like High-fidelity or low-fidelity?
Prototyping is extremely iterative, I favor low-fidelity up to the very end. Lo-fi lets you quickly incorporate any and all changes into the prototype so you can get to the root of exploring how the new idea or approach actually addresses the underlying problem. It’s all about tweaking if you’re iterating changes into a high-fidelity prototype you are wasting valuable time pushing pixels instead of addressing the problem. Also, I find walking someone through a lo-fi prototype helps them visualize and understand the problems we are trying to address because they inherently see it’s not a final solution – kind of like how ‘Lorem ipsum’ in a layout helps keep focus on the design and not the content.
Be forewarned, there is a small risk of your lo-fi design being implemented! In 2000, while at Outpost.com (now Frys.com) I reworked the logic and layout of the shopping cart and checkout, using Powerpoint to create my prototypes. In my designs, I sandwiched the top and bottoms of my prototype pages with yellow horizontal rectangles (easy to make in powerpoint), and tested them as color printouts –  the results from testing were so positive that we rushed them to development knowing that we’d “pretty them up” when we had the time. It’s now 15 years later and the yellow rectangles are still there, unchanged from the lo-fi prototype I created and tested. (Checked 10/20/2015)

What about documentation, how detailed do you like your standards and Ux docs?
In the past, I spent a lot of time writing pristine apple-esque standards docs that – I’m reasonably sure – no one but myself actually read. The outcome worked though, because writing that level of documentation was like writing crib notes for a test, it helped me commit everything to memory and then be able to walk anyone through what was needed and why. The agile process has helped me refine my documentation approach, now it’s all about the conversations and mutual discovery. I still need to explore every option and document all changes, and there are much faster ways to record that info, and maybe even have the developers read it!

Shut up! Developers don’t read anything, please explain.
It’s true – I swear! I recently implemented a WIKI* (including full search capabilities) to document two vital areas, UI Standards Docs, and a database for acronym and abbreviations. It was a lot of work getting all that info into the database, but every time someone asked me for some piece of information I’d answer the question and include a link to the web page where the info was stored. People’s questions shifted from questions like “What’s the standard and layout for date of birth” to “Hey can you send me the link to that WIKI you made I need to remember how date is formatted” I also found a WIKI was perfect tool to track all the decisions made in sprint instead of trying to rely on our memories or decipher TFS notes.
(*MediaWIKI server – Local install package from Bitnami)

You’ve been spouting off on this whole BYOB thing a lot lately, I think I get it for the big guys but why should a small company bother?
BYOB is the way to go. I see  two paths:

  1. Take an existing bootstrap, and make it your own (a great way to learn)
  2. Start from the ground up.

Each approach has its pros and cons:
The biggest argument against taking a cut off an existing bootstrap is that once you take a cut and customize it – it’s likely you’ll no longer be able to benefit from the updates made to the parent. And the biggest argument against “from the ground up” – is that it’s time-consuming, and no one wants to wait for that. BYOB will pay off In the end – taking the hit to getting everything you do under one set of common controls, is going to drastically reduce everything; time to market, bug fixes, development effort, and QA effort. (BYOB = Build Your Own Bootstrap)

The below were not included in the AMA, but I have not found a better place for them.

Learned highlights:

  • Get over it (and yourself): Failure is integral to the process, understand what worked and what didn’t, learn why, and try again
  • Users can’t tell you what they need – but if you watch them they’ll show you
  • Focus Groups just still don’t work
  • Data you retrieve from a usability study rarely lies, however, clients seldom trust that data even though they know it’s true (and they have paid you to collect it!)
  • Ux and Brand are one and the same
  • Ask questions, never assume, but ask questions that facilitate answers you can use 
    • Example: “Do I look fat in these jeans?” prolly not a great question
  • When interviewing, always ask a user how they do their job when the power goes out, you will see their process in its purest form
  • Working with a group of users and gathering pain-points? Try using Tee-Shirt sizing and a story-pointing poker approach to get them to talk further – the conversations you hear when they disagree can take your understanding of their pain and process to the next level
Advertisements