A COMMON MISPERCEPTION

Very early in the life of catapulter.com, before we hired a designer, our team drew up a basic user interface that we believed would work well for the site. We haggled over details for a few nights, and finally came up with a pretty solid UI.

Fortunately for us, one of our mentors set time for us to chat with a UI/UX expert before we hired one.

The first thing he asked us was: “how many people did you test with?”

Of course, we had asked a few people what they thought, but we hadn’t put together a preset, regimented UI/UX test. We had intended to have a designer with UI experience take our initial PowerPoint mockups and move to this step.

Wrong!

WHAT YOU’RE ACTUALLY SUPPOSED TO DO: TEST

It turns out, we didn’t have to go to that level. As a professional UI/UX guru, one of our mentor’s typical first steps is to hold very rough UI/UX tests:

  1. Sketch out a rough wireframe of your site, with every piece needed for the user to complete your target action
  2. Write up a questionnaire to be used consistently across users
  3. Find a bunch of people in your target audience who have no idea what the site is about
  4. Ask them to “use” the wireframe as if it were a website – e.g. for us “plan a trip”

Admittedly, we weren’t entirely convinced this would be useful, with such a simple sketch of our idea…but once we started, we quickly realized that the important part was NOT having users visualize the site.

The important part was that users knew what information they wanted next, and they expected that to be available. Just like on a live website, if the required info isn’t readily available, the user will get confused, frustrated, and/or leave your site altogether.

Given this, much of the value in the test was not asking the user “what do you like/dislike”, but watching the user navigate, asking what they’re thinking at each step of the process, and recording as much information about their experience as possible.

One of the best pieces of advice that we received during our intial design phase was from fellow Betaspringer Andrew Draper of Manpacks:

“At every step of the way, get it in front of users as soon as possible. You think you know the main issues with your site, but as soon as you show users, you’re going to get bombarded by complaints, and see that the biggest issues are actually three things you never even thought about.”

GET it “on paper”

Our next step was throwing together a PowerPoint of the site. I admit that this is mostly because I’m an ex-consultant, but one of its best features is that you can create working links between pages, convert to a PDF, and send this linked mock-up of your website by email to users. If you don’t like PowerPoint, there are a ton of other mockup and wireframing options. Ones that I’ve played with include:

  • Cacoo – An online mockup tool that can be used collaboratively like a wiki
  • MockApp – A package of images of iPhone buttons for Photoshop or PPT that can be easily cut/pasted to create a realistic iPhone mockup (Hint: Use this in PowerPoint, print to PDF, and download the $0.99 GoodReader app to use with working links)
  • There are many other, likely better mockup tools that I haven’t worked with – A recent, pretty comprehensive list of other mockup tools can be found here

As you go through the UI/UX tests, as Andrew said, you’ll notice there are a lot of things that need to be changed, many of which you haven’t thought of. At this point, you’ll begin to realize another very important rule of UI/UX design: you’re never done!

The biggest misconception many first-time web designers have is that “we’ll design and build the thing, then we’re done.” Never. You’ll always have something that doesn’t work just right, new features that a ton of users want (expect, really), and you’ll need to continue to iterate.

Therefore, the key takeaway is: don’t half-ass this initial mockup, testing and design phase.

Test with good amount of users (10-20), incorporating their feedback and iterating as you go. Once you’ve begun to understand what your users want, not just what your team thinks they want, you can move on to spending your time and money on building the site.

This way, you’ll start from a much stronger, user-validated initial design, you’ll understand what additional functionality users want you to build, and you’ll have already seen (and hopefully circumvented) many of the pitfalls that can make a user leave your site immediately and never come back.