The idea itself was at its core ‘to allow users to select meals based on a number of pre-determined factors’, these would come in the form of specified ingredients, type of nutrition, the number of people eating, or any dietary preferences/ allergies, and recommendations based on current saved ‘stacks’. Many social aspects and the ability to create and store recipes for later reference. Creation of shopping lists based on the day/week menu contents.
A very bold specification that would change the process of meal selection and menu creation from “what do I feel like making?” to “what should I be eating?”. Some features would survive the development process but many others ultimately wouldn’t.
Our small team of two set about producing the first round of page anatomy outlines. Actions required to get through the initial account creation and setting up of profile preferences and then on to service provision.
The initial task would be to sort out the underlying mechanics of the service, to deliver a SaaS platform for it to be a membership-based service. Also, the creation of the recipes database that powered the meal information was huge and would be constantly growing.
Initially, the service was envisaged to be used on a tablet device on some kind of stand while the food was being prepared. Which was fine for a starting model and not worrying too much about pixels available as the screen size was generous.
However, the trend to smaller screens became very evident, meaning any later development of interface was primarily mobile along with tablets and larger screens now a lower priority.
Using a combination of User stories and user-flow testing we honed the initial shape of the service. How people would traverse the pages, how much sign-posting, and what they would probably require to fulfill goals in a seamless and timely fashion.
A very early page design made digital flesh, I’d produced a couple of static HTML pages to test out the responsive layout and fonts, etc, and injected some filler text to get an idea of the flow of the page. At this stage, there was going to be a website blog to send people to browse recipes and create menu diaries but to do so you would need to create an account… it didn’t end up that way in the end.
A large chunk of the UI work was taking the screens we had created for tablet devices and making sure that the content fit onto a mobile without it being compromised.
Once we had a basic but working model of the service built on WordPress, A Singapore based web publisher was approached to provide the public friendly version using a combination of HTML/React and the database we had created and the Joice engine and API.
Based on the Beta version, enough excitement about its potential convinced local organic supermarket to request a branded version for mobile. A sort of dynamically generated ingredients list restricted by ingredients available in their store. So you’d be able to cook any of the recipes the engine suggested.