Your group has spent six months toiling over a great new Drupal website with responsive, mobile-enabled design. It’s fully synced with your social media — Facebook, Twitter, and Instagram. You even scored a grant to implement accessibility best practices. Now, finally, it’s time to bring your user community on board.
But wait. Not so… slow. Many of us sense intuitively that delaying until the launch date is too late to bring our user community’s perspectives into a new web project. But as grassroots groups, often without dedicated staff or funding to implement IT buzzwords like UX design, usability, or user prototyping, it can be difficult to facilitate a truly user-driven design process. Thankfully, there are simple strategies out there, many of which are outlined in Ginny Redish’s how-to web communications guide Letting Go of the Word: Writing Web Content that Works. In her second chapter, “People! People! People,!” Redish outlines a few basic steps (distilled further here) for putting your user community (“People!”) at the center of your web content design process:
- Gather real-life data. Talk to or survey your community at the onset of your project planning. Understand their backgrounds, their knowledge of your group’s focus or mission, their web literacies, and their wants from your website or project. Don’t just aim for checkbox data — get real-life quotes.
- Develop personas. Don’t create for lifeless demographics. Instead, develop a handful of personas that bring life to the user groups you identify in step one. Your personas should have names, photographs, real-life voices (quotes from step one), and scripted backgrounds so that, as you begin to prototype your project, they can help humanize your decisions — i.e., “Why would Sandra care about our archived board notes? Can we move them elsewhere, or make them searchable?”
- Design for scenarios. Scenarios are the real-life situations bringing your personas to your website or project. Design your web content for the top scenarios you can identify and, if needed, cut everything else. Redish offers a hard-and-fast guideline here: If you can’t identify a key scenario for using a piece of web content or feature, leave it out.
Redish’s simple steps don’t require a budget, making them especially useful for the grassroots. And they can be complemented with more formal IT design practices like wireframing or usability testing.
Has your group adopted similar design practices? What was the outcome? I’d love to hear others’ experiences.
Redish, Janice (Ginny), Letting Go of the Words: Writing Web Content that Works (New York: Elsevier, 2007).
Brazen Words 