True story: During a recent ad hoc user survey, I quizzed my sister-in-law about her browser preferences. Given the fact that she’s happily using OS X on a late-model iBook, I wasn’t surprised to hear that her primary browser is Safari . . . except when she checks the weather. For that, she uses Internet Explorer. At first I thought she might be getting weather updates from some strange source that only works with Internet Explorer. Upon further questioning, I learned that Internet Explorer is set to use My Yahoo as its start page. Since My Yahoo reports the weather for her hometown, she knows she can easily get the latest weather report by simply opening Internet Explorer.
I explained that she could easily set My Yahoo to be her Safari start page, but she wanted no part of that idea. She only uses My Yahoo when she needs to check the weather — all she has to do is open Internet Explorer. She acknowledges that she could probably setup a bookmark or a toolbar link, but her current approach works, so she’s not going to spend too much time worrying about it. She gets the desired results even if her approach isn’t logical or streamlined. I should also mention that, as a recent Stanford grad, she’s not a dumb person. In fact, my guess is that she’s a pretty typical web user.
My sister-in-law is clearly muddling through. “Muddling through” is a concept that Steve Krug introduced in “Don’t Make Me Think“, his classic book on web usability. Users muddle when it isn’t clear what they are supposed to do in any given situation. If it’s not immediately clear what should be done when a user arrives at your site, they will begin a process of trial and error until they find what they’re looking for. This muddling process leads to some unpredictable user actions. Worse yet, these actions become habits that users repeat every time they return to your site.
One of the biggest mistakes web designers make is assuming they know what their users want and how their users will use a website. These assumptions are usually developed without consulting actual users. In reality, no matter how logically you’ve organized your site and how carefully you’ve built your navigation system, you have no control over what happens when real human beings interact with your site.
Since it’s physically impossible for you to be there when each visitor arrives at your site, your users are left to figure things out for themselves. As Krug notes, users frequently don’t care much about learning the intricacies of your site. The result is they don’t take the time required to “get” the big picture that might be required to use your latest creation.
Here’s the best part. Muddling isn’t just a “user” phenomenon. Web developers muddle too. This is especially true of developers grappling with the transition from old-school web design to standards-based design. Some of this muddling is the result of learning to implement new concepts under the stress of deadlines or limited budgets. Some of it results from not knowing enough. Some of it results from simply not caring enough. Face it, we can’t all be standards geeks.
There are three areas where developers are prone to muddle:
Code: Here’s a bit of news that may surprise many of you in the blogosphere. The vast majority of web designers are not CSS/XHTML gurus. With all of the hacks currently required to successfully implement a standards-based design, it’s arguable that we’re all muddling our way through this particular area — it’s likely that many designers have developed unique and illogical habits along the way. Combine that with the fact that many of the hacks only make sense because they work for completely illogical reasons (box model anyone?), and quite a bit of what we do seems like muddling — even when we’re consciously aware of all of the technical issues involved.
Tools: Our tools aren’t nearly as simple as they used to be. They can’t be because everything has gotten more complicated. If you’re designing with web standards, chances are you’re not using a single, integrated development tool. You’re more likely using a combination of tools suited to particular tasks like HTML editing, style sheet editing, graphic design, etc. Combine those with server-side scripting languages and various content management and blogging systems, and you’ll quickly realize it’s virtually impossible to master of every tool at your disposal. Even favorite tools may not be as familiar as they once were given the frantic pace of upgrades many vendors put their products through.
Process: This is the area where muddling probably hurts the most. It seems to be a natural instinct to begin building sites as quickly as possible. Clients and bosses want results ASAP. As a result, it’s tempting to cut corners on the needs assessments, information architecture, contingency planning, etc. Process and planning frequently get lost in the rush to build the next great website. Even if you have an established process that you use religiously and without compromise, chances are there’s room for improvement — even if it’s some seemingly inconsequential area you normally wouldn’t think twice about.
So what can we do to avoid the muddling? It can be difficult because muddling seems to come naturally. Here are a few suggestions to help you identify areas where you are muddling.
Self awareness: This may sound more like parental advice than developer advice, but you need to pay attention to what you’re doing. Are you really developing in the most logical way given your current level of knowledge, or are you on automatic pilot? Spend some time watching yourself work, and you’re likely to be surprised by how much of what you do seems like muddling.
Continuous learning & research: After scrutinizing your every workday action, you may come to think that you’ve mastered every aspect of web development. When you arrive at this conclusion you should stop immediately and commence a comprehensive re-education program. There’s no way you can possibly know everything. In the standards world, new techniques are invented every day. Part of your job is keeping current with your chosen profession, even as it changes every day. A good web developer is in continual learning mode.
Re-evaluate your tools: If you’ve been using your tool set for any period of time, chances are your knowledge has lost ground with each new upgrade. While many new features are so much marketing fluff, you’re likely missing out on some significant improvements because you haven’t had the time to explore the product. Likewise, new tools appear all the time — you may be able to streamline or improve your processes with something completely different.
Re-evaluate your process: Is your development process documented? If not, you’ll probably have trouble re-evaluating it. Better start documenting now. If it is, then review your process after every major project, amending your documentation to reflect anything you may have learned from your most recent work. There is always room for improvement.
Peer review: There’s been a fair amount written recently about unwanted peer review. It usually comes in the form of strangers validating a site and then sending an email to owner telling them how lame they are. To be clear, I’m not suggesting this sort of peer review (if you can even call it that – it’s always seemed more like drive-by criticism to me). Instead, you might consider forming a small review group of like-minded web designers and analyzing your work on a regular basis, offering constructive suggestions for improvements and sharing insight about your craft.
We can’t control how our users use the Internet, but we can control our own processes. As our jobs become more complex it makes good sense to do whatever we can to minimize our own muddling. We’ll likely make our users lives easier in the process.
What a great article, nice one.
I think you’ve tapped upon the reason why process expose’s are so popular. Good examples include JSM’s Grey Box Methodology, DB’s Design Process Revealed and RW’s Coloured Boxes. They’re my favourite articles, especially when the process involves picking up a pen and sketching.
Muddling through really is human nature. Something that is often quoted is research they did with fire crews. Wanting to know how people think through problems they looked at how fire crews handle emergency situations.
It was assumed that when they got to a fire they would look at the situation, weigh up the pro’s and con’s of various solutions and then go with the one that fitted the best.
What actually happened was more interesting. They would quickly do a mental check to see if there were any obvious problems with a specific cause of action, and then basically do what they did last time. I guess the thinking is something along the line of, if it worked last time, why should I change it.
They would only change the way they approached something if it didn’t work last time, despite whether it was the best solution or not. Basically people get used to doing something one way and only change their habits if something goes wrong. I’m sure there are many ways I could streamline how I work, but until something goes wrong, I’m happy muddling through.
Yet one more reason why I could never be a fire fighter. Many buildings would burn while I fought the urge to over-engineer a solution, certain that there must be some better way to put out a fire. I’m sure this must have come up in a career aptitude test somewhere in my youth.
There is something to be said for finding a reliable solution and using it as long as it continues to work. Consistency in any technical process is highly desirable. Learning to design a web site from scratch with each new project wouldn’t be a viable option.
However, it strikes me that we’re at a point right now where there is a lot of muddling related to the learning curve involved in working with web standards. There are plenty of good sites devoted to helping developers sort out the details and minimize the muddling, but we’re still a long way from having anything close to an acceptable set of best practices. Just look at the number of image replacement techniques we have to choose from.
Don’t get me wrong, a little muddling is probably a good thing. It’s in our nature. But there’s a point where you need to be able to critically evaluate your own methodology and consider new alternatives. Without this ability there’d be no progress.
Fantastic article. As I am just getting started in web design, I have by-passed most of the old-school methods of using tables for layout. I have been literally chucked in the deep end of XHTML and CSS.
However, I agree with your concern that most designers are muddling. I myself can see in my work (albeit they are small-ish sites) that I muddle in my code and process.
It seems that I tend to just play with the CSS until I get it looking right in both IE and Firefox (though perhaps that is more of a problem with IE than my code!). I also shy away from web tools like Dreamweaver. I tend to stay old-school and code by hand. Though perhaps that will change as I start to develop bigger sites.
Thanks for making me review my process though, it’s quite interesting from an industry perspective.
Great article. I think it’s natural to “muddle through” with almost anything in life though. The amount of hassle involved in doing everything the most efficient way every time outweighs the need to just get things done.