Matching the UI to the User

I recently found an article called "Why I love ugly, messy interfaces - and you probably do too" by Jonas Downey, a designer at BaseCamp. I opened this up because I vehemently disagree. All user interfaces should be as beautiful as possible. In today's age, it's unacceptable to punt those P3 "fit and finish" bugs and ship something that looks ugly. It takes an extra week to delight your users? Do it!

At least that's what I had the mindset of going into this article. What I actually got out of it was exactly in line with my point of thinking, aside from loving ugly messy interfaces.

Matching the UI to the User ...

Old school usability study, behind the one-way mirror

Matching the UI to the user has never been more important. Recently, I was the product manager working on Notarize.com, a new product to enable American's to get documents Notarized in a digital fashion, without the beige carpeted walls of an antique Notary office (at least that's how the one looked like that I went to when I was desperate one day!).

Designing the interface involved designing for an end iPhone user who would likely use this app one or two times in their life, then designing a web interface for the Notary to use, who would likely notarize a document every 3-5 minutes in any given shift, and lastly, for the Administrator to manage notary's and review certain analytics.

On the iPhone, it was super critical to get trust, and friendliness across. This lead to working with the design team to create the simplest UI possible. Fancy animations, great illustrations, a flow that made sense. It also had to get the customer to vest by the time in app before it prompted for credit card and drivers license information (likely drop-off locations). Something that you could use once, or twice years later and still feel like an expert user. Being able to sign, or annotate the document just made sense, and the app helped you along the way.

On the web, we chose the "ugly, messy interface" approach. Ok, so it wasn't ugly at all, it was beautiful! It wasn't super simple however, it leveraged white space for "same page" content delivery. In every 3-5 minute call, the notary would have to review the drivers license, review and edit the document, maintain a video call, and charge the user. Having multiple pages and a simple design would only have lead to long-term frustration for the Notary user. Instead we focused the design on every click needed to perform an action: "add a signature", "add a date", "mark complete", "charge user", "Don't charge user", etc. In fact, we designed the system to just assume that the Notary wouldn't want to click much at all. The system automatically answers the next call in the queue, unless the Notary intentionally marks him or herself unavailable (everyone needs a lunch break!). The drivers license is visible, and directly below the video feed, so you can validate it without even clicking, tabbing, or hovering (but you can hover or click if you need more detail). I.e., the interface was optimized around speed, knowing that the notary would get some training, we optimized the UI for the expert.

The admin console was targeted at frequent tasks, reviewing analytics, and less frequent tasks, adding or removing notary agents who work at the company. As a business starting out, it's likely the owner would have that dashboard open much like a real-time dashboard for a rocket launch. We designed for this persona as well.

All this is to say, is that each part of your product, think of who will be using it, and what their needs are, and design for that. Jonas talks about the Craigslist UI, but users can find what they want, they don't have to search, it's look, and click, no searching or figuring out how to use the UI. He also talks about the Photoshop UI, again, can you imagine how much clicking it would be for a digital artist if this was a simple design?

On a last "devils advocate" note, working on Small Business Server 2008, we wanted to target the DIY or "Do-It-Yourselfer" as the system administrator, but also enable the paid consultant. More time was spent trying to figure out how to make the UI work for both audiences than I care to sum up. Looking at the product now, it just looks like it's for new administrators, missing both marks. There are very little DIY people administering the software, and most of the consultants use the standard server consoles. Ultimately, targeting two audiences just alienated both of them.

While Jonas hits a great point, it's not that we like ugly, messy interfaces, its that we like UI that's targeted to our use cases, but we want it to look beautiful, right Jonas?

How are people using your product?

Kudos to the MetaLab team who pulled this together, such a great team of designers, developers and QA. Learn about the Notarize product here - http://metalab.co/projects/notarize/