Limit the choice of delivery meals based on your preferences.
Limit the choice of delivery meals based on your preferences.
Please note
The project was designed for Polish users, therefore wireframes are in Polish.
My role
- Working with previous research results.
- Designing information architecture.
- Designing the final product.
Problems to solve
- There are too many meal options in delivery apps ("The paradox of choice")
- Some food delivery apps do not take food preferences into account.
Persona
From the provided research results (interviews), I created a Persona. This is the user to whom the product will be mainly directed. In the further development of the project, Persona will come in handy in decision-making moments. The persona tool will also be useful for showing user prospective to team members or stakeholders.
I used Persona at all stages of design. While creating it, I focused more on defining the Persona's motivations (goals, frustration, behavior) than demographic data.
Persona description (in Polish).
Activities / Objects / Features
The AOF tool allowed me to find what the interface need to have to enable the user to perform specific tasks. Thanks to the AOF, it was possible to define key screens. I also decided to add some smaller features like including Groupon discounts, showing grammage/kcal or indicating the dish spiciness. AOF also allowed me to look more into application structure.
The most important features: exclude meals based on preferences, showing only 4 random meals to the user, showing meal opinions (screens in Polish).
Red Routes
For each activity (derived from AOF), I have prepared a Red Routes table. The tool made it possible to evaluate which functions are more and less important to the user. The less important ones will be postponed for later application development. Valuation also allowed to concentrate on the elements that the user will need the most.
User Flow
I have created various versions of User Flow to describe the steps in order to perform a specific task. When using this tool, I used sketches of solutions created on a regular basis. Some of them appeared in the previous stages of work, so I needed to clarify those sketches.
Find my dinner's user flow.
Flowchart
I created information architecture using Flowchart. A detailed tree diagram made it possible to define key screens, as well as those that can be made consistent with one template. The Flowchart tool helped me to consolidate the knowledge about navigating through the application.
The app will have an inverse user path to typical food delivery apps. Instead of choosing a restaurant and a dish, the user will first choose the dish, and then the place from which the meal will be ordered
Information architecture presented as Flowchart.
Wireframe
Based on the previously created sketches, I started to create a wireframe. When creating new interface elements, I used solutions already known by the user (popular design patterns). The created wireframe was used for usability testing, therefore any decisions made during wireframe design are not final. The interactive prototype was made in the Axure RP program.
Wireframe used in Usability Testing (screens in Polish).
Usability Testing
The goal of the usability tests was to find and eliminate problems related to the usability of the interface. Not only people who fit in Persona were recruited for the tests. However, the comments from the respondents who best matched the persona were more valuable.
Some of the changes made after Usability Testing (screens in Polish).
User Interface
After a series of usability tests and finding that the interface is quite intuitive (especially for the target audience defined by the persona), I started designing the UI. I used the Apple Human Interface design system because the application was supposed to end up in the AppStore. Everything was designed in Axure RP, using appropriate libraries.
User interface using Apple Human Interface design system (screens in Polish).
Summary
I had a solid lesson in not getting too attached to a lot of ideas for smaller improvements. A much better solution is to make a good MVP, leaving some interesting features for later.
One, well-defined Persona gave me enough insight to work on.
Despite using an agile methodology, the loosely set top-down framework proved to be helpful.
