Skip to content

Project hypotheses

Joseph Castle edited this page Nov 1, 2016 · 37 revisions

Template:

We believe <this capability>

What functionality we will develop to test our hypothesis? By defining a ‘test’ capability of the product or service that we are attempting to build, we identify the functionality and hypothesis we want to test.

Will result in <this outcome>

What is the expected outcome of our experiment? What is the specific result we expect to achieve by building the ‘test’ capability?

We will know we have succeeded when <we see a measurable signal>

What signals will indicate that the capability we have built is effective? What key metrics (qualitative or quantitative) we will measure to provide evidence that our experiment has succeeded and give us enough confidence to move to the next stage.

reference


###Opportunity brief #1 - Landing page (homepage)

We believe that

  • improving documentation and reusability
  • building in the open and using open source technologies
  • making the site user friendly
  • ensuring the site meets the U.S. Web Design Standard

Will result in other agencies using the open.gsa.gov site as a model.

We will know we are right when

  • we get questions from other agencies about the specifics of reusing our site or code
  • when we see the influence of our site in other agency development

###Opportunity brief #2 - Subpage for Open Data

We believe that

  • introducing an Events section to the site

Will result in increased attendance to GSA open data hackathons and related events.

We will know we are right when

  • when we see increased attendance at posted events

###Opportunity brief #3 - Subpage for APIs

We believe that

  • introducing a blog section to the site

Will result in increased engagement with the site.

We will know we are right when


###Opportunity brief #4 - Subpage for Code

We believe that

  • creating a project showcase to highlight case studies and successes with GSA open assets

Will result in increased interested in participation in open technology projects within GSA.

We will know we are right when

  • the number of project inquiries from GSA teams increases

###Opportunity brief #5

We believe that

  • providing guides on open data, apis and open source code
  • migrating all policy and informational documents relating to open technology within GSA to the site

Will result in increased understanding of GSA open technology.

We will know we are right when


###Opportunity brief #6

We believe that

  • standardizing the documentation provided for GSA APIs
  • using an automated method of demonstrating API calls

Will result in increased engagement with GSA APIs.

We will know we are right when

  • analytics shows a greater number of page views of documentation
  • feedback increases through issues and comments

###Opportunity brief #7

We believe that

  • making REST APIs from static GSA data sets

Will result in increased engagement with GSA APIs.

We will know we are right when

  • analytics of the new APIs shows a greater number of page views of documentation
  • feedback increases through issues and comments

Process

Development

Hackathon

Clone this wiki locally