As simple as possible, but not simpler: Launch lessons from 18F
Connecting state and local government leaders
After launching a crowdfunding beta site for Peace Corps Volunteers, GSA’s 18F offered insights into the design and development process.
Crowdfunding does not have to involve Kickstarter. The General Service Administration’s 18F digital services team, for example, recently built a donations platform for the Peace Corps. Like most startups, the team hit a few roadblocks and made some detours -- and posted some advice based on what worked and what didn’t in its efforts to highlight volunteer stories, optimize for mobile devices and simplify the donation process.
The developers found that simplifying the donation process through a new interface would be difficult given the limited control it could exert over the payment processor, and the lack of flexibility in the collections form. However, 18F could control the steps for a site visitor between landing on the website and offering donations, so that “when the user found a compelling story, they could select a donation amount in-line, turning what used to be a four-step process into a single click.”
Developers initially wanted a different look for the payment form, but time was not on their side. They were forced to opt for a simper form that used radio buttons to let donors to choose the amount they wanted to give. Their budget did allow for improvements later, but the less desired, “clunky” selector option worked and served as a good starting point.
On the flip side, simplicity proved counterintuitive elsewhere. The most complicated user interaction for donations offered several filters and categorization mechanisms for selecting how a donation would be used by the Peace Corps volunteers. The ideal page, 18F explained, would have involved “asynchronous requests, where data is transmitted in chunks instead of in one large block, so that the browser only loads what is needed.” Opting instead for a simpler model that included all content in the initial page and hid elements based on filters proved inefficient. Along with massive page sizes, developers had to include patches to minimize redundant markup. The simpler solution set the team back, and still did not get the form to where 18F developers wanted it to be in terms of site load time.
Prior to launch, reports indicated that the website could experience periods of heavy traffic, so Amazon Web Services S3 and CloudFront were used to bear the brunt of web users while the donations application was protected by a memcache-based layer to maintain a low server load. The caching layer architecture designed for the donations application was built to handle dozens of requests per second and keep requests moving.
The actual traffic numbers turned out to be much lower, however, and the additional caching led to confusion and waste. In sum, the architecture was excessive and a simpler platform would have sufficed, 18F wrote.
Merging with the legacy donations portal brought challenges too. It collected more donor information than the 18F-designed version did, and it allowed for keyword search.
The developers wanted to cut as many fields as they could from the donor form, but knew that would require approval from a number of stakeholders, which would take significant time to secure. So as a back-up plan, they also connected a version of the legacy form to the new back-end system -- and ultimately used that version for launch.
To provide a search function, the developers could either add a full-blown search index or a tightly coupled database implementation, both of which would impact design and development. So the team decided to hold off on implementing search and the site launched without it. 18F developers said they were still unsure if that tradeoff was worthwhile.