Introduction
Starving, in line at security, and cutting it close to departure? Terminal Eats helps you find restaurants in your terminal, check prep times, and place an order for pickup, so you can board your flight hot meatball sub in hand!
Early summer 2020, after numerous online courses, I took a turn with my first independent prototype. Along the way I progressed through five different design technologies, and documented the journey on Github, in a nod to my past training as a developer.
Prototype
Task: Hop straight to "Find Food." You are dying for Ahi Tuna from Oh So Sushi... don't forget to checkout the map! I promise it's not as terminal as it sounds.
Project Tools
InVision, Sketch, Atom, Marvel, Canva, Pencil, Paper, and Persistence
Takeaways
1.   When user testing ask for feedback about the look and feel of the app. The name Terminal Eats paired with a logo that has angel’s wings says “Your first meal with Terminal Eats will be your last one.” I’d update the logo, but it’s a good lesson for me to remember.
2.  This project took hours and hours and hours. It had no future, it wasn’t of interest to anyone but me. I wrestled with 5 different design apps. I was brought to tears and then to cheers over and over. I was undeniable, I loved what I was doing.
IA / Workflow
Drawing the workflow diagram caused me to identify a flaw in what I saw early on as a nice feature in the app, the ability to view a restaurant's menu, without leaving the list of restaurants.
In the original concept for the app, users would be able to "quick view" menu options. In drawing out the flow I found that navigationally a "quick view" was only marginally different from the conventional flow. In both cases, viewing the menu required going "back" to view the next restaurant's menu. 
Since my "quick view" didn't offer a clear benefit, I designed the app using a more standard convention.
Lo Fi WireFrames
Creating the wireframes created some reverse engineering to the workflow. Laid out as wireframes, the clear challenge was to keep it functional and uncluttered. This was easier on some pages than on others.
1. "View Current Order" would need to be hidden if there wasn't a pending order. It also raised the need for a userflow if there was! (On the list for v.2)
2. My little addition of "for pick up" is a preview of the crowding issues I would face on the site
3. I prioritized accessibility to the map because airports are inherently confusing. Restaurant signs are competing against airport navigation like gate signs. The map is key to meeting the goal for the user to arrive to hot food.
Prototype V.1
Tools: Canva +  ctrl+c, ctrl+v (repeat); Marvel
Canva never felt like the right tool for my prototype. I have enough of an OOP developer background to know in my heart that the copy/paste demands of this tool were a major weakness. That said, it felt pretty great to see my wireframes come to life! 
I'm a paper person (still) and mapped out my prototype wiring with colored markers. Setting up the hotspots was a great opportunity to compare the mockup with the workflow diagram and confirm the app would work as intended. 
I used Marvel to wire up the hotspots and have my first real prototype online. I was done! But I'd heard about this thing called "symbols," my OOP dream-come-true, and I decided to check that out.
Final Prototype
Tools: Sketch, InVision, repeat
Don't get me wrong, I was relieved to discover Sketch. Symbols and libraries are amazing. My Sketch course emphasized efficiencies like properly using symbols and (many) keyboard shortcuts.
I quickly learned working with symbols and then animating them in InVision presented major file management challenges. I became painfully away of how crucial pre-planning is when managing assets. What at the time I called, "There has to be a better way," I now know formally as a design system, a concept I value even more as the complexity of my projects grows.
Back to Top