EAT School Lunch Challenge

View the Live Site - eatschoollunch.com

Why Participate

By day, Emily McCammon is a product designer at Gaia, a conscious media network that streams thousands of videos across web, IOS, Android and Roku devices to over 100,000 subscribers. By day, Justin McCammon is a full stack engineering lead at InstaBrand trying to turn terabytes of social media data into actionable information. By night, he works on education software called Ignite Teaching which allows kids in schools to create presentations collaboratively across iPad, Android and the web. Emily and Justin’s moms are both teachers and both grew up attending public schools in districts where many students could not afford daily school lunch. Justin qualified for free or reduced price lunches from grades 6-12 and remembers the embarrassment of turning in the paperwork and waiting in a different lunch line.

In short, the team is passionate about education and knows there is a lot to be improved. Creating a better application process to apply for free & reduced priced school lunches is one small component of the public education experience but if we can polish one thing and ultimately give one kid who would have otherwise forgotten to turn in a form the option to get free lunch then this is worth our time. Justin & Emily are married and lead pretty digital lives (Justin proposed to her by making her an app and for some reason she found that romantic).

Creative Process

The project workflow over the past couple of months looked something like this:

  • Research & Interviews: Talking to real people is a critical part of the user centered design process, so we reached out to friends and friends of friends.
  • Low Fidelity Design
  • Development Set Up
  • Medium Fidelity Design & Style Guide
  • Medium Fidelity Development
  • Prototype & Test: Seven people clicked through one happy path prototype and answered survey questions. It does not sound like a lot, but the insights that emerge from simply testing a few people with work in progress designs are priceless.
  • High Fidelity Designs
  • Complete Development
  • QA
  • Development Improvements
  • Create Contest Submission Materials

UX Decisions

Overall Structure - There are a variety of ways to approach the high level interaction paradigm. For example, should the questions be presented one at a time or in a vertically scrolling list view? We chose to send users down a linear path where one question was presented at a time for a few reasons. Emily's experience testing onboarding flows told her that presenting too many things at once was often reported as "that felt like work" during user testing, so we kept that in mind. Also, some of the questions are simple but the explanations are dense. So we wanted to keep things as simple as possible. We looked at other products in the marketplace like Turbo Tax and Typeform for inspiration, even though what we created is fundamentally very different.

Linear Path vs. View All Steps - This form has a couple of critical conditionals. If a student is part of a different assistance program, they can skip ahead. If a student is a foster child, they can skip ahead. We felt that no matter how it was presented, viewing all steps got confusing given that a user’s steps are unknown until they have answered the conditional questions. On our application, users can go back but not forward and they can see progress but not specific steps. On each step, the Next button validates once fields are filled out.

Fully Responsive - We knew from the onset of this project that the form had to work on small and large screen sizes. Our intuition was validated when we interviewed the Director of Student Data at a district in Philadelphia, PA. This person has in depth insights into the lives of the families in her district and knew that many did not have desktop computers at home. This anecdote is backed by a Pew Research study on smartphone ownership that found:

Some 13% of Americans with an annual household income of less than $30,000 per year are smartphone-dependent, and 9% of those with a high school diploma or less fall into this category as well. By comparison, just 1% of Americans from households with an annual income of $75,000 or more depend on their smartphone for internet access to a similar degree.

Where "smartphone-dependent" refers to lack of access to internet through any other means. The take-away: we knew this form needed to work on every device possible.

Consistent Visual Language - Consistency is of the utmost importance in UI design. There may be applicants who cannot read well or who do not understand some of the helper text BUT if every Next button looks alike and form labels are sized and positioned the same way then the visual system will have meaning and applicants will be able to get through it.

A Few Valuable User Testing Insights

  • Make the Form Elements Big: One tester noted that it never hurts to make the text and form fields bigger. Filling out a form is fundamentally daunting and the moment one person has to squint that feeling is multiplied.
  • Make the Help Icons More Apparent: We learned in testing that no one goes looking for help until they need it but we want people to know it is there the whole time. We didn’t want the helper text to be too intrusive throughout the form so we added a tooltip to call it out on just the first screen.
  • Progress Indication is Important: Initially, our form included a non explicit progress bar but that was not enough for testers. A few people wanted to know exactly how many steps there are in the process so we decided to display progress in a format like "Step 2 of 12".

Tone & Copy - Ideally, getting a free or reduced priced school lunch would not be a hassle or cause for embarrassment but for many parents and kids it is. On the first screen of our form we remind applicants that they are not alone and that they are doing a good job by filling this out.

In the U.S. there are over 50 million children enrolled in public school. 30 million of those children eat free or reduced priced lunches every day. The National School Lunch program gets stronger every year because more and more families participate. Thanks for being part of it.

Also, throughout the form the copy is meant to be clear and accurate but conversational and human. We want applicants to understand the instructions without feeling like there is a barrier between them and a bureaucracy.

Technical Decisions

Since the main impetus of this project is to "digitize" the school lunch application form we knew that every technical decision mattered. The number one consideration in our minds was flexibility since we knew this solution may need to be implemented in districts with varying tech stacks and / or capabilities. We wanted to make sure that the project was approachable, well documented, well written and easily modified to meet a specific district's needs.

Below we've listed the core technologies used as well as why each one is the right choice for this project in particular.

Backend

Frontend

  • Javascript (plain)
    • using ES6 features with gulp / browserify for transpiling
  • SASS for CSS

Internationalization (i18n) - Looking at technology from the other side - how it serves not just it's creators but it's users we knew that we needed to make our design responsive for all the great reasons detailed above. We also knew internationalization / translation (i18n) would be key to help districts adapt and better serve their specific communities. To that end, Django has excellent i18n support and nearly every single piece of text in the site is marked for translation (including the admin interface which is translated into 50 different languages out of the box). We purposely kept as much text as possible out of Javascript so we could leverage the power of Django's i18n module. A standard .po translation file for any language you desire is just a Django command away. That means that a Spanish / Russian / Mandarin / etc translation of the site can easily be implemented by local districts as needed.

Admin Interface & CSV Export - Another aspect where we can leverage technology is in the admin interface for managing the applications coming in as well as exporting them into other systems. Django has a wonderful admin interface out of the box and with a few customizations we are able to allow admin users to easily search through applications by any number of fields like signing adult name, date, application id or child name as well as edit / mark as approved each application as it comes through. And once they're done processing the data they can export it in any of a number of formats including CSV, XLS and JSON (all of this can be seen in our demo video or on the live site).

Vanilla ES6 Javascript - Our frontend doesn't use any JS frameworks which to some people means it doesn't have any organization. Much to the contrary, we use modern ES6 JS modules and classes coupled with the revealing module pattern and plain old attention to detail to make sure that if you know JS you know our frontend from day one. This is backed up by the fact that Justin has onboarded nearly a dozen junior developers to a similar architecture without a hitch. We used ES6 JS to help make the code more future proof but also realize it needs to run in a number of different environments. To solve that we employ Babel which transpiles ES6 JS to work in today's (and yesterday's) browsers seamlessly. On the CSS side we use SASS and an autoprefixer in our build process that allows you automatically transform your CSS to target nearly any browser. If that sounds like a lot, don't worry. As documented in the readme all you need to do is type gulp at the command prompt and everything is taken care of for you in our build process (but of course it's easy to extend and change as needed).

Put together we think we've created a tech stack that not only solves the task at hand today but is ready to solve the problems of tomorrow as well. We also believe it will be easy and straightforward for districts to implement which is important to ease it's rollout.

Final Thoughts

Applying for free and reduced priced school lunches is just the tip of the iceberg when it comes to not just improving school lunches but the whole public education experience. However, just like we didn't sit down and have our whole project done on day 1, we'd be naive to think we can rethink the whole education experience in one go. Design is a process. Development is a process. And applying those processes to the system of school lunch will surely be a long series of processes unto itself. The important thing though is that we, the collective-all-your-neighbors-and-friends-and-fellow-citizens we, continue to keep moving forward. We're proud to do our part, however small it may be, to keep moving forward.

Onward.

Share this project:
×

Updates