Skip to content
This repository has been archived by the owner on Dec 8, 2017. It is now read-only.

Problem Statement

Michael Torres edited this page Mar 7, 2016 · 24 revisions

#Who are we helping?

Personas

What are our users' goals and pain points?

Problem statement - January 2016

When 18F started, its leadership was largely occupied by work outside of 18F to create processes that would allow 18F to operate. There was an assumption that if we hired smart people, they would figure it out. Employees wrote lots of documentation in both Google Docs and GitHub, but soon realized that that documentation was rather opaque to those who were new to the organization. We lacked an effective knowledge-sharing infrastructure, and no accepted practices for onboarding people.

Things have greatly improved over the course of 2015. We now have more documentation, and it is more accessible than it used to be. We have also created the 18F Handbook, which serves as the canonical source of all information 18F. However, information remains distributed and people are still confused about where to find things.

Problems

  • Need-to-know content is still hard to find: People are still confused about where to find essential information and this causes a lot of unnecessary communication overhead (for leadership, operations, guild leads, product, etc) that won't scale as we grow. And it makes it harder for new hires to get up to speed and 18F employees in general to do their work.

  • Basic data about people and projects is difficult to ascertain: There is no canonical place to find information about teams and projects and this creates inefficiencies, miscommunications and unnecessary overhead to the functioning of the company as a whole, and for projects in particular.

  • 18F has a lot of documentation, but it's not organized in any particular structure, and people are not sure where to publish what, and inhibits them from contributing to the success of the organization

Goals

  • Eliminate confusion between the Handbook and the Hub, and make it clear to 18F where they can go to find the content they are trying to find.

  • Eliminate as much as possible the need for people to go to multiple places to get information they need to do their jobs. This may not be entirely achievable in the short term, but we want to significantly improve the experience in this iteration.

  • Conduct discovery on enabling content creation according to content standards and architecture developed by wg-content or g-content

  • Make it easy for anyone at 18F to see all team members, their skills and location, and what they are working on.

  • Continue research into all of 18F to learn more about our users and their goals

How are we going to help them?

Hypotheses

  • Create a simple, easy-to-use "content browser" (the Hub itself?) that will allow 18F employees to more easily navigate across all of 18F's internal content, no matter where it was originally published (and make it easier for them to direct others to it).

  • Work with the g-content on content standards and an overall 18F content information architecture that will give us information we can use to build tools to help people publish content in the right way to the right places. Combining the Hub content and the Handbook content (and guides?) into one interface will implicitly communicate that it’s the single place to go for 18F documentation

  • Create a UI for the Hub that will make it easier for people to find the most up to date content wherever it exists. We hope to do this via a combination of information architecture and a more robust search tool.

  • Surface team data in a easy to use page where users can quickly find out about who works here, what they do, and what projects they're working on.

  • More research will give us a better sense of what our users are trying to accomplish via documentation, and that will help us come up with solutions that match their goals.

How do we measure success?

Success Metrics

  • The content will better achieve its goals - to bring new hires up to speed quickly and to help 18F employees do their jobs. We hope this will result in less overhead for the comms team and leadership as measured by requests for links in Slack and visits to the Handbook (GA)

  • We already have some metrics via Google Analytics of visitors to the Handbook, and top pages. This number shouldn't go down, and in fact, should go up as we are only averaging approximately 15 visitors per day. If this information is really essential to people doing their jobs, that number should be higher.

  • Tracking whether people actually click through in the search results will help us know if we are successful. If the ratio of click-throughs/searches is high, we know we are on the right track.

  • Continuing to check in with our users - informally, and with the @spokes user group on Slack.

What are the Risks?

  • Are we building something that we could buy? We have chosen as a team to proceed with a homegrown solution because we could not find a third party solution that was both open source, and would give us what we need. This freed us up to be creative in our solution, and make it fit our existing processes. But, there is a cost. We should keep an eye on this.