A Penny On The Sidewalk

There’s a sociological test where a coin is placed on the sidewalk and a varied percentage of people will stop to pick up the coin. There are many factors, the greatest being the value of the coin. The average person won’t take the time to bend down and pick up a penny, but most people will pick up a quarter. Nickels and dimes fall somewhere in between.

I’m not sure what the exact purpose of the study is, but I think it makes a great metaphor for a tool or application that isn’t quite worth the trouble to use. Oftentimes it’s the very simplest differences that determine whether the cost of learning and using a tool is worth the value that the tool provides.

Example: Team Foundation Server takes a long time to load, loads into a small window inside visual studio, and requires lots of clicks to push things through (Assigned must be saved as Active, THEN as closed). The web version loads faster but I hate that I can’t simply check off a list of bugs and perform a bulk update. Creating a new bug requires me to fill out several fields, and it’s just not worth the trouble for most minor bugs, so I jot them down on a notepad in a meeting then type them into a word doc.

Fogbugz has a beautiful, intuitive interface, you could quickly add bugs and manage bugs with bulk actions. I would write things down directly in fogbugz. Both work, but it’s a quarter on the sidewalk. Granted, I didn’t set it up, and the fact that TFS is built into Visual Studio gives it more credence, and it does have a lot of integrated features which give it more value.

Another example, I just recommended to my collegue and fellow blogger to change his homepage settings to show full articles instead of summaries. this was my case: my wife reads lots of blogs. She uses an agregate service (google reader) and will only read blogs that show up in full because it’s faster to load and more convenient, especially on a smart phone. She won’t even bother subscribing to blogs with a summary setting. That tiny inconvenience of having to click into your site and back to the reader is that little difference between being a penny or a quarter on the sidewalk. That may be a rare and very subjective case. I could go on about the best cases like credit card purchase streamlining solutions or the worst cases of sites that make you do back flips to perform the simplest task, but I think you get the idea.

So is your solution a penny or a quarter on the sidewalk? (If you won’t bother to pick up a quarter then you are a snob). Some factors are personal preference, but they all amount to a few universal factors:

  1. Speed.
    The king of kings. Take too long to load your pretty pictures and I’m out. Animation? It’d better be quick and fluid. Flash Intro? Skip. It was cool the first time…maybe. I have to create an account before getting basic info? I’m looking at YOU, experts – exchange . com, (purposely not a link). Don’t ask why stackoverflow is crushing you. Myspace vs. Facebook? Enough said. Keep your glitter, give me my news feed.
  2. Usability.
    Yes, noble developer, you find your site easy to use and don’t know why everyone else has so much trouble. Well, they don’t live on the web 8 hours a day like you and haven’t been staring at this app for the last six months. You have to watch people use your site, see how they don’t even notice your glossy icons and how they struggle to perform the simplest tasks, despite your tooltips, FAQ, user guide pdf and captivate animations. Hear how they curse at your creation, and wistfully compare your solution to their old, dependable paper system.
    Coupled with basic understanding is the general ease of use factor. Forcing users to click through extra pages to get details or update individual records when using AJAX to load extra data or including a bulk update feature would work; these are the subtle features that greatly affect user experience. In instances where users are making an online purchase, they can often make or break a sale.
  3. Reliability.
    A.K.A. Quality of Service. “The network is down!” Cries Chicken little. This app has gotten really slow, it’s really frustrating! Oh, that’s because of that sleek javascript thing you wrote. It worked so well in your development environment with two test records. Bet you didn’t account for people pasting 10 page word docs into the “Remarks” field and uploading giant uncompressed powerpoint files.
  4. Design.
    This is often the first lamb to the slaughter when budgets or schedules get crunched and that is a great tragedy. A high quality interface design not only provides clarity and improves usability, but on an almost subconscious level, you just feel better when you’re interacting with a sleek, modern design . It gives an impression that the underlying technology is built with the same attention to detail. It is also important that design decisions are implemented site-wide to make a uniform user experience.

There’s nothing revolutionary here; these are pretty much common sense. What I find amazing is how many developers I’ve met that simply don’t seem to care about user experience. They simply go through their requirements checklist and feel like their work is done when they are capable of executing the required actions within their own application. The apathy epidemic is most acute on internal applications, partly due to the fact that the audience is a captive audience. It’s their job to use the in-house app and there’s no alternative. Developers can’t take all the blame though. Business decisions often place user experience as a lower priority and don’t allocate the time or personnel required to truly make a project shine. In many cases, developers aren’t even allowed to add or improve features that weren’t specifically requested or paid for by the client. But in those cases, it’s the client’s fault, and there is no more literal example of the phrase “You get what you pay for”.

This entry was posted in clients, work. Bookmark the permalink.

5 Responses to A Penny On The Sidewalk

  1. John Pencola says:

    “I just recommended to my collegue and fellow blogger to change his homepage settings to show full articles instead of summaries. this was my case: my wife reads lots of blogs. She uses an agregate service (google reader) and will only read blogs that show up in full because it’s faster to load and more convenient, especially on a smart phone”

    Hello, I’m that fellow blogger! :) For the most part I can appreciate what you are suggesting, but for Liquid Language (the blog mentioned), I actively chose not to support full article text in my RSS. Here’s why: Liquid Language (LL) is a destination site; it’s tailored to be viewed as such not a face-less impersonal text document. Although you can consume the information partially, via the summary in your feeds, you just don’t get the intended experience. To me that experience is more important. I feel that if someone shows enough interest to take the time to subscribe to LL, then I’m betting if they see an article in their feed that intrigues them, they’ll make that extra click to visit the site.
    Also, your generalized comment about being “faster to load” is misleading since that really just depends on the website you are subscribing to. The time it takes to type LL’s address into the browser and pressing return seems faster to me than:
    – directing your browser to Google Reader’s address
    – (potentially) logging in
    – Finding LL in your Subscription list
    – Clicking LL link in your Subscription list
    The other obvious downside is that if you have enabled your viewers to get all they need from a Feed Reader, then you lose out on real traffic to your site, which leads to lots of lost context (comments), analytics, and other important bits that make up the experience that is the site you have tailored.


  2. mindstorm says:

    The point of the post is that every decision needs to be measured in the potential value for the client, which you’ve clearly done in your case. Many usability features and design are subjective and there are often trade-offs. Others, like speed and reliability, are less open for debate.

  3. John Pencola says:

    I get what you are trying to convey. I wanted to take the case your presented and detail why I made those choices, relating them back to the factors you mentioned; speed, usability, reliability and design.

  4. mindstorm says:

    The only factor that applied to your case was usability, unless you count design, because I know you put a lot of time into designing your blog:)

    As for traffic, you really think Google isn’t smart enough to count hits from Google Reader (which does include images btw)?

    As for LL being a “destination site”, that would be a user decision whether styling are important to them. Consider the audience that reads blogs from reader apps in phones. The visual experience, speed, and ease of data access is much better than having to click tiny links with your finger and visit a website that probably isn’t optimized for a phone.

  5. John Pencola says:

    I didn’t mean to hi-jack this post! But I think its important that we are having this
    discussion and I definitely want to keep an open mind.

    “because I know you put a lot of time into designing your blog”: Hmm… not sure to take that as a compliment or not :D ! Let’s just say I put a lot of faith in the TwentyTen theme and do design tweaks when they occur to me. :)

    The bottom line for LL is that it’s geared for a certain audience and is tailored to be experienced @ blog.johnpencola.com. I like the idea that RSS can serve me as a referral, so I kept that capability, but in a way I’m suggesting to the end user that they should come to the site to experience it in full by only exposing the summary.

    Per the comment about traffic, “…then you lose out on real traffic to your site…” What I mean by that is visits to your site (proper), not hits to an RSS feed. So, it goes well beyond a third party simply counting visits to your feed in a reader.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>