USDS’s 5 steps to mobile success
Connecting state and local government leaders
Erie Meyer, a founding member of the White House’s U.S. Digital Service, offers five tips for building mobile services.
When building mobile solutions, Erie Meyer, a founding member of the White House’s U.S. Digital Service, said it is important to take a tactical approach.
At a May 24 FedScoop event on mobile government, Meyer gave her top five tips for making the most of mobile, based on USDS’s experience with partnering agencies and industry:
- Start with a problem statement
- Make the scrappiest possible prototype
- Build with your user
- Open the data
- Build mobile first, but don’t stop there
Meyer used the Department of Education’s College Scorecard, which was launched in 2015, as an example. Developers from 18F and USDS began with a problem statement that identified the goal, which was to help potential college students find the best schools for them.
USDS identified and spoke to intended users to ascertain their online and mobile behaviors and the ways they make consumer decisions. Armed with this information, USDS could create a data-driven solution.
The problem statement the team drafted didn’t indicate if solution would be an application or website, which is critical, Meyer said. The goal must not be informed by need, she stressed, not by the tools used to get there.
Then USDS created a prototype. “The point of a prototype is to test your riskiest assumption,” Meyer said. “It’s the best way to make sure you’re not setting money on fire.” USDS started with a cardboard iPhone and paper mock-up strips of its design to test whether or not students would use a mobile tool based on a government website.
A few prototypes later, USDS built a mobile website and a reference implementation, but then realized from the conversations it was having with potential users that students do not typically use government websites. USDS had to find another way to get the information to the students.
Making a list of resources and websites students usually turn to for college information, USDS found third-party partners that use open data to help students make college decisions. According to Meyer, the USDS gave these partners the Department of Education’s data to use in their platforms even before it created an application programming interface for the College Scorecard data.
“It was important to talk to the people who made the tools that students were actually using.” Meyer said. By making the data available to third parties early on, USDS was able to reach a much larger audience.
With the College Scorecard project, USDS learned that had it specified a mobile app in its problem statement, it wouldn’t have built the API now used by software developers, researchers and policymakers to foster analysis and the creation of more tools to help college students. Likewise, working with students to find which sites and tools they were already using in their college decision process gave USDS options for partners, which expanded the utility of the product beyond the government.
USDS took similar steps with a more recent project, StudentLoans.Gov/Repay. After creating a platform-agnostic problem statement and 19 prototypes beginning with paper,, the team built a tool that, in five steps or less, provides a set of recommendations for how to sign up for the best option for student loan repayment.
And after finding that borrowers were comfortable getting instructions on mobile but wanted to complete the process at home or on a desktop, the USDS included an option to send the repayment plan instructions to the user’s email.
“We didn’t restrict the full life cycle of the product to a mobile experience,” Meyer said. “If at the end your users need a piece of paper, if they need a desktop experience, let that happen. Don’t get obsessed with constraining it with mobile.”