Thursday, May 22, 2014

Overcoming piecemeal design

Do you think Rome was built in a day? Do you think that someone carefully plotted out all the streets, the water ways, the sewage system, housing positions, public parks, or any of the other parts that made up Rome when that old guy with the beard came up with the saying that "Rome wasn't built in a day"? Probably not. Indeed, it's likely that early in the cities lifespan there was probably a simple quaintness that made it a charming vacation destination. Over time, it was pieced together one corner stone at a time until at some point it became a magnificent specimen of a city! Piecemeal design can work out. This is however precisely what I'm going to avoid talking about today. 

In this article I intend to pose the idea that there is certainly a sweet spot between the business goals and the users goals that we must seek out as growing User Experience Practitioners.

What is piecemeal design? One definition of the term "piecemeal" describes small unsystematic measures taken over time. With that definition, it's pretty clear that what I'm referring to are those interface designs that we've probably all seen that have been built over time, that are difficult to use and are made up of less than optimal process flows, many of which result in poor process termination.

What got me thinking about this topic was when one of my team came back from a conference in Denver and talked about how a highly acclaimed speaker in the UX industry was speaking on mobility. The speak referred to an inflight wi-fi provider. He described how once upon a time, the providers website had a form to register for the service that presented twenty-three (23) input fields that the user would be required to fill out before using their service. He then went on to explain how they were able to narrow it down to a short four (4) input fields long for mobility purposes. Think about that... How on earth did that company get to 23 input fields? Is that where they started when they originally designed this form? I speculate that maybe there is a chance that it was less at one time, but through piecemeal it grew to the awkward number of twenty-three (23).

Another example that I've seen this piecemeal problem is with the search functionality on a highly well-known retailers website. I remember going to their site one day and typing in "cupcake" for something I was working on. When I hit the "Go" button, I was given several results. The number one (1) result on the list was baby clothing... Strange. I then tried another search. I tried the search term of "sheets". When I went to click "Go", I remember expecting to get a results page full of different sheets. Instead, I was immediately take to a screen that seemed to be dedicated to "sheets". The website wanted me to specify size before I got to look at the products. Strange?! Why is this happening? I happen to know a little of the history of this particular search tool. I also happen to know who runs it and have specifically had conversations with them about it. It is the way it is the business has requested that design changes be made in specific ways to better suite their reporting needs. 

What lesson can we learn from these two examples? For one, there is a danger in allowing business reporting drive design decisions. What else? Well, it seems that in the case of the in-flight wifi provider, there may have been a reason for there being so many fields that could have extended beyond business reporting needs. Could there have been security reasons? Could there have been customer complaints? What about the search tool? Was there a problem in a more simple form that they attempted to address through piecemeal build-up? These questions do not get us much closer to a solution.

So ultimately, what is the solution to this sort of problem? It seems there there may be danger in over complicating, but then there seems to be a danger in under simplifying as well. How do we avoid this sort of travesty?

Before a line of code has been written, before a line of ink has been drawn, and before a color has been chosen, there needs to be a thorough understanding of the Business goals, but then also the User's goals. Once a thorough research effort has been carried out, only then should the design be worked on.

Piecemeal happens when the research phase is skipped. Compromises in design decisions are often the cause of such silly design tactics. Could have been due to time, budget, higher-execs making their "awesome leader" decisions. Whatever the reason, the solution is to understand the user's goals and understand the businesses goals before making design decisions.

Friday, May 9, 2014

User Experience Getting Started Reading List

As I was reading a book one day, I realized that I'm not even certain the book was of any value in helping me get up-to-speed as a beginning UX Practitioner. I decided to put together a User Experience Reading List to make sure that the next book I pick up puts me in the "Popular Learning Zone" of the UX Design Profession (roughly). 

visual metaphor showing a circle with an x, then an inner circle showing the popular learning zone.To come up with the list, I Google'd the term "User Experience Reading List". I compiled all the reading lists from 40 different websites. The list has 200 book suggestions. I've also kept track of how many times each book was "suggested" as an early learning (or foundation) book for this line of work. 

The book list has 2 sheets: 1) The list that is ranked from "top suggested" down to "least suggested", and 2) The source websites.

I hope that this book list helps you get going. I'd love to hear any feedback you may have.

User Experience Getting Started Reading List - 2013