Little Springs Design. 2001 – 2010.

Imagine walking into a nice hotel, having a very easy time checking in, being greeted by name, and even being given a cookie. You have a very positive impression of the hotel.

That impression can get worn down by the details. Not just the cleaning staff, but from work done long ago by somebody with no investment in your brand whatsover: construction workers.

The sink controls have hot and cold on the wrong sides, causing you to drink warm water for a while.

The tub faucet is designed in a way that suggests it is a lever, but actually it requires that you brace yourself and pull straight out. The shower curtain rod is crooked on the square tiles.

The television remote has a nice large button at the top right, which does not turn on and off the television. (a small button at bottom does that instead).

The free in room wi-fi only gets into your room sometimes, and only in one corner of the bed.

You learn that your credit card data is stored on your room key.

You don't finish the Starbucks coffee brewed in the room due to the aftertaste created by an uncleaned coffee pot.

The exercise room is not open 24 hours, despite being separated from all guest rooms.

Every time you enter the room, it takes two tries to open the door -- even though the LED indicates success on the first try.

The business center does not seem to have a way to print from your laptop without installing print drivers, at 99 cents per minute (charged to credit card, not room).

The toilets in the public restrooms are "conveniently" close to the side of the stall the low-placed toilet paper is on. This configuration requires a bit of contortion to actually reach the paper when you need it, and requires larger patrons to have to twist to use the toilet at all.

These details are busy degrading the hotel's brand, and they are mostly out of the control of the current management. These are the same types of details degrading your brand, but they may be more under your control. And I recently had an experience with all but two of the above aspects; the other two were elsewhere.

I can guarantee that the architect did not envision toilet contortions, and quite probably had more human specifications for the actual layout. The folks doing the actual installation didn't have that vision; they were just showing up for a day's work.

Maybe the specifications didn't make sense, maybe the workers thought they knew better (perhaps because they had to "fix" other parts of the specification), maybe they were just lazy.

Developers do this too. They have to, for the same reasons the construction workers do. But their expertise is in building things, not in designing an experience, so some of their fixes won't be right, and your customer may suffer. But remember: developers want to do a good job.

Increasing the details of your specification only helps if you've been under-specifying your product. In most cases, more specification won't help. In software, if you fully specify the software you have essentially written the software but in the wrong language.

You will experience these problems more in environments where specifications go "over the wall" between product management/marketing into development.

Solutions:

• add a designer component to the QA process. By providing responsibility for product review on the design team, both specification misinterpretations as well as places where the specification was wrong or incomplete are caught.
• train developers on user-centered design. While their job is to build the thing, an increased awareness of how to translate user needs into design will help their "fixes" of the specification.
• include developers in the formation of the vision and design of the product. This increases buy-in, increases understanding of why things are as they are (for better "fixes"), and increases the likelihood that the envisioned design can actually be built.
• increase the flexibility of the development team. Take an attitude of prototyping, of the right to throw away code. Thus errors are not fatal or permanent. This is particularly important for open source teams.

This entry was posted on Sunday, August 5th, 2007 at 2:02 pm and is filed under Business, Design, Design Tips. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.