ss120509-bd01.jpgIf your latest Web CMS project is total disaster, you should definitely blame the users.

These careless people probably weren't there to inform your closed door meetings and they probably never did a proper review of your requirements and design specs. The nerve of them -- going about their daily lives simply ignoring your need to develop relevant user stories and process flows.

If only they knew what you know about how things should work, everything would be just fine.

I'm poking some fun, of course.

Speaking at CMS Expo today here in Chicago, Daniel Mittleman of DePaul University says most Web CMS implementation books and trainings leave out the most important element of project planning: your users. Given this he fears that there's a widespread problem in the industry where too many of us get focused on the the tech and forget the business of addressing the needs and problems our users are facing.

Folks like Gerry McGovern -- who has written volumes on putting customers first -- are not guilty of such things. And most CMSWire readers are familiar with the rather trendy customer experience mantra: winners prioritize customer experience and build fast feedback loops to continually optimize it.

Nevertheless, a reminder about putting users out front, and more importantly how to do this from a process perspective is always a good thing.

Users At the Head of the Table, Please

Daniel asserts that users and UX have not had their proper place in the CMS project cycle and that a user-centric planning process is key to a successful Web CMS implementation. He spent an hour today running through the process of putting users first.

Note: The discussion moved fast, as does this article. If these topics are new to you, additional research will be required -- we've included some links for additional reading.

1) Begin with Problems

Mittleman, with a background in architecture (as in buildings not software) says his training was to always approach a project by clearly defining the problem space before attempting to come up with any sort of solutions. In the world of content management this means shining the light on content, user experience, interactions and stories.

Define problems in their most specific and complete form, he says. When in doubt be detailed to a fault. Understand your problems, make them broadly understood by the team and make the solution testable.

2) Get Intimate with Users

Know your self and your business goals, but know your users better. Intimate knowledge of your users is the key to success, says Mittleman.  

Start with categorization of users by considering demographics like age, experience, sex; technographics like platforms, devices and skills; and psychographics like behaviors, emotional states and attitudes.

Mittleman encourages the audience to formalize and encapsulate the user knowledge gained via the development of personas. Personas -- a feisty topic on its own -- are fictional characters that summarize each of your key target user groups. They are vessels for your knowledge about each category of user.

An example persona might contain a photo, a "key feature", job title, geographical location, responsibilities, and trigger actions.

3) Interview Your Users

Once personas have been constructed, you must validate them.

Discover your users' realities via interviews, surveys, and casual conversations. Proceed to use focus groups, mood sessions and card sort sessions.

4) Write (Useful) Stories

Mittleman says carrying forward from persona development the next step is the development of clearly documented user stories.

These are similar to use cases, but have a different structure and are more narrative. If you're familiar with agile software development methods like Scrum, then UX user stories are essentially the same thing.

UX consultant, Basheera Khan, recently wrote this helpful tidbit:

User stories, when correctly written, serve as a very visual reminder that whatever you’re working on, with any luck you’re doing it to improve someone else’s life.

The goal, according to Mittleman, is to collect as many user stories as possible, validate them and then prioritize them. 

Stories start with simple phrases that identify the persona, the function and the outcome. They put the voice of the persona out front. For example: "As a frustrated Jane, I want to quickly find the latest software driver, so that I can make my printer work." 

The test of a user story is summarized by the INVEST acronym. The INVEST test comes from the agile development world and stands for:

  • Independent -- is the story independent of other stories?
  • Negotiable -- is the implementation of the story something that can be discussed between business and tech, for example? It should focus on the essence, not the details of the scenario.
  • Valuable -- is the story aligned with the mission and valuable to the persona?
  • Estimable -- can we estimate the amount of time or work the story implicates?
  • Small -- is the amount of work implicated less than a month? Is this really a single unit or is the story composed of multiple stories that need to be further broken down?
  • Testable -- do we have a clear way to verify whether or not a story can be accomplished once the implementation is completed?

A useful user story contains significantly more information than the scenario. A fully formed user story encapsulates the 3 Cs: Card, Conversation and Confirmation.

The Card

This is the basic scenario phrase. It is called the card as often this phrase will be written on a 3"x5" card and used during card sorting exercises.

The Conversation

This is the dialog about how the story will manifest and what users care about. It is recorded as part of the story in a series of concise bullet points, with the goal of enriching the story.

The Confirmation

The confirmation element contains the business requirements for the "Testable" bit of the story. These are the tests required to confirm a story has been implemented correctly and completely.

Mittleman suggests the following format for a user story: 

  • Title
  • ID
  • Scenario (As X, I want to Y, so that Z)
  • Conditions of Satisfaction
  • Example scenario
  • Business Rules
  • Impacts on existing functions
  • Links to reference information
    • Specifications
    • UI mock-ups
    • Etc.
  • Test case outlines

And he points out that there are both low-tech (e.g., 3x5 cards) and high-tech (e.g., edistorm.com, WebSort, etc.) tools for building out user stories with your team.

5) Build Reference Points, Wisely

The road forward from user stories requires imagination and research. Some keys to this next phase says Mittleman, are looking at reference sites and studying competitors -- look for best practices, recurring patterns and looking for how similar problems have been solved. Try reverse engineering your competitors' user stories and the personas they target. 

Additional tips Mittleman shared include:

  • Test the users you want, not the users you have
  • Users give you conflicting feedback, take time to find the most broadly useful reality
  • Validate the problems you are solving actually exist
  • Prototype early
  • Plan through version two or three

6) Get Your Content Strategy Sorted

This phase begins the shift from problem seeking to design and is particularly important for Web CMS projects. CMS projects are heavily content centric and the information architecture and content strategy can have big implications on the platform selected for the project, says Mittleman.

Mittleman suggested that Card Sorting while not a simple topic (he spends 3-4 weeks of his course on the topic), is one of the best tools for teasing out the relevant content strategy details. He pointed us to Usability.gov for a solid overview of card sorting techniques. And to this post for a list of relevant tools.

Card sorting, says Mittleman, will give you a visual mind map of how your users think. This map will in turn inform your taxonomies, choice of site vocabulary, how menus are labeled, how elements are grouped and more.

Use this exercise to answer questions like:

  • Do users want to see information grouped by subject, process, business group or information type?
  • How similar or different are the needs of different personas?
  • How many potential categories of stuff are there? (often drives navigation design)
  • What should these groups be called?

7) Audit What You've Got

Next in the process is -- assuming you have an existing site -- a content audit. This process is meant to drive more conversation and tease out additional information about relationships in your content, understand access control and further relate user stories to your existing body of information. 

The content audit will also help you clean up the cruft, reevaluate ownership of content, understand and refine content processes, and understand all the various formats your content is in, why it's in these formats and if these format decisions are still valid and best serving to the user stories. 

The net result of a content audit, according to Mittleman, is:

  • An acute awareness of site priorities
  • An increased awareness of business or operational constraints
  • Surfacing of a common language
  • An acute sense of the scale of the project

8) Map Your Site

Sitemaps may seem like an antiquated idea given the dynamic nature of many sites, AJAX content, the endless scroll of sites like Pinterest, etc. But the sitemap exercise is still highly used and useful to the UX process, according to Mittleman. He recommends designing your sitemap offline and addressing the following points:

  • Menuing
  • Categories and sub-categories
  • Special pages outside the main content
  • Your tagging scheme
  • Module/widget assignments -- where in the site are these used, etc?
  • Address public/private parts of the site (e.g., by using color coding)

9) Build the Wire Frames

Using one of the many wire framing tools out there, start mocking up your site in a light-weight fashion. Don't make wire frames pretty, says Mittleman, that will only serve to distract you from possible failings. Using pencil and paper is not a bad idea!

Mittleman also urged the audience to review current heatmap research and pointed out via several examples how there is no standard way that users scan a screen.

10) Research Web / UX Design Patterns

This is an area of much research and evolution, says Mittleman. There is no best pattern, only a most appropriate one, considering your project context. He suggested the following resources as a starting point:

11) Test Early Designs & Refactor

Use real tests to validate your to-date analysis and findings.

Remember, Mittleman emphasized, you are not your user. You need to validate your logical design, you should test your new designs against your legacy system (if possible) and once through this phase and the related refactoring, only now are you ready to build something.

Title image copyright Dirk Ercken, courtesy of Shutterstock.