My top tips for making your user experience design not suck

I’ve taken a fun little transition in user design and user experience.  After a number of years developing websites, I’ve spent the past year help shape the user experience of my company’s iPad app.  The process has been… uneven, admittedly.  We officially got our first app review, and it was 1 star!

I always tell my users “I like positive feedback, but I love negative feedback”

Getting this app review came at a good time too, we’re in the process of updating the app, so the 1 star review really helped us.  The review was “has content, but just no direction.”  Personally, we couldn’t agree more!

First off, no excuses here.. we had issues with the direction of the app.  We wanted our app to contain lots of helpful content, but we didn’t guide the user as quickly and easily as we should have.  We also dealt with an offshore, 3rd party development firm.  They did a good job, but items got lost in translation.  In short, we learned how to fine tune our approach with the offshore development team, but we’re also in the process of cleaning up the sins of the past. 

Some of the items we’ve learned and improved upon are listed below.  Perhaps you already know them but  these are items that we’re revisiting now to give our app a more pleasant experience, and are also guiding principles for any software application you may be architecting.

1. Start with a goal – This is UX 101, but honestly.. we had issues here. We had a number of items that we felt our app could do, and we tried to do them all.  At the end of the day we wound up with an app that does all of these things pretty well, but not one thing great. The problem is, the user’s noticed this in the experience.  The items we developed weren’t fully robust.

This is something Apple is so darn good at doing.  They limit their scope and design the heck out of it.  Microsoft on the other hand puts their hands in everything. They’re not great at one thing, but are pretty good at many things.  After knocking Microsoft for so many years about this exact principle, here I am on a team committing the same sins!

Pick your idea and stick to it.  Make a mission statement for the product and consult it if needed, but don’t try to do too many things all at once.

2. Don’t penalize a user – So our app involves a little setup.  The app helps a user sell an extended service contract for a used vehicle.  To do this, the user needs to answer some information (what vehicle are you selling, are you including any other costs, is the customer financing the sale).  That’s just a few of the questions.  We found 2 issue’s with this approach.

First, it’s a lot to ask of the user up front!  There are 12 different questions for the user to tap through, which is probably about 11 too many for the user to care.  Could the user walk through this process if they really wanted to?  Sure.  But the point here is, don’t count on the user wanting to perform these actions, instead make it as simple as possible, even if they don’t want to perform these actions, there’s a better chance they still will because it’s low effort.  We’re no going through and removing over half of the initial setup questions, making a separate section for anything that is optional.  That should help us get the user’s buy in for the app.

The second item involves how we collected data.  Once a user started the process, we didn’t make it easy enough for the user to cancel.  If they chose to cancel, it would reset the entire form.  If the user completed a question, they could no longer edit that question.  Once a mistake was made, you did not pass go, you did not collect $200, you went to jail.

Needless to say, users HATED this experience.  Heck, we HATED it too! So why did we ship the product this way?  We ran out of time.  It was either ship late, or ship on time with a faulty process.  As said before, we’re now fixing the sins of the past, and this is one of those items.

3. Make your actions consistent – One of the nice things about designing a product is that some decisions pay dividends.  For example, when you choose a color layout, you no longer have to question “what color should I use for this text” since you’ve already decided that.  Once you use a color somewhere.. keep using it! 

Actions within the aforementioned app weren’t completely consistent.  We were consistent almost all of the time, but when it comes to end-users, almost doesn’t count.

Take the time to choose your action buttons, how they look and where they’ll be placed.  As importantly, make the placement consistent (always in the bottom right corner for example). If you’re going to place “Save” and “Cancel” buttons next to each other, place them in the same orderly consistently.

4. Don’t change too much too often – Item 3 discussed placing items consistently. Item 4 is all about respecting that. When you place items consistently, users learn where items are placed early on and become much more inclined to continue to use your product\service. Forcing a user to re-learn how to use your application is a big deal!

Of course, there are always times that you need to make a change.  Perhaps it’s a company rebrand, or perhaps an item wasn’t as well thought out when it went live.  If you’re going to change, don’t change too often, and certainly don’t take half-measures when performing your update. Anything worth doing is worth doing right.  Make a change that you’re comfortable living with for some period of time.

5. Don’t chase perfection – The classic project timeline killer. Here’s the scenario: You take the time to design your screens, create wireframes, consult the user’s and perhaps even write a technical spec!  In other words, you took the time to think.  Once you get as far as actually testing the application, it doesn’t feel right.  Perhaps you need another button, or an option is missing.

For our iPad app, using a 3rd party put a lot of time and communication between the ability to identify a need and complete work on that item. It also came with a cost: “We can do this, but it will take 2 weeks and $1500” was the usual reply.  These responses forced us to look inward and say “is it worth it?”  Depending on the item, sometime’s it is, but treating each change as a cost really helped put wants and needs into appropriate perspective.

Software is never perfect.  Respect that there’s always a balance between getting things right, and getting things live.  Learn to live with imperfections and simply target them for a future release.

---

PS – Thanks to MikeMark.com for the post image, it was too awesome to pass up when I saw it on the web.  You can see the original logo, along with an interesting intro to UX, here - http://mikemark.com/2013/06/user-experience-intro/