Show, Don't Just Tell

When designing software, what can we learn about user interface requirements? When using Scrum, what can product owners, and development teams, learn from users? Some organizations still rely on asking people what changes they'd like to see in their software or service. Does asking really work?

It's not what people say, it’s what they do

Gerry McGovern writes in It's not what people say, it's what they do that The worst way to design a website is to get five smart people in a room drinking lattes and posting post-it notes. […] The next worst way is to get 10 customers in a room drinking lattes and giving their opinions on the new design. That model is really, truly broken.

People Cannot Tell You What They Want

UXMyths posted Myth #21: People Can Tell You What They Want. So, if it is a myth, and people cannot tell you what they want, why do we keep asking them?

Don't do what customers say they want, understand their problems and solve them.
- Per Haug Kogstad, Tandberg (now Cisco) founder

From reading Malcolm Gladwell's Blink, I can remember the failed experiments:

• The Iyengar/Fisman study revealed that what the speed-daters say they want and what they were actually attracted to in the moment didn't match when compared.
• The New Coke is one of the most famous research failures. Despite thousands of sip tests and countless efforts to fine-tune the taste based on the customer feedback, the New Coke was a huge disaster. "Gladwell contends that what people say they like in these tests may not reflect what they will actually buy to sit at home and drink over a week or so." See the full story on Wikipedia.

  (Image from Wikipedia)

• The now acclaimed Aeron office chair received very low ratings in early tests. Despite the ratings, the company decided to go on with manufacturing. The rest is history: Aeron became one of the most iconic and best selling chairs in the history of office furniture. And the irony: once the chair became famous, people started rating it much favorably.

  (Image from Wikipedia)

Lean Startups

Present an idea, and ask about their pain point? Ask if they would pay X for this product? This is what some teams say they do when they try to "validate" their startup idea.

The problem here is that asking people is not a good approach. They'll say one thing, and do another. It's not that they're lying. It's just that humans are not good at speculating on future use of a product or system. Their answers are neither right nor wrong, they're just unreliable.

people don't know what they want until you show it to them.
- Steve Jobs, Apple co-founder

Scrum and Product Owners

What can product owners and development teams gain from this insight? What happens during Sprint reviews?

During sprint reviews, it is good that teams show what they've built, and have the product owner use it. That way, it's not just what the product owner says, it's more about what s/he does with it. Better yet, the product owner should find ways to get the product to actual users and see if they actually use it (e.g. download it, or click through it).

Show, Don't Just Tell

People don't know what they want until they see and use it. If you're designing a new system for people to use, have more than one design running, and have people use it. Don't ask them which one they like. Have them use both, and see what they do with it. If they keep using one version over the other, then you have a winner. (web usage analytics? A/B testing anyone?)

If you really really really have to ask, make sure you know what you're asking, and know how to interpret the results.

Early UI, Early Feedback, Better Results

A few months back, I was reviewing some internal apps we had in our organization, and this thing we humbly call the "library app" got my attention. We have a lot of books (physical copies) lying around, and we encourage everyone in the organization to read and apply/share what they've read. So far, it seems to be working.

A group of young developers was learning Grails, and they built this "library app". I wanted to learn too, so I pushed myself to do something that ran on Google's App Engine, and I ended up learning more.

UI and User Experience

I started looking at the current user interface of the one built using Grails. Here's what I saw — a login page.

After logging in, I get the following.

Thanks to PJ for the screenshots.

I asked myself, "What would a typical user do if s/he was greeted with this landing page?" My first response was, I wouldn't even think of clicking any of the two icons. And here's what I saw after clicking on the "Book Listing" icon/link.

There was nothing there that "entices" me to explore and look at the available titles. So, I set out to create a landing page that would make we want to look at what's available.

Early Feedback

Here's what I came up with (largely inspired by iBooks and other similar apps).

libraryapp.onb-demo.appspot.com

I didn't build the code behind it (at least, not yet). I just started with some static HTML, deployed it to the cloud, and asked some colleagues to try it out. I was pleasantly surprised with their reaction. They asked if the app was a modified version of the one built using Grails. They also asked if I got help from our creatives team, and if it was written using Grails. Anyway, the early UI allowed me to get early feedback. And letting the landing page be seen without the need to login also helped (I guess everyone is too lazy busy to login).

Learning users’ unarticulated needs through a process of keen observation and interpretation often leads to breakthrough designs.

http://en.wikipedia.org/wiki/Empathic_design

So, I proceeded to turn the static HTML into something more dynamic. I started populating the database with book titles. Then, it occurred to me that I was spending so much time entering the titles, authors, publishers, etc. Even though we have about 50+ titles, it was taking too much time. So, I asked around how the current version was being maintained. I was surprised that they did it pretty much the same way I did (adding titles one by one, and typing everything in while looking at the physical copy). I started thinking of improving this. (Seems like an unarticulated need here)

I saw myself Googling the book's title every time I needed to enter its details. Light bulb moment! Why don't I enhance the entry form and allow the user to Google it up, and populate the entry form?

After some rough JavaScript, here's what I ended up with.

I added a "Search" button that would do the search (using Google Books API). The results are shown, and a button is added to use the book information to populate the form.

After I added this, I was able to add titles in no time! This would not have been possible for a user to articulate or express as a requirement. How would they know that APIs exist to help with finding book information? It's critical to observe and experience what the user goes through when using your app to achieve their goals and/or perform their tasks.

I'm no design guru. This simple enhancement is far from a breakthrough. I hardly observed our office admin team use the existing library app. But I'm glad I had this experience, and I hope sharing it here would help others. I indeed learned more than just building apps!

Future Enhancements

As you can see from the screenshot, I have not implemented the borrowing part of the app (yet). But I'm thinking of ways to add a "comments" section to allow users to post their comments about the book. I'm hoping that these comments shall further "entice" others to grab a copy, read, apply, and share.