Designing the User Experience

Posted by: Josh Walsh in User Experience.

When we think about the development of websites, we think of the back-end development, graphic design and semantic markup that are coded and combined into the finished website.

The user experience design is often overlooked. It is intangible, naturally vague and difficult to understand. However, making this user experience comprehendible is crucial to the design process.

It is very tempting to skip over the experience design and straight to designing in Photoshop. Perhaps our ego gets in the way, or we are scared of spending hours that, in the end, don’t return a tangible product.

In the end our user experience notes and research are transformed into wireframes, design comps and ultimately the finished website.

Understanding the Business Process

I am a firm believer in simple procedures. Breaking complex problems down into simple patterns guides the development of the user interface and brings potential problems to the forefront while they are still simple to change.

Typically, I draw out these procedures with a pen and paper. I like using paper because it’s fast. You can throw bad concepts away, or scribble all over them until you get them right.

These drawings end up pretty messy, so I’ve cleaned them up in Omnigraffle for presentation reasons.

The Business Process

For the following examples I will be using the order fulfillment process from our upcoming application, Simpli5. This process begins with a new order and ends with a product delivered to the customer.

Disclaimer: This procedure has been dumbed-down from the actual procedure we have implemented in Simpli5 for demonstration purposes. It can, and probably will change over time.

Finding a Starting Point

If your business process is new or proprietary you will need to start from scratch. In our case, order fulfillment is a well defined problem already. I have taken time with retail business owners and had them show me what their order process is. In general, their business process looked like this:

This procedure is pretty simple and does work. However, it is not without its own problems.

• Some of the steps are redundant or unnecessary. For example, What is the difference between a “new” order and a “pending” order?
• When an order is shipped and out of your hands it still has not been marked as complete. This takes up administrative time to complete after the fact and the result is that most people end up skipping the “shipped” status altogether.

Given these problems, I made a few changes.

• I removed the “pending” status, it is the same as “new.”
• I removed the “complete” status and ended with the “shipped” status.

At this point, I still was not happy with the way the “paid” and “shipped” statuses were handled. There were too many exceptions to the rule and no way to elegantly handle them.

• It is possible for a payment to bounce. You cannot account for a order that has shipped and come back unpaid.
• Orders are not always shipped at the same time. If a product is on backorder, you may ship it after the products you have in stock.

At this point it dawned on me, “paid” and “shipped” are not statuses, they are states. I removed these statuses from the timeline and replaced them with “IsPaid” and “IsComplete” boolean states.

Also, our workflow is way too ideal. Problems happen, and right now there’s no way to elegantly handle them.

• We might have an order but no payment yet, or a declined credit card.
• The product ordered may be out of stock.
• The address on the order may not be a valid address.
• etc…

A simple parallel timeline fixes this problem.

Each arrow on the diagram is a procedure. I typically give these procedures names so that I can flesh them out in more detail later on.

For example, moving from “In Process” to “Completed” will involve the shipping procedure. Shipping is a procedure of its own and will be analyzed at a later point. For now, we just label these steps.

Once this analysis is complete, I like to take it to my colleagues to review. We will throw a few dozen real world examples at it and see how it performs. We will jointly make a few revisions, or in some cases scrap it and start over.

This procedure takes an hour or two at most and dozens of concepts. (I have only shared a few of the major iterations with you.) Once the procedure has been finalized, draw up a prettier version of it and hang it on the wall where everyone can see it for themselves.