Jump to Content
Small TextMedium TextLarge Text

The Usable Experience of Michael Robertson

I should start by saying that what I know is invariably the product of my work with a team. For the last 18 months I've been Director of Product Design at Local Search Startup Krillion, before that a six year 'tour of duty' with Ariba, and going further back, thirteen years at Vector, a design studio I owned and led in Toronto. It's an interesting journey that's taken me from fledgling visual designer/entrepreneur to User Experience director/evangelist, from the endless winters North of the 49th to the trembling hills (and markets) of Silicon Valley. From start to finish, the teams I've worked with, and those I've built have been stellar.

This "site" will do its best to flesh out the story. The narrative approach I've chosen appealed to me after culling through hundreds of resumes feeling "there's got to be a more creative way to present this stuff." My resume is here too, and the highlights are listed in the sidebar, but I hope you'll take the time to read on. Scrolling is not an imposition on the user if the content is compelling.

Jump to Highlights

 

I fell in Love with a User Researcher

In my Toronto studio feedback on our designs was anecdotal. Clients occassionally ran focus groups but for the most part our yardstick for success was whether we were given another paying assignment. As the web came to dominate our identity work, we looked at server logs and tried to divine user experience from rudimentary reports.

At Ariba I was introduced to User Research and began what has become a love affair with the discipline that informs all our design work and keeps us honest. The impact of user studies is typically inescapable and critical to building usable applications/sites. Ariba's labs see a constant stream of participants, live and remote, internal and external as we test evolving solutions.

In our missionary role we've had success bringing stakeholder groups into the light. We've not converted every lost soul but most developers and product managers acknowledge the end user should have the last word. Amen.

I try to pilot all the studies we run, reasoning there's no better way to keep myself informed and to influence the functionality firehose we don't always have the bandwidth to direct with prototypes. Increasingly it's clear that field research pays huge dividends. Finding opportunities and budget to make it happen is one of my principle goals.

 

Accessibility: The Blind leading the Blind

In late 2000 I took responsibility for driving Ariba's compliance with ADA 508 legislation. The June 2001 enforcement deadline loomed just over the horizon and we knew next to nothing about the standard. In truth, not many people did, least of all the government officials charged with interpreting it.

It's been a sobering and emotional journey at times. It's taken me to Florida to work with the State Disability Office and a remarkable group of users: a blind agency director, a blind IT Manager, a quadraplegic lawyer and a 27-year veteran purchasing agent. Daily each of them overcome enormous challenges to lead productive lives. And all they want us to do is make sites and web applications behave reasonably.

Put yourself in their shoes. Imagine flying blind. Travelling hundreds of miles to a strange city with your guide dog. No one meets you at the airport. You have to find your own way to the office, the hotel, and eventually back to the airport and home. You do all this to provide feedback to a software company that makes a product you must use to keep your job. ADA 508 is the law, but more than that, it's the right thing to do.

Hearing a blind user listening to a screenreader at 300 words per minute or navigating a page by remembering a complex series of tab clicks makes an impression. And in the final analysis this is an issue about the blind. In my experience the problems faced by the motor impaired are significantly mitigated by their ability to see.

Here especially there's no substitute for observing real users. It's taught us that the technical standards are only a means to an end, and that clean structural markup is more important than a collection of affordances like skip navigation links and proper alt attributes. We've come a long way but we can do much better.

 

Visual Design is not for the thin skinned

Great visual design is seldom the result of compromise, and yet it seems I've spent most of my professional career finding ways to bend but not break. Complex web projects are inherently collaborative – depending on the multi-disciplinary skills of dozens or hundreds of specialists most of whom are technical – so it's no surprise that visual decisions often spark spirited debate.

Visual design is much more than making things look pretty, it's about readable typography, appropriate information density, selective emphasis that balances initial and repeat usage, and information graphics that communicate rather than confuse. Generally I believe less is more and nowhere is there more need for restraint than in the design of web applications.

At Ariba I've had some success in propagating a simpler visual treatment. The framework is basically monochromatic. Color highlights are reserved for key interactions and status. Branding is controlled by a single css file. The objective was to make the applications usable and attractive, and for the most part we've achieved that goal.

I'm inspired by the designs of others: Apple and Nike get it right more often than not; the experimental work of Joshua Davis; the efficient minimilism of Google and the pixelated detail of Cameron Moll's Authentic Boredom. Great content makes everything more attractive.

 

Iconography: Hieroglyphics for the modern age

My biggest failure at Ariba has been my inability to control the proliferation of icons in the UI. If there was an international treaty governing their use, I'd sign it. Used selectively to represent clear concepts like error, warning or new, icons are a powerful, space-efficient visual device for the designer. When they're sprinkled like confetti or used to encapsulate complex concepts like "approved negotiation task" they become tiny visual puzzles that distract the user.

 

User will learn how to use it

Training and various forms of help are a safety net I hope are always there for users, but they are no substitute for good design. At a time when the software industry is being forced to take a hard look at itself in the mirror, there's never been a better time to (re)invest in the design discipline.

Make it intuitive and usable from day one and user adoption barriers will fall away so your solution has a chance to deliver the ROI it promised. Good design creates advocates, not prisoners. Get it right initially and reduce change management down the road.

When the inevitable weight of usability issues finally drops it may be too late for users, and retrofitting an existing application is painful for developers already struggling to balance bug fixing and new functionality requirements.

If I distilled what I've learned into just three principles, they'd be these.

1. Do upfront user research; know the user, understand the domain, differentiate the roles and build task flow focused on the 80% use case.

2. Demonstrate that you know who the user is by personalizing the user experience, practice progressive disclosure and remember anything the user explicitly chooses to do in the way of UI customization.

3. Staff and empower your design team to make the ultimate decisions that shape the user experience.

 

Build it in and they will come.