Published in Contingency Design on Friday, July 9th, 2004
Ramblings about clients, contingency design and thinking like a user. A few thoughts on the topic.
Keith over at Asterisk, and Jason at 37signals, both recently posted about their efforts at trying to get stuff done on the web.
While Jason outlines an example of good contingency design, Keith provides what amounts to a list of things that we should keep in mind when designing sites. In his list, he says the following:
Saw a whole crap-load of poorly designed, poorly written and even more poorly functioning Web sites that someone out there probably expects works just fine.
It's interesting, and a bit scary, to think about the validity of that comment. Of course a lot of the insufficiencies can come down to economics.
Sitting down with a client last week to go over some extra work, they were surprised to hear how long it would take to add a 'simple form' that would allow users to submit job applications to the company.
After explaining the finer details of things, they were left surprised at how much work it actually takes to do it right. The fact is, there are many little details that need to be handled when user interaction is concerned, and many people don't take that into account.
I wonder how many designers and clients would be surprised at the holes people can find in their websites?
Derek Featherstone's recent post, The Case of the Missing Defensive Design, is a great view into a couple of problems (and the mind of a user), one of which has been mentioned before over at Stopdesign and Daring Fireball.
Besides the obvious 'defensive design' shortcoming, Derek's example shows how, as users get more and more 'savvy', they're becoming more prone to getting themselves lost, so to speak.
The classic example is of someone blogging about a topic or product, only later to find people landing on the blog post and posting comments where they clearly think that they are on the business site of said topic or product.
It's easy to talk about contingency design and 'thinking like a user', but ultimately the designer has to do the work (details can be time consuming!) and the client has to pay for it. So, sell good contingency design to your client first.
If you can't sell then on contingency design at first, build something that is worth what the client is paying for, and then do your homework.
Paying close attention to the site's log files, look for signs of possible trouble happening. Go back and outline it to the client and give them a quote for the work. Return on investment is important to your client, so is abandonment; your client does not want to lose a potential client because they got lost on the company website.
A great method for dealing with all of this is real live user testing, but this may not be in the budget for most clients.
Easier said than done, an alternative is to spend more time 'thinking like a user'; try doing crazy unimaginable stuff with your site. Have an applicable error page for every path on your site. Plug the holes.
Again, keeping a careful eye on your log files can help to gives clues to find failures that may have been missed.
When it comes to contingency design, think beyond your form and website. Think of a first class shopping experience. How would you expect to be treated? Apply that treatment to your site. Innovate.
In the end none of this is any good if the client is not on board. While some of our clients see the value up front, many respond better to a follow up similar to what was outlined above: watch the logs, find the holes, propose solutions. Build better user experience!
Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:
I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.
The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.
Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..
Comments and Feedback
Excellent - from that last link to Keith:
"If you think marketing goals and users goals can’t live together in harmony, you’re not thinking hard enough."
I've now printed that out in 72pt and stuck it on the side of my monitor, ready for the next time our Marketing Dept want 25% of the homepage for one ad. :)
Nice ;-]
It's good to see other people thinking and talking about this stuff. I honestly believe that by thinking about people and trying our best to make the design decisions (defensive or otherwise) that best help our users meet their goals we become better at what we do and bring more value to our projects.
I know it can be hard. Usability is a hard sell and the effort it takes to do something right is costly, both in time and money. But it's worth it.
I often talk to people, usually freelance designers and agency folks, who have a problem injecting this stuff into their process as it's a hard sell. I tell them to get creative and at least try to do something. If nothing else it will help them be a better designer in the end.
Once a designer has seen a few users they begin to see patterns in user behavior. Many designers make assumptions on how a user is going to interact with a site anyway so regardless of the other benefits (of which there are many) -- it just makes sense, as a designer, to better understand how people use things.
Seems pretty simple to me. Spend that $50 bucks that was going to go to the latest Flash book on a cafe test for one of your sites. It'll be worth it in professional development alone! And it'll take less time to get through...
;0)
Good advice, Keith. I have to admit, the more stuff (little contingency design ideas, user ideas etc.) that I learn, the easier they become to implement. Many of them are now 'standard' in our CMS.
The Cafe test is a neat idea. Trouble is that out here, the people in the cafe's are, for the most part, oblivious to the internet!
*raises hand* Can you tell me where to find some clients that wouldn't mind waiting long for their site and spending more money to have it done right versus quickly? Because I would really like to know. I really wish there were alot of clients out there that would say, "Here is 80 grand, build us a great website and test the hell out of it. Make sure it works for as many people as possible", Instead, you get the client wanting to give you 6 grand for a 30 page site and by the time you are done building it out, making sure it works in most browsers, etc... you don't really leave yourself with enough time/budget to do alot of user testing or patch up any security holes an application may have because the client "WANTS IT RIGHT NOW!". Too many clients are in a rush and will take what they can get. just my 2 cents, but good posting...
I hear you Bryan. Heh, we're lucky to get 6g's here in our market!
We have found that, depending on the site, some clients are more than willing to look at contingency issues after they have a quick site up.
Collecting stats and data for problems (or to discover problems) or to help to get a better understanding of the sites users can give you something to go back to the client with; we've landed two very nice maintenance contracts this way, both of them worth more than the respective sites were worth. (Be sure that the client is aware that they aren't getting the full bag with the first site though, or you end up looking bad!)
With respect to full cross browser, have a stroll thru the Vault and you will see a lot of sites that don't qualify as 'fully cross browser happy. Many designers acknowledge yet ignore some of Opera's bugs, and I know that we don't fully support IE5 Mac in most of our sites.