Redesign of Zulzi grocery delivery app

Industry

E-commerce & Groceries. Servicing South Africa.

What is Zulzi?

Zulzi is an online platform where you can order groceries and have those items delivered to your door within the hour. At this time, Zulzi was shifting from delivering products supplied by local retailers (such as Pick ‘n Pay, Woolworths, Clicks, Dis-Chem etc), to sourcing and supplying those products directly.

My focus was primarily on the customer App for iOS & Android devices, although Zulzi also has a customer facing website, staff facing apps for the shoppers and drivers and a portal for the merchants. 

The design team

We were a small design team of 2 and the first in-house designers in the company. When we joined the project, the first iteration of Zulzi 1 was live whilst version 2 was still in progress. Version 2, which was set to go live within the following 6 months, was a complete rebuild of the app. A lot of work had been done by a previous agency which our internal team picked up to evaluate and complete for the launch date.

In order to effectively evaluate the state of the designs as they were, we decided to do a UX audit which consisted of a Heuristic assessment and also having a look at the Accessibility. 

 Splash:

1. We could add defined branding (and the company name) as this is the first screen the user will see. This is not a usability problem, but it could definitely be improved to familiarise new users with the brand.

2. Repetitive heading and paragraph, explore better use of copy.

3. The button sizes vary based on length of copy, we can standardise size of buttons and their placement regardless of the copy length.

   [Consistency and standards]
   Recommendation: Decide on a button pattern and apply it throughout.

 Get started:

1. The label “Explore” does not clearly clarify what this button does. It should help users anticipate and understand what it means to select this button.

   [Match between system and the real world]
   Recommendation: Look at the label copy and placement.

2. There is a general lack of context on this screen with almost no information. We need to add more more context / clarity, especially because the heading ‘Get started’ is so vague.

   [Match between system and the real world]
   Recommendation: Add copy below the heading for more context. For example “Simply enter your cellphone number below in order to register for the service.”

3. Buttons for ‘Explore’ and ‘Use Email/Cell’ are styled the same yet have different purposes and results. The one allows you to switch the log in method on this page, whilst the other allows you to bypass this flow and view the app in guest mode.

   [Consistency and standards]
   Recommendation: Investigate better toggling buttons and standardise how tertiary buttons are used.

4. Page button placements differ from other app sections (some are located at the bottom of the screens whilst others sit just below the content).

   [Consistency and standards]
   Recommendation: Decide on a button pattern and apply it throughout.

Verification / OTP:

1. What happens when the user enters the wrong code?

   [Help users recognise, diagnose, and recover from errors]
   Recommendation: Include error messages and look at copy presented to the user.

2. Is there a limit to the amount of times the customer has to enter the code?

   [Error prevention]
   Recommendation: If so, list the information upfront (potentially during the error state).

3. The “resend code” button does not match any tertiary button styling.

   [Consistency and standards]
   Recommendation: Confirm pattern/library and update throughout.

4. Inconsistent use of the disabled button in terms of size, colour and placement.

   [Consistency and standards]
   Recommendation: Standardise & document all buttons and apply it throughout.

5. The Back button should be listed on top nav level to allow the customer to go back to the previous screen (which is where the number was entered).

   [Consistency and standards]
   Recommendation: Reference the back button used in other sections, such as “Help”.

6. Is there an easier way for existing customers to gain entry into the app? At the moment the token expires and the user is forced to go through the entire log in process (cell number & OTP).

   [Flexibility and efficiency of use (Accelerators)]
   Recommendation: Don’t let the token expire or explore faster log in methods such as biometrics for return users.

Enter details:

1. Fields are not marked as mandatory or optional so it’s unclear to the user what’s expected.

   [Error prevention]
   Recommendation: Clarify which fields are mandatory and which are optional.

2. What are the error messages? (Especially for Email and Password)

   [Help users recognise, diagnose, and recover from errors]
   Recommendation: Include error messages and look at copy presented to the user.

3. What are the password requirements?

   [Error prevention]
   Recommendation: We should inform the user upfront about the password requirements or restrictions as to avoid them making a mistake before informing them.

4. Try more scalable content like “By continuing you agree to the Zulzi Terms and Conditions” so that the label of the button does not affect the disclaimer content.

   This is not a usability issue, but it would require rework if the button label was changed. This is also a good copy method to follow for referencing dates, for example, instead of writing “we launched two years ago” rather state “we launched in 2018”. That way, you don’t need to rework the content every year.

5. The user should have access to the Terms & Conditions if this is something they ‘agree’ to, even if informally.

   [Help & documentation]
   Recommendation: We should add a link to the Terms & Conditions from this disclaimer, even if the user only views it.

Delivery details:

1. Explain why the address is needed after registration and before they can access the home page, since this is a mandatory step and not clear as to why it’s needed.

   [Match between system and the real world]
   Recommendation: Add additional content on the page before the search feature.

2. Active and empty state font colours are the same. This is not recommended as it causes confusion between completed and incomplete states.

   [Consistency and standards]
   Recommendation: Establish UI for populated and empty states of fields.

3. It’s unclear that you need to select the populated address in order to proceed with the flow.

   [Consistency and standards]

4. How often is the map feature used instead of search or current location?

   [Aesthetic and minimalist design]
   Recommendation: If this feature is rarely used, rather emphasise the search function for finding an address.

5. “Choose on map” button does not match the tertiary button UI.

   [Consistency and standards]
   Recommendation: Standardise tertiary button UI and apply it throughout.