As a part-time EMDD student and a full-time publications designer, my brain is constantly toggling between student mode and work mode. On the positive side, this means that the skills and concepts I have picked up in my classes immediately become a part of my mental toolkit at my job.

I work in an economic research office where every job is deeply connected to data. The research team cares about trends in the data and the implications for households and businesses. As part of the publications team, I care about the best way to tell the visual story of this data.

One project in my office involved designing a website that takes clients step-by-step through an online process to help them understand the strengths of their community and the best direction for future economic growth. The question is: How do we take a complex series of tasks and simplify them for our clients?

The client journey (aka user journey) was developed by a team that included several economic professionals, a website developer, and a publications designer (me). Although we did not follow a formal design thinking process to develop the project, the development process included abstract discussion (brainstorming/ideation), defining, prototyping, testing, and lots and lots of revising.

Over a course of six months, we discussed and listed the critical objectives that we wanted a potential user to complete, the actions that the administrators would have to take to make those objectives possible, and the actions that could be added if users were unable to complete the objectives. We also estimated reasonable time frames for each step and action in the journey.

To document these hypothetical user journeys, we drew basic and then increasingly more detailed flowcharts, which can be thought of as user journey maps. The details and phrasing of the maps changed as we refined/clarified the process and developed new features. The map also changed in intensity of detail depending on the audience to whom we were presenting (a basic overview for promotional partners, more detail for potential users, and far more detail for coworkers behind the scenes).

The project team also had to establish uniform terminology for our project: Each “step” in this project involves several tasks for both the user and the administrators. A “client community” is self-defined by the user, so it may be a town, a multi-town region, an entire county, or a multi-county region. All project assets (brochures, website, presentations, etc) and project team members need to use this terminology. We also must have consensus for which tasks fall under which step, which conditions must be met for a user community to be eligible for the next step, and when exactly a user community is promoted to the next step.

To keep this project scalable and cost-efficient, we rely heavily on website automation to guide users and administrators through each step (we’re looking at a pool of 600 communities eligible for participation within a 10-year window, and we estimate 0.5-2 years for process participation). This very complex website is being developed in phases, with the first phase completed for a soft launch in early 2016, two years after the initial conversations and planning began. After meeting with the very first pilot community to explain the steps and how they work online, it became obvious to me that we needed a user guide.

The website is full of contextual prompts, but many of our potential clients do not fall in the “tech-savvy” category, and therefore are very intimidated by a process that is so heavily web-based. I think of this audience as “nervous web users”—those who may successfully email and web surf, but panic when an ad pops up or a video auto-plays. The nervous web user needs some hand-holding when they do something new online.

When building the user guide, I went back to the user map and separated each main step into a chapter. Each main task became a heading appearing chronologically, and every task has a corresponding screenshot with added arrows, circles, and dummy information so users know exactly where everything is on the site, what it does, and when to use it.

Creating a dummy account was doubly useful. Not only did it serve as an effective example of what sort of information goes where in the site, but it also forced me to perform a cognitive walkthrough of all the features of the site and highlight the tasks that might go wrong. What happens if I mistype an email address? What happens if someone forwards the questionnaire invitation to another address? What if the community account needs to be switched to another user and how do they pick up where the other left off?

Because the website is implementing new features in phases, the user guide is not a static document. The most current “official” version is updated online, and the team must be notified when significantly new versions are made available. Each version of the user guide has the publishing date marked clearly on the front, features a “who to contact” page with all the administrators and partners associated with the project, and references the online download link in multiple places. If users suspect they have an outdated version, they can easily download a fresh copy.
This project is constantly improving and expanding, so it’s important to think about what we’re producing from an angle of sustainability. This is a long-term project, so we must be vigilant in establishing a maintenance routine to ensure that features continue to function and documentation reflects that function even five and ten years down the road.