Any designer is faced with a situation where the routine begins to put pressure, and new tasks begin to seem boring and dull. This is called “burnout” and people of creative professions often encounter it, in fact, burnout is inevitable and you just have to wait out, change your occupation or find a really interesting and new task for yourself, to distract from everyday life, develop skills and find innovative solutions to standard problems (and cheer your ego a bit, of course). Ideas for such a project can be real or not, personal interest and desire are important here.
So, the project “Wine not?” was born. Actually, if we say frankly, this project is the result of merging the ideas of one of my previous clients who wanted to create a platform for organizing deliveries from his restaurant chain (and although the idea remained exactly at the stage of the idea, it stayed in my heart for a very long time) and my own thoughts on this.
So, what is “Wine not?”?
Incoming data or “how the idea was born”
“Wine not?” is a restaurant chain that discovers a new direction — the delivery of personalized products — and in order to optimize this process, a system was invented where it would be simple for each user (namely, network employees who are involved in delivery) to conveniently and quickly organize a delivery served by the restaurant to any part of the city.
The main competitive advantage will be the opportunity for couriers and restaurant administrators to choose the most suitable orders manually or using the AI system.
Objective: to create a convenient “dashboard”-type interface for internal use and organization of food delivery from a restaurant chain.
UX process. Chapter One: User Map.
It should immediately be taken into account that the “Wine not?” platform is intended exclusively for use by company employees and should be understandable to them, and not to end customers, but at the same time, be consistent with the corporate identity.
So, a user map is needed to better understand the needs of the client, it helps to collect all available information about the upcoming project and systematize it, understand the pain points, identify problems and then come to their solution.
Usually, when compiling a map, I try to take into account the basic needs of users and come to that kind of final “customer path” that fits a specific case. This helps to find the best solutions for the development of a design product based on needs and other important factors.
So, for example, when creating a “client path” specifically in this case, I added such a characteristic as “type of device” so that this information remains in a prominent place, since there are 3 roles in the project: “super-admin” (fundamentally convenient use of applications on PC), “admin” and “courier” (due to the nature of the posts, the application will be more convenient to use from mobile devices). The formation of a client map taking into account devices in this case is also necessary for the convenience of forming tasks and finding bottlenecks in the project, determining the needs of users, etc. Below I leave the results of building a map.
Thus, two main tasks of the application were identified:
• it is necessary that the user receives the maximum amount of information for the minimum number of iterations;
• you need to take into account that the functionality of the application is divided into roles and the information on the screenshots should be different from each other.
Next, I wrote out a list of bottlenecks for each of the roles that need to be paid more attention when working with UX:
• Courier: you need to access statistics and schedule management, while the interface should be as clear and simple as possible;
• Admin: you need to get information and functionality to manage the schedule, staff work and view statistics on the restaurant for which it is assigned;
• Super-admin: you need to display all the statistical and analytical data for each of the restaurants in the network in aggregate and separately, while the data should be accessible and structured.
Now that we have identified the basic data, bottlenecks and tasks, we can move from the preparatory part of the work to working with wireframes and structuring data on the application screens.
UX process. Chapter Two: Wireframes
The next step in the design development is the visualization of the data obtained during the preparation taking into account the identified tasks and bottlenecks of the project. The main goal in this case is to determine the general structure of the platform’s functionality.
At this stage, the “base” of the project is laid, the location of the navigation elements is determined, what data will be displayed on each screen, how it will be visualized and the general view of the platform. Since the work on the preparation of wireframes was divided into 3 stages (according to the number of different roles in the application), I started up and down the hierarchy of roles and, accordingly, the complexity of the functionality.
So, from the work done in compiling the user’s map, we recall that for work the Courier needs a mobile application with statistics and a calendar. At the same time, the platform implies simple navigation through the tapbar without multi-level transitions, because if we imagine a typical situation in which the application will be used — in a hurry, on the street or in transport, during the delivery process — it is easy to come to the conclusion that this type of user needs to interact with the application as simply and quickly as possible despite “distracting” factors. To do this, you need:
• information should be clear;
• information should be placed at the height of the screen to exclude scrolling and speed up interaction with the application.
That is why it was decided to display information in numbers, since they provide the user with instant information used for analysis and decision-making, however, in addition to numerically presenting such data as delivery time, total amount of time worked, number of deliveries and ratings should be presented graphically, to track them in dynamics. The best solution is “column charts”. For quick identification and to exclude the re-designation of each norm, each value was marked with its own color.
We move on to the next task — drawing up a calendar of shifts, taking into account the factor that the Courier can manage his work time by himself, noting the number of days needed and choosing shifts. Here it was necessary to arrange a calendar with a graphical display of already worked out and planned shifts and a functional panel with the ability to create a new application.
Last, but not least, the incoming delivery request page was designed. In view of the specifics of the project — the Courier takes orders on his own, by analogy with a taxi — this page is the basis. The information presented on this screen should be exhaustive so that the courier quickly decides to accept this delivery or reject it. The application shows the starting point of the courier’s location and delivery point, the distance between them and the estimated time are calculated so that the courier can evaluate their capabilities.
In the process of designing the order page, a hypothesis arose: if you add an approximate delivery weight, will this help the courier in making a decision, taking into account his capabilities (space in the car, total load)? The answer was positive, dimensions and weight must be taken into account to optimize the delivery process and the convenience of the Courier, as well as minimize risks in the delivery of a large number of dishes. Therefore, this information is also displayed on the screen.
he next role in the project hierarchy is admin. In fact, the administrator must coordinate work on the spot (in the restaurant), organize delivery and analyze the results of the work done. Since the administrator is less mobile and has fewer distractions than the courier, the desktop version and the version available from tablets should be developed here first.
The main information that should be considered first is on the left, since we usually look at information from the upper left corner. We have already determined what information should be presented on the Admin screen, it remains only to prioritize and structure this data for ease of use. The numerical data is located at the top of the dashboard, since this is the simplest and most significant form in our case for showing statistics.
Delivery speed and the number of deliveries are also key indicators (like profit, but this indicator is required much less often, therefore it is located below) therefore, these indicators are located in the upper right corner, and for clarity, graphs showing the dynamics of these indicators were added.
The next most important task is to display indicators for monitoring the work of couriers, therefore, you need to place these indicators in a prominent place for the convenience of information perceiving — below numerical indicators.
Before compiling the table, you need to indicate what information the administrator must receive to analyze the courier work. In our case, it will be such data as: the number of deliveries for each courier, revenue for the current day, courier shifts and activity markers to display courier’s workload. Since the number of participants can vary — the window itself is fixed, and the list of couriers is scrollable, while the couriers of the current shift are always in first place in the list. Also, here you need to display the workload of field and local staff. Here we use a pie chart because this type of information is always calculated as a percentage.
The final point regarding UX design is the development of a dashboard for the super admin. We have already determined that the aim of the super admin is to record and monitor data on the work of restaurants, but this time the analytics is carried out not for each point, but for the entire restaurant chain.
The key objective is the income, profitability and availability of raw materials, tools and materials needed for production. All indicators from the admin panel are also relevant for the super admin, but new ones are added. But how to avoid a heap of graphs? Reduce them, leaving only the most necessary information. But the super admin is a “role over the roles”, he needs all the information about the restaurants, what if he wants to know the details of this or that data?
As a solution, the workspace was divided into two parts: the left one is a set of cards with statistical data, and the right one gives more detailed information. To get this information, the user needs to click on the card of interest. And if nothing is selected and the user does not even guess that you can click something? To avoid this situation, an empty state must be indicated by an illustration and a hint.
Another difference from the Administrator’s dashboard is the graph with the delivery location. It is a map with a bubble chart. This type of chart helps you to see the quantitative difference by delivery area.
One of the main tasks of the super administrator is monitoring and supplying products to restaurants in the chain. For the products cost keeping, a warning card has been created on the dashboard with indicators about how many product positions come to end and which products are most popular. This helps in making decisions about regular and ongoing buyings and supply of necessary products. When you click on this card, information on the most popular (top 3) menu items and how many times each of them was ordered is displayed on the right; immediately below them are products that come to end.
Thus, the UX base is ready and now, with the existing data presentation structure, we can proceed to the development of the interface in terms of visual design, but this is a completely different story.