Redesigning: A Case Study in Several Parts

11 Aug 2006 5:00 PM | Deleted user
I’m the editor of, 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.

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, 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.

Copyright © Triangle User Experience Professionals Association

Powered by Wild Apricot Membership Software