Research on the Quick

By Michael Gowan

Continuing a series of posts on redesigning a section of a Web site (see first post).

Since we’re talking about user-centered design, getting user input into a project at the beginning seems pretty important. But conducting interviews at the beginning of a project is often the first stepped dropped when deadlines get crunched.

On this project, I had planned to run an online survey and conduct follow up interviews with some respondents. But after entering that into my project schedule I ended up with a January 2007 launch date. That wasn’t going to fly — I needed to have an outlet for new content no later than November 2006.

So I looked for other forms of user input that I already had on hand. Sacrilege, perhaps, for the readers of this blog. But with a little effort, I found enough to provide a user voice in defining the requirements.

First I looked at previous research that we had performed. Earlier this year we conducted some pretty extensive focus group and user testing work around what existing patients and prospective patients wanted from our site. A portion of this testing was dedicated to the health library. Bingo.

We’d conducted user testing during our Service section redesign that covered, indirectly, user needs in the health library. We had found how users interacted with the library when seeking information about treatments. It was enough to piece together a user task.

I also turned to the Web for other published research. The Pew Internet & American Life project has some specific health related research that provided high-level user needs. Paired with our own existing research, I started to get a good picture of what our users would want.

Other sources of external research included Jupiter and Forrester.

What quick methods have you used for getting user input before writing requirements? Post in the comments section to let me know.

Redesigning: A Case Study in Several Parts

I’m the editor of DukeHealth.org, Duke University Health System’s patient Web site. I thought I’d post a series of entries that follow our progress of redesigning a section on our site, detailing decisions made along the way and hopefully getting suggestions from all of you as to how we can make it better.

We’ve decided that our health library has to go. Or, more precisely, it needs to be wiped out and rebuilt from the ground up. Better, faster, stronger.

Piece by piece we’ve improved our site over the last year, creating more flexible designs that are attuned to user needs. We began with a new services template that we’re rolling out to all areas in that section, along with an A to Z index. Then we revamped the locations section.

Now it’s time for the educational materials.

Processing

My first step is deciding on the process to follow. We had success with this approach on a previous project:

1. Content inventory
2. Analyze existing research — internal and external
3. User and business requirements
4. Wireframes
5. Content gathering
6. Prototype
7. User testing
8. Revisions
9. Content editing
10. Visual design
11. Development
12. QA
13. Go live

I’m always looking for a better way. A search led me to Usability.gov, which has a fairly develop user-centered design process laid out. Has anyone had success following that method?

In a project post mortem we determined that a missing step was touchpoints — links in and out of the existing section.

The user impact is fairly significant, since missing this step could have resulted in broken links all over the place. We skirted that issue by keeping all the old pages live until we can fix the links.

But now users are getting two different locations experiences, old and new, and that’s not good, especially since the old way sucked.

So with the touchpoints step added we got:

1. Content inventory
2. Touchpoints
3. Analyze existing research–internal and external
4. User and business requirements
5. Wireframes
6. Content gathering
7. Prototype
8. User testing
9. Revisions
10. Content editing
11. Visual design
12. Development
13. QA
14. Go live

I wasn’t sure I placed the touchpoint stage in the right order. It could come later. It may be best to have it near the end so we understand all the links out. Should I split touchpoints in two: links in and links out? I kept playing with the pieces and remembering steps I was leaving out.

And several hours and a few charts later, I ended up with this:

1. Content inventory
2. Touchpoints
3. Research analysis
4. User interviews
5. Business interview
6. User and business requirements
7. Review
8. Wireframes
9. Review
10. Content gathering
11. Prototype
12. User testing
13. Revisions
14. Content editing
15. Visual design
16. Review
17. Finalize all documents
18. Development
19. QA
20. Go live
21. User testing
22. Iterate

Going through this exercise made me realize this: Without a clearly defined process before you begin, the project will fail users.

When you’re straying without purpose, the project ends up catering to the whims of what’s convenient and what the business wants.

And if you don’t plan for user inputs throughout the project, you can be sure the user needs won’t be taken into account when timelines get crunched.

I’m sure most of you can relate.

In my next post I’ll discuss our research analysis and user interviews.