The House that Jack Built…Is Crumbling Down

Let’s say you are a contractor building a new home for an unknown family. Looking at your deadline you realize you aren’t going to make it on time. It’s time to do something to solve the problems. What can be cut first?

Perhaps you get cheaper wiring, maybe the concrete on your house didn’t dry before the rest of the foundation had set. Because you are behind schedule you feel the only way for you to “catch up” is to cut corners. Cut one corner and you have opened up Pandora’s Box. It’s so easy to cut more and more. You begin a process of jamming things in just to meet the deadline. One year later the house catches fire and you are sued because you cut those corners.

Elevate Your UI Design To Another Level

The same holds true in UI design and in the UI design process. Frequently you can get rushed to put an unfinished design to the test with real users, even though you are aware of other issues with the design. It may be slow, it isn’t usable, lacks cohesiveness, tries to do too much, is hard to understand, is missing key features of a process. All of these are symptoms of a rushed and hurried design. You can see this in pretty much any application.  Your goal is to minimize this but how?

Give Your UI Time To Mature

This is one of the big concern designers have with an Agile development process. The same can also hold true in a Waterfall management process. The rate of development and design is fast and it’s extremely tricky for the UI designers to stay ahead of the development cycle. What’s even scarier is if the business fails to understand the importance of re-factoring and retesting a design. Rarely, is a UI design perfect the first time. It should and must be tested preferably by the people, person, that are going to be using the application. The problem is getting those that have direct interest in the application to buy-in( I’ll cover more about this later).

Dress your UI Design For Success or Send it Back to the Orphanage

It’s important to somehow let the client know that the first impression of an application is the most important. This is your adoption point (your such a cute design yes you are). If your customers don’t like the product at this point you have to work three times as hard just to gain them back!

Please Come Back I’ll Do Better Next Time I Swear!

Think about the last time you purchased a product and were dissatisfied with the outcome. You probably returned the software, car, clothing, food, etc.. and refused to ever purchase that product again. You probably even refused to purchase a different product made by the same company. This is especially important to your web application and UI design. Yes, features are important, but if my car has 3 steering wheels, 5 extra tires attached, and everything is labeled in Japanese are you going to think it’s usable?

Act Like The Customer Think Like the User

A customer tries to answer two quick questions about your software before purchasing, or using it.

1. Does it do what I need it to do?
2. Can it do it easily?

These are simple core concepts, yet look how many UI designs struggle with this. Look how many Interaction Designers wrestle with these ideas. Think back to the last piece of software, or product you have used. Do you have it in your head? Now think back to the reason you purchased it.

For myself the last item purchased was a tennis racket. These were the thoughts going through my head.

1. Can it hit a tennis ball? – Question Answered – [FEATURE]
2. Is it lightweight, balanced, and does it feel right to use? – [USABILITY]

If I was able to answer the above questions and after repeated use (learn-ability, memorability) could continue to perform and even excel then the design was in essence “great for me.” Why did I put this in quotes? Well as UI designers we have to find that common ground to support the vast majority of users. Are you really really going to find a UI Design that supports 99.9% of your users. You may find a a design that meets all the goals of your (persona’s -fake users), but even that is a rarity.

So What Makes a Design Great?

It’s the combination of a great feature set that has a high level of usability and has an aesthetically pleasing design. It’s about a design that delivers direct answers to the questions.

Does it do what I need it to do?
Can I get it done easily?

So the next time someone says just jam that feature in to the design. Feel free to send them to this post so they can see what really happens and how many aspects of the software you effect because of quickly rushing a design. Your adoption point or the first release of your application is your first impression. Fail at making a good one and what was the point of even producing the software?

Related articles:

1. User Experience Design in an Agile Development Cycle
2. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?
3. UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?

Lately, I’ve been trying to push the power of paper-prototyping. It’s a tough concept to get across though because some just don’t see the value. In fact, the customer, BA, Product Owner, just want you to show the customer a mocked up (coded) prototype. This is nerve racking because problems and issues in the design can be ferreted out much quicker using the paper prototyping method.

The overwhelming response to paper prototypes that I have personally faced is: They don’t seem professional, are hard to read, may be difficult to understand complex web actions. These people need to quiet down and listen. Paper is cheap and easy to modify on the fly. Paper prototyping is more than just showing a piece of paper. It’s about defining, refining, and streamlining the interaction between the user and the proposed widgets, functionality, etc. Paper and markers and traditional means can represent all these concepts with little difficulty. You just have to get a little creative at times, but the new ideas that come from these paper prototyping sessions can point you in a new direction.

Several times I have worked through a prototype with limited customer feedback(not recommended) and discovered core application function that was not identified. By discovering this up front you can better prioritize absolute functions from secondary functions. IE: I need to be able to save my book title, but I also need to give it a custom save descriptions.

Customer: “Wow, we never thought about that. We just wanted them to save the book using the title as the saved name.”

You may even discover larger problems such as entirely missing pieces of functionality.

If at all possible you should involve the end customer of your product. I’ve been trying to get this practice cemented into our process but it’s not an easy one. The general premise is this; everyone feels they are right and specs were translated correctly into business needs. It kind of makes sense that you need the customers input to ultimately test the system? However; this type of input rarely seems to happen at the level required. Focus groups, usability testing, is an afterthought and tends to be reactionary instead of proactive

Related articles:

1. Which Widget is the Right Widget for My Application Design?
2. When is it the Right Time to Use Icons?
3. Design Experiences: Don’t Rub Your Product Experience All Over Me.