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.