Category — Web Development

All websites are supposed to be easy to use. They have to be. If your website isn’t, then your visitors will bail and find a website that is. But how in the world do you sure your website has ease of use?

My answer came after a good bit of trial and error is to use Joint Application Design workshops for website design. Then follow that up with some simple usability testing.

But most websites groups don’t really do too much to improve the designs of their websites. Heck, most folks don’t even use usability testing on websites to see if they are easy to use or not. And I can see why. When I worked on ACT! at Symantec we did a lot of usability testing and I have to admit it didn’t work that well.

Our usability testing went something like this: We would work really hard to get the application features complete and get rid of the bugs that made the usability testing impossible. Then we would hunker down in our high dollar usability lab and pump 15 to 20 people through the testing process over about 2 weeks. We would then pull some test ‘results’ together.

There were two big of problem with this approach. We didn’t have a great idea of what to test before hand so we ended up with a big glob of anecdotal comments about the app – not actionable “this is wrong” sort of feedback. And the feedback came so late in the project we couldn’t really act on the results - we had to wait and integrate that test results into the NEXT release.

To make usability testing really work for us we needed usability feedback before we even got the application complete so we had time to fix the problem. And the feedback needed to be formatted into a “fix this problem” sort of statements. It would have been good if the testing could be a little less intense and time consuming as well.

These experiences led me to a big dilemma when I saw the really bad user interfaces coming out of the first few website projects I managed. It was clear that “Big Usability Testing” – big as in big test lab, big group of folks being testing, big glob of results at the end – just wasn’t going to work on websites either. Yet something had to be done to improve the usability of the websites we were making.

Without a lot of great ideas of how to improve usability on websites, I adapted a couple of application development ideas to website development: Joint Application Design (JAD) workshops to improve a website usability design and beta testing to test the website design’s effectiveness.

I ran across the JAD technique when I was doing client server development for a bit right after I left Symantec. JAD is an “interactive systems design concept involving discussion groups in a workshop setting” normally used as a requirements gathering exercise using a cross section of technical and business participants.

I saw it really work well for requirements gathering and some light application design. So it seemed to make sense to apply the workshop setting and cross-functional participants to the entire user interface design process as well.

The JAD workshop applied to website design worked something like this:

• Create a list of the features that the website needs to do
• Get 5-8 folks with differing backgrounds and viewpoints into a conference room
• Conduct a workshop to create a wire frame website on a white board.
• Turn the white board wire frame into HTML with some text added for things you can’t explain in the wire frame.

I tried using the JAD technique for the website design of a pretty simple site with a consulting client. After reviewing the HTML wire frame from the results of our JAD workshop with client management, we did a follow-up JAD workshop to address the issues they brought up.

Once we had the final wire frame assembled, low and behold, we had created a much more usable website design than any one person could have done individually.

For usability testing, we adapted “Beta testing” like I had seen done at Symantec on ACT! to website development. It was really easy to implement beta testing – once the website was stable enough to use without crashing we posted a version of the website out for review by some external partners.

The good news is that we got some feedback from folks outside the project. But the feedback we got wasn’t focused. It was at the “tweak this and tweak that” level and not the in-depth feedback we needed. The results were still too late in the development process to act upon without holding up the website release.

After the first experiment of how to improve website usability, I found that the JAD workshops really, really improved website usability. But beta testing didn’t give us any better feedback than Big Usability Testing even though it was a lot easier to pull off.

Fast-forward several years. I found great results using UI JAD workshops to design websites in a variety of settings – consulting and for internal customers. But still no improvement on testing the UI that was developed during the process.

Then I got to reading this really great book, Don’t Make Me Think by Steve Krug. Krug describes a really stripped down version of Big Usability Testing that was specially tailored for websites. The process it described took almost all of the practices of Big Usability Testing, simplified them and moved testing earlier into the development process.

Krug doesn’t really name this stripped down website usability testing, so for lack of a better term, let’s call it “simple usability testing.” Here is a summary practices of Big Usability Testing, the thorny issues they cause and a set of simplified practice Krug recommends instead.

This sort of process made so much sense that I had to try it out. Using a little project that I was working on, I did some simple usability testing after the design was done and guess what? Worked great. I had a couple of those usability testing magic moments where things I had never thought about came to light. It was brilliant.

So to boil that all down, I have had great results iteratively doing Joint application design to improve the initial UI design usability and then applying “simple usability testing” from Krug’s “Don’t make me think” book to assure that the design is good. It’s not particularly difficult to do and the results are really good. Let’s walk through the steps of how to do these two processes together.

Steps to improve your website’s usability

1. Assemble a set of features – Before you start designing anything you really need a list of features that the website is going to implement. Without a well-defined list of features your design team just isn’t going to know what to design.
2. Pick a cross-functional design group – To get a really good design you need the right folks to get in there and make the design workshop happen. Ideally, you would have at least two business non-technical folks, a web producer/HTML person, a senior developer, and the project manager. You want a good cross section of viewpoints and interests in your design workshops. And the folks you select should be flexible and easy to work with.
3. Set up the JAD workshop - Get a conference room with a lot of whiteboards, reserve it for the whole day and get cracking. If this is the first time through the process it may make sense to show up with a first draft wire frame to kick things off. Ideally the person that will be “approving” the UI design should be participating. If folks can’t stay for the whole time, don’t include them. Don’t allow cell phone/crackberries/laptops.
4. Conduct the JAD workshop - Spend a couple of hours to an entire day creating or revising a wire frame on a white board. Hopefully you can moderate this yourself. All participants should have an equal say in the design. Look for consensus in the design but don’t force it. It’s not critical to get down to one design but it will be great if that happens. But do make sure that your website design guidelines will allow what you are designing… it makes no sense to make a design that can’t be implemented on your website.
5. Develop a wire frame – Using the notes and white board drawing get your web producer to create a wire frame UI in HTML. In cases where it is not clear what should happen on a page then add some text descriptions or call outs. For instance, if there should be some AJAX functionality happening on a page don’t get bogged down in developing it now. Describe what the functionality should do in a note on the page someplace.
6. Iterate – Do steps 3 to 5 again to improve your design at least once. At a minimum you should have at least 2 JAD workshops with the same set of people.
7. Make a usability test script – Before you can start testing you need to make a script that will walk the user through each specific task you want to evaluate. You don’t have to start from scratch on this – Steve Krug’s website has a really good great starter script. http://www.sensible.com/Downloads/script.doc
8. Find a testing location and equipment – All you need to test is a conference room or, heaven forbid, a quiet cube someplace. You will want to videotape each testing session so bring your video camera and tripod from home.
9. Conduct the testing – Line up 3 – 8 people to test. Bring them in. Walk them through the script. Make sure and pay them $50-100 in cash as they leave. It’s great if they are in your exact website demographic target but it’s not as critical as you might think.
10. Review results – While reviewing the testing make two lists: one for general issues that came up during the sessions and one for problems specific to the new things you are testing. Prioritize the issues to fix and possible solutions if they pop up. In an ideal world, the same design group you used during your JAD workshop would review the testing videos.
11. Redesign as needed – Do another JAD workshop to address the issues brought up in usability testing. Look to solve the high priority problems specific to the new functionality you are developing and any of the general problems that can be fixed. It’s convenient but often challenging to review the results and redesign based on the results in the same session.
12. Redevelop – Now get in there and rework the wire frame based on the JAD workshop results.
13. Iterate – Do steps 7 to 12 again so that your team will do at least two rounds of usability test and redesign.
14. Start development – Once you start usability testing, I would try to start involving more application folks in the design process or at least giving them access to the wire frames as they come out. The idea is to jump-start the lower level business logic and database design processes using the wire frame to stimulate the discussion.

I’d try to use 2 JAD workshops and 2 rounds of usability testing, like I have document in the process now, for large chunks of functionality or content. The entire process could take as little two weeks if folks can be dedicated or mostly dedicated and could take a month and a half if folks are not dedicated. It will probably take at least a month the first time through.

For smaller project cut the number of JAD workshops and usability testing iterations down from there as you see fit.

Summing up - Get Great Website Usability Using Joint Application Design and Simple Usability Testing

Using a Joint Application Design workshop for your website’s user interface and the using simply usability testing as outlined in Krug’s excellent book “Don’t make me think” is really going to improve your site’s usability. And without a huge change to the development process you have in place now. If you really want to get it all together then try combining this approach to website usability with time boxing, MoSCoW prioritization and iterative development. Give it a try and let me know how it works.

Joint Application Design Resources

Great summary of the problems JAD looks to solve and how.

Great summary of the wireframe process.

Usability Testing Resources

The man himself, Steve Krug, has a great site on website usability.

The best resource on website usability has got to be Jakob Nielson’s website.

Some folks swear by their homegrown content management system. Others like their open source content management system (CMS). Still others have gone all out and purchased a big package to solve the giant content management problem they have.

And that makes sense. There isn’t just one solution that works for every site and every organization. There is too much diversity in what folks want out of their content management system and processes.

Regardless of how you solve your content management problem, I do think there is a sweet spot of just enough CMS. A place where you get ease of use and the efficiency promised by content management systems. But not so much that your team loses its creativity, agility and control.

So what sort of features should you implement with your CMS to get into that sweet spot? Here is my take:

Use site-wide themes

To get the most value from your CMS, use its theme capability and make sure that you can globally change the look and feel of your website by changing a few template files. By template files, I mean something similar to themes in WordPress or a skin in DotNetNuke. You also want a globally included well-designed CSS so that you can make small styling changes without radically changing your content. If you are in roll-your-own mode you can still accomplish theme-like feature for your CMS without a ton of development work. We implemented a theme-like feature at NetIQ/Webtrends (we called it a page framework) and it worked really well.

Optimize for the list-view pattern

Tons of the content on websites is in a list-view pattern. Press releases are a great example of this pattern. Almost all sites have a list of press releases which link to individual press release views. Anytime there is a list of links – product data sheets, events, FAQ, knowledge base articles, sales offices for instance– and each of the links goes to content items of the same type you have content in a list-view pattern.

Because this pattern is so common, making a common authoring, storage and display system for this pattern can save your team tons of time. To take full advantage of the list-view pattern, make sure your CMS can:

• Create new “types” of content – Say you already store FAQ and product data sheets in your CMS. And tomorrow you find out that you need to store many “tutorial video clips” for download… Each tutorial video clip will have a title, one or more video clip files, tags and of course any text/html for the download page itself. You want to simply create a new content type in your CMS called “tutorial video clips” and start up loading them.
• Author all the types of content with a single authoring application – you want to be able to create press releases, events to go on a calendar or store “tutorial video clips” using a common set of tools in a single authoring application. This saves tons of time by not having to create custom admin interfaces for each type of content that your system will need to store.
• Ability to control the content displayed in a list – Say you want to list just 5 “tutorial video clips” for a product sorted by date. To support this sort of requirement, which is sure to come, you will need to be able to query the content database and get a list of links that have a limited number of entries, filtered by tag (in this case the product), and sorted by any field.
• Associate a view template to a type of content – Each type of content will need its own list formatting and view formatting. Press releases, “tutorial video clips” and FAQ lists and views are all going to look different, right? You need an association between a content type and a set of list-view templates, which described how the content should be formatted. Using this association you can make press release look like a press release and set of calendar events can be formatted on a calendar.

Authoring content in a web page

You want everyone to be able to author content and the ability to do it using an editor in a web page is super cool. With significant ease of use and accessibility using XHTML / AJAX based editors like FCK editor, your entire team can participate in the content creation fun. The ability to apply basic CSS styles even makes styling content easy and consistent. The only down side is that training will be required for your content creators to make sure your site ends up with well-constructed and well-edited content.

Don’t write the copy

I have seen some web shops where the web producers write the copy that goes on the website. Not a good idea. The business owner of the copy should be the person that gets the copy written. Ideally, they will get a professional copywriter to write it or, heaven forbid, do it themselves.

Limit content approval steps

Lots of big sites have very sophisticated content approval processes. But this isn’t where you get good value out of a CMS - keep your approval process basic with a single signoff from the business owner for the content. If there is legal or some other approval needed to get content on the site, then get the content’s business owner to solve that problem himself or herself. Don’t let your overachieving legal departments or micromanaging executives complicate what should be a simple straightforward process.

Use staging & publishing

Tons of sites develop, review and approve content on the live website and don’t use a QA server. But working on a live site for major changes in content or even small look and feel changes is like doing a high wire act without a net. Screw up one thing and your site is down until you can somehow patch it back together again. Ideally your CMS setup has the idea of a QA server, a staging server and a robust publishing process that gets the content out to the site. I find the lack of staging and publishing features a significant omission in popular open source system (hello WordPress) and amazingly, higher cost commercial software, too.

Make version control transparent

It sucks to lose work. There is nothing worse than saying to your boss “it was all done but someone overwrote the changes and we can’t get them back.” So naturally I recommend that your CMS should support file versioning, locking and rollback. It should take very little effort from your content authors to use version control with your CMS – version control should be completely transparent to the user and only announce its presence when there is a problem.

Exploit Plug-ins

Your website isn’t just content. It’s going to include some features that have become standard website fair like mapping, blogs, forums and dozens of other smaller items. If you do have the option of getting some of this functionality for “free” using a CMS plug-in and the plug-in fits your requirements, then just plug it in and be done.

Implement a well-known stack

The ability to add custom functionality to your CMS and support it is vitally important to the long term viability of your website. But there are still closed content management systems out there or systems so difficult to work with they might as well be closed. Make sure your CMS is LAMP, Java or .net and uses a well know SQL database if you want to make things work long term.

What not to do with CMS

There are also a few things that are NOT in the sweet spot of CMS. These features are harder to implement, keep running and don’t add a ton of value. Features not in the sweet spot of CMS are:
1. Lots of authoring/publishing roles – You shouldn’t need to have more than 5 or 6 standard roles in your CMS setup. Adding a lot of roles makes things more complex than they need to be.
2. Multi-level content approval – Multi level approvals don’t make sense in most cases. Use a single level approval process for content.
3. Single sign-on/LDAP – If directory services and single sign-on come for “free” with your CMS package or it’s less than a couple of days, then this integration makes sense. Weeks/months spent on directory services integration doesn’t.
4. User level access permission – Assigning user access rights to content at the user level never makes sense. Assigning user access rights at the group level does.
5. Excessive security (firewall rules and encrypted sessions) – It’s not such a big thing to have your unpublished content zipping around on the Internet in clear text. The snappy performance of unencrypted HTTP is more important than security in my book.
6. Site rollback features – I have never understood the need to roll back the site to a particular point in the past or seen it work. Punt on this feature.

Summing up the content management system sweet spot

That’s my view on getting the most bang from your buck when you implement CMS for your medium to large corporate websites. If you can combine these features with some basic solid processes then you are well on your way to website content management done right. The sweet spot isn’t elusive if you work through these issues carefully. Give it a try and let me know how it goes.