Locker Consumer App

A consumer mobile app for users to collect and return parcels through lockers, in the rising e-commerce scene.

Background

A one week contract work for Singapore's biggest locker network.

Pick network was looking for a headstart in a design of what it would look like if the locker servicers had a mobile app for e-commerce customers.

The brief

To submit a functional high-fidelity prototype of the mobile app showing the parcel return process.

Core competencies

Component LIbrary

User Experience Design

User Interface Design

Interaction Design

Tools

Figma

Google Sheets

Component Library

Consumer Product

Merchant Product

Video Prototype

Image Credit: TheSmartLocal

Detailed Design Process

Continue reading this case study to dive deeper into the design decisions behind the project.

Project Context

User Type

Consumers who are collecting or returning parcels. This does not include businesses/merchants.

User Behaviour

Consumers would only open the app when they need to collect and return parcels. (Non-power users).

Primary task

Take action to collect/return parcels through the app when needed.

Secondary task and edge cases

Search for previous transaction due to high numbers of transactions. 
E.g something went wrong in one of the transactions, users need to search for it.

Points of consideration on the use cases

  1. To differentiate between the different types of transactions.
  2. Differentiate between status, statuses are clear.
  3. Able to find their transactions. E.g we dont want to display old transactions - showing the best method of only presenting the ‘active’ transactions in the homepage.
  4. Utimately, the aim is for users to know which transactions require which actions.

Use Case 1
Differentiating between types of transactions

There are two types of transactions: Collect or Return parcels.

Exploration A
By labelling each card

  • This exploration labels the type of transaction at the top left corner of each card with bolded text.
Evaluation
  • With this layout, cards that require actions are always seen first. Once the users are aware of the cards that require actions, they can figure out the action to take: Return/Collect. This may reduce the users’ cognitive load.

Exploration B
Categorizing the type of transactions by sections

  • Type of transaction categorized by sections.
  • Vertical scroll to view Collections vs Returns transactions.
Evaluation
  • Cons: After expanding the ‘Collections’ section, ‘Returns’ will no longer be above the fold/viewport. Discoverability for ‘Returns’ will be bad.

Exploration C
Categorizing the type of transactions in the two tabs

  • Type of transaction categorized by page tabs.
  • Layout options: Tabs at the top vs bottom of the page
Evaluation
  • Pros: Return/Collections transactions are not stacked together, user can easily find it based on what they already planned to do.
Tabs at top of the page
Tabs at bottom of the page

Conclusion

Exploration C: Tabs + Refining

  • Exploration C categorizes the types of transactions well, however if the transaction is the one hidden in the tabs, it may not be as discoverable.
  • Using notification indicators helps users to understand where to look.
Conclusion
  • The pros in this layout outweighs the others as it requires the least cognitive load from users.
Notification Indicator to draw user to the category that requires their actions. It does not clear until action is resolved

Use Case 2
Differentiating between status + statuses should be clear

The primary purpose of statuses are to indicate to the users which cards need their attention/action.

For example: (Returning of parcels) Statuses include: To deposit, deposited, returned, expired, with "To deposit" being the one that requires action.

Exploration A
Indicate different statuses by text

  • Why are statuses not coloured?
 This is because I wanted to draw attention only to the cards that require actions.

Exploration B
Indicate different statuses by text, colors and icons

  • Visual exploration by differentiating different statuses with colors and icons.
Evaluation
  • Cons: The varying colours and icons are distracting and takes attention away from the cards that require actions.

Exploration C
Indicate different statuses with subtle varying colours

  • Visual exploration of giving the status tags a lighter color.
Evaluation
  • Cons: The varying colours and icons are still rather distracting and takes attention away from the cards that require actions. Users may not know where to look.

Conclusion

Exploration A + C
Indicate different statuses with text and varying color, based on action status

  • There are two main use cases for the cards: to take action, or not to.
  • Reserving the coloured status for action-based cards makes sense.
Conclusion
  • Colors draw visual emphasis. I intentionally used colors to bring attention to the user where action is needed. With this, use case 1 and 2 are clear.
  • Ties back to the objective which is to lead users to take action.

Use Case 3
Finding specific transactions

Consumers are able to find their transactions. Whats the best method of only showing the active transactions in homepage.

Exploration A
Sort by: Latest as default

Logic for sorting:
  • Transactions that require actions / (has CTA buttons) will be surfaced at the top of the list
  • Sorting feature dropdown: by latest / oldest
Evaluation
  • Pros: basic sorting function covers edge cases of users who are searching for older transactions.
  • Assuming on an average, a consumer has 3 parcel transactions a month. Over 3 months, they would only have 9. Over 1 year, they would only have 36. Latest/Oldest would suffice.

Exploration B
Archive Features

  • Once a transaction is completed, the user can archive it, so it is no longer in the list of transactions in the homepage
Evaluation
  • Cons: Highly manual
  • Doesnt help the user with its primary task
  • Dev cost to build archive feature not proportionate to value it will bring to user, estimated only 20% users will use
  • (Not mocked up as we decided that the exploration is not worth pursuing)

Exploration C
Sort by + Search

  • The idea of a search function would allow users to search for the Parcel Tracking ID or Transaction ID.
  • An advanced search filter could allow users to search by the date range.
Evaluation
  • Pros: Search function serves the edge cases of users who are searching for older specific transactions.
  • However, estimated less than 20% of users would use the search feature if the basic sorting logic covers primary use cases.
  • Users on this app do not have to be power users as it only serves very basic use cases.
Tabs at top of the page
Tabs at bottom of the page

Conclusion

Exploration A: Sorting

    Conclusion
    • The basic sorting feature (Latest) covers the primary use case for consumers to take action where needed.
    • Vertical scrolling suffices because relevancy of transactions goes down as time passes.
    By default, cards with ‘To deposit/To collect’ statuses will be at the top and highlighted.

    Design Explorations:
    Transaction Details Page

    The primary purpose of the transaction details page is to provide relevant information for users to complete the action.
    These include: Location of the lockers and the date when the transaction will explre.

    Exploration A: Sorting

    Evaluation
    Pros:
    • Information is categorized. If the user knows what they’re looking for, read the header tab > tap on the tab
    Cons:
    • Doesn’t follow users mental modal of expecting the details page to just list details down. Users may think: ‘Why is there another folder?’
    • Too many clicks to uncover information, discoverability is not ideal.

    Exploration B: Cards in a vertical scroll

    Evaluation
    Pros:
    • At one glance, we can see all the primary information that the consumer needs to make a return. Secondary information can be expanded with ‘See more’.
    • Action-centric information hierarchy: Parcel Dimensions is still in the viewport, even though its not the most important thing they need to see, but it is still discoverable and visible if they are looking for it.
    • Cards are visually consistent to homepage/brand

      Conclusion

      Exploration B: Cards in a vertical scroll

      • The cards layout provides better discoverability for users.
      • Discerning between what is primary and secondary information and placing them in the collapsed and expanded version helps decrease users cognitive load and improves discoverability.

      Design Explorations:
      Return Parcel Flow and Actions

      Consumers can choose between three options to return the parcel (via Access keycode, Bluetooth, or QR Code)
      
The steps to return should be clear and easy to follow.

      Exploration A: Bottom sheet

      Evaluation
      Pros:
      • Users can end the flow anytime easily
      Cons:
      • Weird to scan bluetooth in a bottom sheet, conventionally its done full page modal.
      • If user accidentally swipes down, can they still pick up where they left off from before. If it’s still possible then this option is not out of the window.

      Exploration B: Full page modal

      Evaluation
      Pros:
      • Scanning bluetooth in a full page page is more conventional on mobile
        Cons:
        • If the user wants to end the flow midway, it is harder to do so. However, this is designed with intention as we would like the user to follow through with the flow.

        Conclusion

        Exploration B: Full page modal

        • The full page modal is more conventional and suitable for a flow with more than 3 steps required from the user.

        Learnings and Takeaway

        Design takeaways

        • Designing for the attention of users. Centering design decisions based on the primary use case of the user at calculated moments.