I’ll ad to that. From personal experience, there are a few other important things to consider when evaluating how much attention to put to the small things. First, what a user considers a small thing versus a big thing is very subjective. You might think its no big deal, and the user might think its a major mistake. Consider what Facebook developers thought was a cool new feature–small stuff for a cutting edge development team.
The problem was a new option called News Feed, which creates regular reports about the activity within a network or group of friends. It may have seemed like a good idea at the time, but it set off a revolt in the Facebook community. Users felt that their personal information was being broadcast all over the Web without their permission. Never mind that they had posted it all publicly themselves. Or that it went only to people who were friends or already in their networks. Facebook is a fast-moving, throw-it-up-and-see-if-it-works sort of place that typically adds a feature, watches how people use it, and, based on feedback, adds things such as extra privacy controls. But this time, Zuckerberg and his crew had made a mistake by not putting privacy features in place first.
Taking advantage of another new feature, which allowed individuals to start their own issue-oriented “global groups,” disgruntled users set up a group they called Students Against Facebook News Feed (Official Petition to Facebook). Ironically, the News Feed service itself then spread the campaign (“Your friend has just joined this group!”). In less than 48 hours, 700,000 people had joined the protest, and the blogosphere declared it the end of Facebook.
The story didn’t end that way, and Facebook seems to have recovered just fine, but it illustrates in today’s wired world how quickly a small mistake can turn into a huge mistake.
My second insight is that it seems that when engineers start getting careless because they are trying to “not let the perfect be the enemy of the good” little bugs start slipping through. So, its always healthy to make developers pay attention to small stuff. It keeps them on their toes, and alert to the details, and potentially prevents major problems from occurring later in the development process — the cause of embarrassing delays.
Of course, my guess is that Rhea was referring to interface design and usability. But I have to totally agree with Jakob: “…getting the small things right enhances usability and fosters user comfort.” This is also true in the area of functionality development. Design the tools right from the start, beta test it to see how human’s respond to the page flow, navigation, validation and site feedback, and then be willing to go back and tweak things to make sure its right. It makes a difference, even if your users don’t can’t always pin-point it.
P.S. I think breadcrumbs are cool too. You can read the full article on breadcrumb navigation from Jakob Nielsenâ€™s website right here.
UPDATE: I went over to Jakob’s site after posting the above comments, and read his article titled “Does User Annoyance Matter?” He says something that is key to understand about the “small stuff” that comes up in web development, “Annoyances matter, because they compound.”
If the offending state-field drop-down were a site’s only usability violation, I’d happily award the site a gold star for great design. But sites invariably have a multitude of other annoyances, each of which delays users, causes small errors, or results in other unpleasant experiences.
A site that has many user-experience annoyances:
* appears sloppy and unprofessional,
* demands more user time to complete tasks than competing sites that are less annoying, and
* feels somewhat jarring and unpleasant to use, because each annoyance disrupts the user’s flow.
Even if no single annoyance stops users in their tracks or makes them leave the site, the combined negative impact of the annoyances will make users feel less satisfied. Next time they have business to conduct, users are more likely to go to other sites that make them feel better.