Skip to content

Project hypotheses

Joseph Castle edited this page Nov 4, 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...

  • there should be a landing page that nicely and professionally lays out data, apis, code, etc.
  • should be thought given to graphics and layout, some text here and there but pretty intuitive
  • has a hero image, possibly one from a Hackathon, maybe even the GSA DS team
  • has personas - curious, developer, data consumer - with appropriate outlets to content
  • adheres to style guide, largely to USWDS
  • is consistent with previous GSA DS sites
  • incorporates DAP scripts, search, feedback form, and signup for listserv

Will result in...

  • improved use of the site by the personas and others
  • being the model for government and industry open data engagement sites

We will know we are right when...

  • all items listed above come to fruition,
  • as seen through improved metrics and site feedback

Reference: http://open.gsa.gov/; http://federalist.18f.gov.s3-website-us-east-1.amazonaws.com/site/gsa/open-gsa-redesign/; http://open.nasa.gov; http://open.epa.gov


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

We believe that...

  • creating an open data landing page at /data that highlights popular GSA data sets and app/software built from GSA data sets *and provides basic introductory paragraph about open data

Will result in...

  • increased engagement with GSA open data assets

We will know we are right when...

  • visitor click throughs to open data sets increase

Reference: http://open.gsa.gov/data/


###Opportunity brief #3 - Blog

We believe that...

  • creating a blog with an RSS feed

Will result in...

  • improved communication with users of GSA open technology

We will know we are right when...

  • visitors are actively engage with blog posts and subscribe to the rss feed

References: https://github.com/18F/api-standards https://developer.github.com/changes/


###Opportunity brief #4 - Subpage for Code

We believe that...

  • there should be a landing page for open source code
  • it should eloquently lay out GSA's Open Source Software (OSS) policy (including link to OSS repo and pdf), links and narrative around GSA's open source repositories, some narrative around OSS guides for going open source, and where to find more assistance to get to OSS

Will result in...

  • increased understanding of GSA OSS and increased use of code through GitHub public repos
  • in other agencies using our OSS page as a model for display and content

We will know we are right when...

  • the number of clicks on our repo link or pdf file
  • the number of clicks through to our GitHub repos
  • increased inquiries of code that site participants would like to see

Reference: https://github.com/GSA/GSAOpenSourcePolicy


###Opportunity brief #5 - Standardize API documentation in industry-standard format

We believe that..

  • standardizing the documentation provided for GSA APIs
  • using industry-standard API definition (e.g. Swagger, API Blueprint, RAML)
  • providing an interactive method of demonstrating API calls and results

Will result in...

  • increased engagement with GSA APIs and allow GSA APIs to be discovered an aggregated in online API directories and hubs.

We will know we are right when...

  • analytics shows a greater number of page views of documentation
  • feedback increases through issues and comments
  • GSA APIs are included in more API directories and hubs.

Reference: https://www.govfresh.com/2014/01/next-us-government-api-strategy/


###Opportunity brief #6 - Create REST APIs from static data sets

We believe that...

  • making REST APIs from static GSA data sets
  • providing tools to automate this process, following best practices

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
  • analytics show increased usage

Reference: https://www.govfresh.com/2014/01/next-us-government-api-strategy/


###Opportunity brief #7 - Listserv site integration

We believe that..

  • the site should have an opportunity for participants to opt into a listserv
  • the site listserv should be Google Groups

Will result in...

  • increased communication with site users on a regular basis

We will know we are right when...

  • a Google Group is created (this could be in test for the Hackathon, just to show us how it works)
  • an individual signs up, GSA DS is notified, and a message is sent through listserv that all receive

###Opportunity brief #8 - Personas - Sara

We believe that..

  • xxx
  • xxx

Will result in...

  • xxx
  • xxx

We will know we are right when...

  • xxx
  • xxx

Process

Development

Hackathon

Clone this wiki locally