JasonMorrison.net

I’ve been kicking around the idea of redesigning my homepage and blog, though I’m not sure I really have the free time to do it. To start, I thought I would to put down a few thoughts about applying usability principles when designing blogs.

When you starting thinking about usability it’s temping to jump right into lists of principles and rules of thumb. It’s a little silly applying Fitt’s Law when you haven’t even established what you want your site to accomplish in the first place. So what, generally, do you want your blog to do?

Personal Goals

• Share thoughts and work with others
• Collect a body of work to represent myself (like a portfolio)
• Collect information for later discovery (by myself and others)
• Provide an outlet to continue practice writing
• Allow others to communicate with me and comment

If you’re creating or redesigning a blog for a company, the goal set may be very different. Below are some examples that don’t actually apply in my case.

Business goals

• Communicate with customers
• Build long term relationships with customers
• Produce quality content to drive search traffic
• Generate revenue through advertising
• Etc.

Many projects don’t even get this far before the graphic designers and web developers are already making mock-ups, but we still have one more important step to do. We know why you’re building a blog, but why are users coming to it?

(more…)

The New York Times had a great article a few months ago about redesigning the font used on highway signs.  You’ve probably seen the current font, Highway Gothic, a million times without ever thinking about it – it’s been in use for more than 50 years.

Worrying about the font on the signs seems pretty silly compared to all the engineering and resources that go into a single bridge, let alone the entire highway system.  Why does this merit an article in the Times and what does this have to do with programing, web development, social software, or any of the topics many visitors to this blog are interested in?

Programmers and analysts sometimes doubt the value of design.  It’s hard work gathering all the requirements and writing all the code – we don’t have time to worry about how pretty it looks.  A lot of projects we work on, though, involve creating user interfaces, often web applications.  That means that, when it comes down to it, your job is to support the user’s tasks.

Now if someone wanted to add 10% to your hours to pick just the right shade of chartruse, you would be justifiably miffed.  But good interface designers will have good, empirically-tested reasons for their work and the guidelines they live by.  Highway signs are a great example of this kind of empirical benefit:

Intrigued by the early positive results, the researchers took the prototype out onto the test track. Drivers recruited from the nearby town of State College drove around the mock highway. From the back seat, Pietrucha and Garvey recorded at what distance the subjects could read a pair of highway signs, one printed in Highway Gothic and the other in Clearview. Researchers from 3M came up with the text, made-up names like Dorset and Conyer ? words that were easy to read. In nighttime tests, Clearview showed a 16 percent improvement in recognition over Highway Gothic, meaning drivers traveling at 60 miles per hour would have an extra one to two seconds to make a decision.

A one or two second gain in legibility matters a lot when your life depends on it.  Few web applications present the same kind of physical danger, but multiply a small gain over an application with 10,000 users, operating 24 hours a day for a year, and you can see how this can impact the business.  Good design is part of the larger concept of usability.  As anyone who’s done any usability testing can tell you, most applications have many small, easy-to-change pitfalls that can quickly add up to huge wastes of time and effort.

When I was a kid, computers were slow. They had little or no storage, the most reliable connection was sneakernet, and having more than four colors on the screen at the same time was amazing. So the user experience looked a lot like this…

For quite some time now we really haven’t had those same excuses, so why does this video remind you of the point-of-sale system at work, or the database HR is still using, or the software that came with your MP3 player?

Abstract

Diet can have a great effect on health, but few people keep track of what they eat each day, let alone how much fat, protein, Calcium, or other nutrients. Although most food items have nutrition information printed on the packaging, few people can tell you whether or not the 10 grams of fat in their candy bar is acceptable, or whether it has put them over the edge.

In this project the author assumes that a big part of the reason people do not keep track of their diet is that there is no easy way to do so. The final product of this project is Mealographer, a simple interface that allows users to enter in the foods and meals they eat each day, set simple nutrition goals, and see reports of their progress. Mealographer was created by implementing a large number of improvements to the product of a previous investigation, WhatYouEat. A usability test was conducted to evaluate Mealographer and find specific usability problems.

Previous Work – The WhatYouEat Project

Mealographer inherits much of its functionality from a previous project, titled WhatYouEat, part of an individual investigation from fall, 2005. The original project had two goals: to create an application that allows users to track their dietary intake, and to make the application as easy to use as possible.

WhatYouEat allowed users to record their meals, set simple goals for different nutrients, and

track their diet through simple reports. Supporting functionality included a simple user sign up and login system, and systems allowing users to indicate favorite foods and “usuals” – foods eaten on a regular basis.

WhatYouEat was demonstrated informally to several groups and an informal usability test was run with four participants. Although this style of evaluation was not rigorous, users were asked to use the site and comment on any confusion or difficulties. Many users also commented on design and additional functionality. Usability issues included difficulty in:

Targeting

• Even with a large screen size and large font, it was hard for one subject to click on fields before entering text.
• Field labels were used to enlarge the clickable area. It may be possible to have the cursor will default to the first field.

Layout

• Two users were a little confused about the two-column layout of input forms.
• A thin line was added to help make the grid more clear.

Forms

• Three users forgot to set the meal date at least once. The submit button was easy to miss. One user hit enter to submit the search form and didn’t expect the entire meal to be submitted. There were problems using the back button.
• The submit button was made more visible
• The forms were be broken up so that the submit button for a particular field only submits that field.
• Required fields could be made more clear with a symbol and some JavaScript.

Labeling

• Some labels were unclear or hard to read. In particular, dates presented in yyyy-mm-dd format and names of nutrients.
• The labels should be changed to reflect user expectations.

Measurements

• Many users had a hard time determining how much they had eaten, or understanding how much food each measurement amount actually represented. Few of them knew what an ounce or gram of a given food looked like, or how much of non-fluid items made up a cup.
• Some graphic representation of food amounts should be available in the system, as well as a conversion application. See Future Plans for more information on the approach to this problem.

Missing items

• Users more than once looked for food items that did not appear to be in the database at all. This included brand-name items or items from specific restaurants. This is a limitation for the USDA database.
• There is no simple or quick solution to this problem. See Future Plans for more information on the approach to this problem.

(more…)

Note: This was originally created for an information architecture class – the project was to redesign the Kent State School of Library Science web site. You can also see a usability study of the site.

Executive Summary

The current Kent State University School of Library Science (SLIS) does not meet the needs of the department. This project outlines a plan and strategy for designing a new site. The new site will better communicate the department’s image and core attributes to the outside world and better meet the needs of users. This report covers the entire process, from research and project goals, through the development of a new design and how to measure success. Major recommendations include the use of a simple content management system (CMS), a new navigation structure and graphic design, and a few new content elements such as news, video, and podcasts.

Introduction

This report will cover the overall strategy for the redesign of the Kent State University SLIS web site, including the site’s audiences, the vision for the site, and analysis of the content and maintenance. Finally, recommendation are made for the content, information architecture, and design of the new site. The ultimate goal of this project is to create a coherent analysis and plan for the SLIS department to execute. The result will be a site that better projects the image of the department, better serves the users, and, if possible, makes the staff’s job a little bit easier.

Site content has been updated, but the organization and design of the site has been the same since 2000. The web has changed a great deal in the last 5 years, and the Kent SLIS site look and feel is not exactly cutting edge. The faculty and staff have voiced a desire to update the site, and there is anecdotal evidence that at least some students find the site lacking. Any new design must better address the needs of the site’s audiences and should better project the image of the department to the outside world. Also, the process used to update the current site is slow and unwieldy. The new site will solve three main problems: poor ease of use, an image that does not fit the department, and difficulty updating the site and communicating with users.

The process followed in creating this report has included requirements-gathering meetings with SLIS faculty and staff, content analysis of the current site, analysis of server logs, brainstorming sessions with Information Architecture Knowledge Management (IAKM) students, analysis of similar sites, academic usability research, the creation of persona, card sorting exercises, wireframing, prototyping and other techniques. The report will recommend additional steps such as formal usability testing be taken as well.

(more…)

I’ve done a lot of small freelance web development projects and I find myself explaining my approach to non-technical managers, small business owners, and other decision makers again and again.  Here’s my attempt to write a more general document with a business perspective on web design.

Website design doesn’t just mean graphic design applied to a website.  There’s a lot of work that should go into the project before anyone starts designing anything, and I think a lot of companies and web designers skip these steps and end up with yet another site that does nothing for the company.

The first thing you’re going to want to do is determine your business goals for the site and your various user populations and their goals.  At this point you’re just brainstorming; later, we’ll figure out which goals are more important, which are most cost-effective, and figure out how your goals coincide with your users’ goals.

So let’s say, for example, that you have the following goals and user groups with their own motivations:

Business Goals:

• Sign up new customers
• Sign up new advertisers
• Keep current customers
• Reduce time/effort spent handling incoming files
• Reduce time/effort spent handling ads
• Communicate with customers
• Sell additional services
• Sell branded physical products
• Reduce time spent on tech support

User groups/goals:
Current customers

• Send in files for processing
• Get help
• Use your products to communicate with their customers
• Have a web presence of their own
• Improve their own business

Current advertisers

• Send in material for ads
• Make payments/view account status

Prospective customers

• Find an affordable way to get their products produced
• Help support their organization
• Figure out which company to go with

Prospective advertisers

• Find cost effective way to get more business
• Figure out best place to advertise

As you can see, your goals do not exactly match up with your users’ goals, but there are many places where they overlap.  For example, your current customers want to send in their files, and you want to reduce time and effort handling incoming files and in tech support.  So that means the site should allow customers to send in their files as quickly and easily as possible.

In general, my rule is to look at the customers’ goals first, then match the business goals to them.  If you end up with business goals that do no fall under any of your users’ goals in the end, you need to think about how you will market this goal to users or attract user groups that share that goal.  For an (exaggerated) example, one of your business goals might be to sell an old backup generator.  Right now that meets none of your users’ goals, so unless you attract different users you won’t be any more likely to meet your goal than blind luck.

The next step is to prioritize and quantify these goals.  So perhaps we decide that we are going to get most new customers through face-to-face meetings with marketing reps and not through the web site.  That means we can bump up all the goals relating to current customers to the top of the list.  Or maybe attracting new advertisers is much more important than letting current advertisers pay online.  So we bump “sign up new advertisers” up the list.

In order to quantify the goals, we’ll need to establish some measures and current values for them.  So, for example, we want to quantify the “reduce tech support” goal.  How can we measure this?  Well, one measure is the number of people in tech support.  This is a bad measure, though, and a common mistake–if laying people off is your goal, that means you can make create a poor website and still lay people off and meet your goal.  Some better measures would be time spent per call, number of calls per customer, etc.  That way your employees can be more efficient and handle more customers or provide better quality help.  Also, always look at this from the customer’s point of view–why not measure how happy customers are with tech support overall, how happy they are with the help available (or not available) on the site, how likely they would be to use the site if they knew help was there, etc.

Once you have current figures for these measures, you’ll be able to tell if the site has really improved.  Once we know our customers’ goals and how our business goals match them, and we have figured out measures for each, we can start planning how to meet them.

This was just an illustration, but this is the kind of process that separates successful web sites from mediocre ones.  Keep in mind that this is just the first step toward a successful project, there’s still project management (planning the steps out and tracking milestones), picking the right technologies, designing the information architecture, testing usability, etc.

It’s a good idea to put together reports on each of these stages.  This is something a lot of web designers and companies don’t usually do, but I think it’s important for a project this size.  It keeps you aware of what’s going on, and eliminates duplicate work in the future.