Taking a Product from Zero to One

Context

The Operations & Management team was developing a command-wide digital hub for employee resources. These resources would include articles about command news, events, and more. Command staff would need a way to create and manage content for this platform, and off-the shelf content management system (CMS) products were not compatible with their security protocols.

Where I came into it

By the time I joined the team, they had already

• Interfaced with a number of parties who were interested in writing and managing content

• Decided that a custom CMS would be necessary

• Performed and recorded interviews with 6 people who were either members of our target audience or who had worked with CMS products before

Educating myself on user needs

I watched all the recordings, and took note of the following:

• Anything that seemed to evoke an emotion

  • Frustrated with lack of customization

  • Anxious about the fact that they aren’t getting notifications about what to do next

• Anything that sounded like a constraint

  • “There needs to be a review process for security purposes”

  • “We have to follow chain of command”

• Anything that sounds like an attitude they’ve developed as a result of personal experiences

  • Attitude: people who know what they’re doing can do better work when you give them creative freedom, therefore you should allow more creative freedom

• Anything that sounded like a desire

  • Expressed a desire to edit code blocks in app

Our findings

• Constraints

  • Due to our client’s internal policy, every article that gets written would need to pass through a particular organization for review to ensure quality, information security, and accessibility standards were met before publishing.

• User Priorities

  • Most participants wanted the creation of content to be decentralized so that the command to benefit from a healthy variety of perspectives.

  • Most participants wanted the quality and security review (complete with the updates and communications that come with it) to take place entirely within the app, because switching between platforms and/or incorporating email communications had caused issues for them in the past.

• Frustrations

  • Users across the board were frustrated with the number of trainings they have to complete, and were dreading the possible administrative burden of being trained to use the CMS.

  • Many users expressed that switching back and forth between platforms during their workflows resulted in poor communication and some tasks falling through the cracks.

• Other

  • When it came to how much creative freedom the CMS should allow, interviewees were divided a long a defined line: creators wanted more creative flexibility, whereas administrators and reviewers wanted more standardization and stricter constraints.

Translating the findings into action

There comes a time in every design process where you have to enter the squishy space between researching and prototyping. Here's how we navigated that:

Research-Informed Priorities

Based on our research and some conversations with the development team, I decided my priorities were to:

• Make the app learnable enough that no training would be necessary.

• Provide for an in-app review process.

• Facilitate clear communication between the author and reviewer during the review process.

• Make the review status of an article visible to it’s author.

• Prioritize consistency and accessibility above creative freedom in the first iteration so that we could study the review process after implementation with controlled variables (and the understanding that more creative flexibility can be studied and implemented in future iterations).

• Prevent scope creep by saving non-MVP features ideas in a rough roadmap for future iterations.

• Make the app scalable in such a way that it could be used for publishing content to multiple platforms down the line. For example - in addition to publishing articles to the employee research center, I was told to anticipate that in the future, the CMS would also be used for publishing help and troubleshooting articles to the IT help desk website, events to a different website, etc.

Considering different CMS structures

The team and I considered some research from Nielsen Norman Group while making decisions about how the app would be structured.

The need for security review and oversight meant a fully distributed model was off the table. A centralized model was also less than ideal, because our clients expressed a desire for the CMS to be widely available for the contribution of different perspectives around the command.