Recently, I found myself the unfortunate victim of a poorly redesigned User Experience. No... this wasn't a new version of some software program. This was a change in the cafeteria at my office. Bear with me...this isn't just me ranting.
I don't eat in the cafeteria much. In fact I almost never eat in the cafeteria. I do, however, get a drink at the cafeteria daily. Up until last week, the process was very simple. I could go to the soda machine which had the cups, lids and straws kept in a plastic dispenser directly to the right of the soda machine. So the process of getting a drink was simple. Pick up the cup, fill with ice and soda, retrieve a cover from the dispenser, get a straw and off I go.
One day I noticed there were no straws next to the machine. I assumed the dispenser needed to be refilled. I asked someone for more straws and he quickly walked out into the the area where all the tables are (the soda machine is in the area with the kitchen and salad bar) and opened the cabinet below the counter where the utensils and napkins were stored and pulled out a box of straws. I took one and off I went.
Ever since that day, there have been no straws near the soda machine. They are now stored along side the napkins and utensils.
So here is the problem. The straws appear to now be kept in the current location for the sake of keeping them near the place where the extra stock is stored, instead of where they are actually needed. This is often a problem in software development as well. How many times have you heard a developer say "it is easier to put the button here" or "we have to do it this way for techincal reasons." There may be times when it is techincally challenging to make software do what is best for its users. However, the problem could have easily been solved before it was a problem, by thinking about how it might be used.
One could argue that many people who come to the cafeteria are there to eat so they will likely need napkins and utensils as well. However, the is a whole other type of visitor, that frequent the cafeteria. This is also a common problem in software. As developers, it can be very difficult to think about anything other than "The User". The problem is "The User" is a combination of every possible type of user which leads to an interface created for a person that doesn't really exist. If the cafeteria manager thought about "customers here to eat", "customers here for a snack" and "customers here for a beverage" then it would be obvious that things should be set up to accomodate each of them. For example, customers planning to eat would likely need utensils, napkins and straws. The current set up would work well for them. Customers who came in just for coffee or a soda would probably never need to visit the seating area at all. Placing sugar, creamer, straws and napkins right by the checkout would make a lot of sense.
We can do this in software design as well by thinking about the types of users the system might have. The point is to make sure you are supporting the real users of your software so that you don't make the system difficult or ineffecient for a significant amount of them.
No comments:
Post a Comment