Deliveree Inc.
Automating operations for a fast-expanding food delivery business.
My Task

Over three weeks, design the tablet and phone user interface of a multi-platform B2B food delivery application.

iOS tablet and iPhone.

Visual competitive analysis, style tiles, high-fidelity mockups, interactive prototype, style guide.

Sketch, Principle, InVision, Google suite.
The challenge

Deliveree Inc. provide on-demand food delivery services to Chicago restaurants. They offer a premium, friendly and personal service with well-trained, highly reliable drivers and as a result separated themselves from competition while building great rapport with their existing client base.

When sharp increases in demand started putting strain on their largely manual workflow, they sought advice from DESIGNATION to help conceptualise a solution which would support their growing popularity and vision for future expansion.

The project was split into two phases, with the first being purely UX based, followed by a subsequent UI phase. I worked on the second phase as part of a UI team which consisted of myself, two fellow UI Designers, a Project Manager and a Creative Director.

The UX team before us created the concept for an integrated, multi-sided solution consisting of:

1. An iOS tablet application for restaurants to request drivers and track the full lifecycle of orders from initial request to final delivery:

Restaurant interface wireframes
2. An iOS phone app for drivers to claim jobs as they are requested and provide facilitation of restaurant pick-up and customer delivery.
Driver interface wireframes
I picked up from where the UX team left off; building upon their wireframes and producing final high-fidelity mockups based on the needs of users and the client's brand values. My team collaborated on sprint planning, research, client presentations and user testing tasks, while ultimately each creating our own unique solution.
Establishing the requirements

I started by performing an in-depth analysis of all UX data with the aim of completely understanding:
  • What we're designing.
  • Why we're designing it.
  • Who we're designing it for.
  • What the features and use cases are.

I placed specific emphasis on extracting any insights which would provide bearing to my visual design language.

Key takeaways:
Speed is key
Once off the line, foods starts deteriorating and needs to reach the customer fast. Interactive elements (such as buttons and text entry fields) should be big in size and provide sufficient contrast from their surroundings so that users don't waste precious seconds wondering where to tap, or correcting mistakes.
Loss of trust could be detrimental
Deliveree's main differentiator is their personalised service and track record of high reliability. Any grammatical errors, UI inconsistencies or inappropriate/unprofessional use visual language could compromise that and must be avoided.
Next we met with Deliveree's CEO and lead developer to further understand the user goals, identify brand values and establish any boundaries or technical limitations going forward with the visual design.

More takeaways:
Restaurant-side first
Place priority on designing the restaurant-side tablet screens first, with secondary focus on the driver-side phone application. This decision was based on the fact that the restaurant application is essentially an externally-facing representative of Deliveree as a company. Pixel perfection, consistency and highly refined aesthetics were therefore of utmost importance in retaining credibility and trust of restaurants.
Keep it professional
Strive for a fresh, modern aesthetic but avoid anything too trendy, artsy or entertainment-related. Restaurants owners need to feel that the app is trustworthy, professional and reliable.
Minimal and engaging
Don't overwhelm the user with unnecessary information or visual noise. Keep the overall interface clean so that the user's eye is drawn instantly to primary CTAs or key information.
Make content glanceable
Make content glanceable. The application is a tool that needs to fit into users often hectic workflow, help them do their job by making information easily scannable and interactions intuitive. Aim to take any guesswork out of the UI.
Consider the multi-sided platform
Consider the multi-sided platform. How can visual design decisions made on the restaurant side be applied to driver the side?
Style exploration

With takeaways from my UX analysis and kickoff meeting in mind, I created three divergent style tiles which I presented to the client.
Client liked the use of blue as a trust invoking brand colour and felt that the soft turquoise CTA provided nice contrast off the background without feeling too harsh. They also spoke favourably about the flat design and the overall fresh, minimal and clean look and feel.
Client appreciated the divergence. Strong contrast between branding and CTA colours aligned well with the goal of creating an easily glanceable interface. There were, however, concerns raised about this visual direction feeling "loud" and veering too far out of the professional realm.
Overall this was the least favoured style. The dark, single-colour palette was too reminiscent of entertainment or gaming interfaces and lacked the impression of trustworthiness that Deliveree was striving for.

The final decision was to proceed with style tile one, which the client felt best met the users needs and represented the image they were looking to portray.

Refining the concept

As I started creating initial screens, I found opportunities to enhance the user experience and better meet the requirements identified earlier. I proposed three changes:
1. Use a custom, numerical keypad on the right side of the customer search screen. As search criteria is strictly phone numbers, this would allow for far easier accessibility and speed of use over the system keypad, which in landscape mode, arranges digits horizontally across the screen and occupies a vast portion of the vertical real estate.
2. Consolidate delivery date and deliver by inputs. The sole purpose of having the delivery date input was to cater for rare occasions when delivery needs to be scheduled for another day. By allowing users to set a date in the deliver by time picker modal, this input could be removed.
3. Change the navigation system. The wireframes were designed to use both side and top navigation menus. I was able to combine this into one top menu. My rationale was that screen real estate throughout the application (and especially on the orders in progress screen) is of high importance.

I pitched these ideas to my creative director who also saw the benefit to users and agreed to have them tested with end users for verification.

User testing approach
User testing session at our workspace; 1871.
When it came to testing, our primary goals were to:

  • Gauge emotional "gut" reaction to designs in terms of how it made the user feel. To do this we shared each screen for a short period of time, followed by a series of questions to establish impressions.

  • Verify that the most important elements were being noticed. Similarly to the above technique, we shared screens with users and asked them to recall what they remembered from what they saw.

  • Determine users ability to understand and identify the primary purpose of each feature. We measured this by questioning users about what their first point of interaction would be, and what they would expect to happen

  • Establish adjectives - at the end of each session, we allowed users to freely explore the prototype and then asked them to select adjectives which they felt were applicable from a large list. We included some related to key brand values, as well as their direct opposites, and a wide array of others in-between.
With the busy testing schedule we made use of Google Sheets to keep on top of it.
High-fidelity mockups

Using my approved style tile, insights gained from client meetings, and UX data I started the process of creating high-fidelity mockups. Along the way I constantly looked to sites like Dribbble, Behance and Pinterest for inspiration and ideas around how others has successfully used visual design language to achieve similar brand values.
First iteration
With our first round of user testing locked in (only two days after having my style tile signed off) I produced mockups of four key pages to put in front of users.
Top left: Customer search. Top right: Delivery details. Bottom left: Orders in progress. Bottom right: Map view showing full details of a single order.
Key insights

  • The orders in progress screen was a hot topic. The circular state indicators (as opposed to arrows) were liked by some due to their modern, minimal aesthetic, while others preferred the arrows. Additionally it was widely reported that the driver information is extremely important, and should be given more prominence.

  • Overall users had no trouble identifying the general purpose of each screen.

  • The simplicity and minimalism of the overall look and feel were applauded, however there were concerns raised that it felt too sterile.

  • Typography was reported as feeling too small in places, particularly the phone number display.

  • There was an overwhelmingly positive response to the on-screen, numeric keypad in A/B tests against the original design. Users felt that it would enable them to process orders much more efficiently.

  • It was pointed out that payment method selector should be grouped with delivery date and ready for pickup fields, in order to maintain clear separation between customer address and delivery details.
Second iteration
My focus for the second iteration was to address issues raised during the first round of testing, as well as experimenting with design concepts that I hadn't had time for earlier.

  • Utilised the blue brand colour in top navigation as a way to rectify the sterile feel, while helping to "box in" and draw focus to the content.

  • Experimented with a combined Customer Search and Delivery Details concept in an attempt to speed up the interaction.

  • Designed a new concept for the orders in progress screen which included full driver information, and replaced the circle event markers with arrows more reminiscent of the wireframes.
Top left: Customer search. Top right: Delivery details. Bottom left: Orders in progress. Bottom right: Map view showing full details of a single order.
Key insights

  • Blue top navigation bar came out as a clear favourite in A/B tests against the previous transparent version.

  • The combined customer search and delivery details screen overwhelmed users and caused uncertainty around what to do first.

  • Users liked the ability to see full driver details on the orders in progress screen. However, the design was described as overly cluttered and overwhelming. Furthermore, users wanted the ability to clearly see expected delivery time and when the order was first placed. While this was included in current layout, it lacked certainty and was far from glanceable.
Further UX enhancements

With both rounds of user testing complete I had some excellent insights and felt good about going forward with my final iteration. However, it had become apparent that the orders in progress screen, with its current design, was not successful enough in meeting user needs.

I dedicated a late-night discovery session to really getting my head around the problem, and started looking at different approaches to better serve the user. The problem I found, was that the screen was trying to do two things at once:

1. Tell restaurant staff the current status of all orders in progress in a clear, a glanceable manner

2. Provide supporting metrics around when each status was reached, and when it was completed.

This approach resulted in a high volume of information and appeared to be what was hindering the chances of either being completely successful.
"I just want to know where the delivery is at, if I want more I can click"
- Restaurant manager
I proposed splitting this information up, having only critical information pertaining to customer, current status, ETA and driver on the orders in progress screen.

The remaining, timeline based information was still highly important to users, however not from a mid-workflow, glanceability perspective. I recommended moving it to the map view page (which is accessed by tapping on a single order). This screen was already geared towards providing supplementary context surrounding the order. Furthermore, there was ample unused real estate which allowed for a more tactical, hierarchical visualisation of the timeline data.

I conducted more research and found that the real value in using staggered progression bars is seen when users are unfamiliar with what the exact steps in the full process are, and need a more holistic view. For this reason it is commonly used in business-to-customer (B2C) products, such as postal tracking services or B2C food delivery services.

In the case of Deliveree — a business tool — users will quickly learn the full sequence of an order, at which point having all states at one time only clutters the interface and ultimately creates distraction from information that needs to be glanceable while in the midst of their busy workflow.

I pitched these changes to my creative director who applauded my dedication to the product and willingness to veer outside the UI realm. I was given approval to include this concept in my final client deliverables on the provisor that I include clear supporting rationale to back up my decisions.
The final product
Restaurant interface
Left: Customer search with multiple results. Right: Customer search with no results found.
Left: Select address modal (if customer has multiple). Right: Delivery Details (with alert showing).
Left: Time/date selection modal. Right: Delivery details screen fully populated (submit button slides up).
Left: Orders in progress screen. Right: Map view showing full details of a single order.
Driver interface
Due to the tight timeframes, we were unable to run user tests on the driver side application. I created mockups for five key screens for the development team to use as a guide, and as a way to illustrate how the visual design language and brand values would translate to a mobile phone platform.
Future considerations

The potential scope for this project far outweighed our allocated timeframe. Given additional time and resources I would:
1. Conduct thorough user testing on the driver side application. We gained enormous value through user testing on the restaurant application and would I see the potential to do the same with the driver app.

2. Conduct thorough testing on my new concept for the orders in progress view. My changes to this screen were well informed and directly based on prior testing results and extensive research. However, without actually putting it in front of the people who have to use it, I cannot verify its success.

3. Implement the solution across a wider range of devices. Both restaurants and drivers are expected to use the solution on devices outside of the ones we designed for. A design effort is needed to adapt current designs to specifications of other devices from an array of manufacturers and screen resolutions.

4. Incorporate micro-interactions to drive engagement, create distinct character in the brand and promote desirability. There are numerous great opportunities in Deliveree to do this, for example:

  • When a new order appears in the orders in progress screen.
  • When an order progresses from one state to another.
  • When all mandatory delivery details inputs are completed and the submit button slides in.

Deliveree was undoubtedly the one of most intense and rewarding projects I've worked on to date. From a personal standpoint, the company and its employees were a joy to work with. As a fairly young company I got a strong sense of, and took inspiration from their drive and ambition to expand. Being around this energy was a buzz, I found myself really connecting with the product and sharing their vision.

The pace of this project was beyond anything I'd experienced in the past. I really learnt the meaning of the phase "perfect is the enemy of good", and that early feedback on less polished work is often more beneficial than waiting and potentially finding myself a long way down the wrong track.

User testing was a huge part of our design process. Getting useful and actionable feedback directly relating to the visual design was often very difficult. My biggest challenge was gaining a tangible measure of success of using the product, without having a comprehensive enough prototype to simulate a real world task in their workflow.

By the end of our final testing cycle I had honed my ability to gauge success of purely visual aspects by clearly emphasising the purpose of the test early on, and constantly refocusing the conversation around visual related specifics (such as legibility of type, contrast and accessibility).

Overall, I feel my solution was successful in meeting the desired outcomes. The visual language effectively portrays a professional, trustworthy and modern image, as well as supporting usability goals of being glanceable and fast. While I made strides to improve on the "sterile" aesthetic of my first iteration, I feel my efforts weren't completely successful and the design would benefit from having more character and boldness. Essentially I may have played it a little too safe, focusing more directly on ticking off requirements while failing to really inject more of my own unique personality into the design.

I am proud of what I achieved for Deliveree, the perseverance I displayed to get there and the extensive learnings I picked up along the way, which I'm looking forward to applying to my next project.
Glen is a proactive and tireless contributor who would make a great addition to any team. From the first day we met at Designation Labs during his study, he brought great designs and creativity to the table, which we implemented into our current UI design. He understood our needs and delivered a design exactly as we hoped.
Daniel Natasag, CEO/Co-Founder of Deliveree Inc.
Phone: +44 073 9948 9025
Made on