sample of miqueas's mobile screens

Miqueas 6.8 Inventory Management System

Streamlining the inventory logging process and clarifying data readability for volunteers.
TIMELINE
January - April '20
CLIENT
Miqueas 6.8
(thru Bits of Good)
ROLE
User Research
Product Design
TEAM
Product Manager,
Engineering Manager,
2 Product Designers,
5 Developers

Overview

Miqueas 6.8 is a non-profit organization based in Honduras dedicated to providing a home and education to orphans. Currently, they house around 40 children and must manage a large amount of food, clothing, educational material, toys, etc.


They use a combination of Excel sheets and a mobile app made in AppSheet to manage their inventory, but as their family grows, they need an application that is more efficient and easy to use.

Research

We were given access to the most current version of the application that they used and were able to talk with some volunteers regarding their experience using the app. From there, we created a user journey map based off of our explorations.

user journey

Ultimate Goal: Improve overall app efficiency.

Constraints

Because we were revamping an already existing app (rather than creating something entirely new), there were some things we had to keep in mind.

  1. No drastic design changes

    We want to reduce the learning curve for the volunteers who are used to the current app.

  2. The system cannot be changed

    Our client expressed that they didn’t want to change how they currently organize their inventory in terms of naming, categorizing, item gendering, etc.

  3. Spanish is required

    Many volunteers do not speak English, so Spanish translations/versions must be available.


Feature 1 : The Transaction Form

The application consists of 2 primary features:

  1. Transaction Form

    How items are logged into and out of the inventory.

  2. Log Tables

    Where transactions and inventory amounts can be reviewed.

two screens of the current app's transaction form

The current form is dynamic as different items in the inventory have different details to specify. However, from talking with our point of contact as well as our personal usage of the application, we discovered some areas of concern in the logging process, all of which contribute to increased error.

1

Items may be of the same name and category, but if the details differ, they must all be logged separately.

2

Forms do not autofill, even when there is only one possible selection option.

3

Category always has to be selected first, so volunteers need to remember the the correct category of the many items.

Solution

In addition to improving the app’s visual design, the main goal for the transaction form was to reduce the amount of redundancy in the logging process. Since the home is far from stores, purchases are often made in bulk and logging many nearly identical forms is tedious and can be prone to error.


The solution? Allowing the duplication of transaction forms and reviewing entries before submitting.

proposed user flow chart for transactions

Designs

screens of the newly designed transaction form

With the new designs, users no longer need to rescan the QR code or reselect the item’s Category and Name when entering in multiple of the same type of item. The ability to review forms encourages volunteers to verify the accuracy of entries and reduce error.


Feature 2 : The Log Tables

two screens of the current app's log tables

The tables are difficult to digest. Volunteers need to look back at these logs occasionally in case of discrepancies in stock and to verify that the children are being treated fairly. However, the information hierarchy is quite poor. A few improvements that can be made:

1

Logs should be instantly available (you shouldn’t need to go through a location selection page first every time).

2

The Inventory should be a single page.

3

Quantity is an important value that should be more easy to see.

Solution

The entire application’s information organization can be adjusted. The current layout is in part due to the technical limitations of AppSheet and thus includes some unused features as well as important information that is hidden. Below are the current and redesigned information architecture maps of the app.

current info architecture of the appproposed info architecture of the app

Designs

screens of the newly designed transaction logscreens of the newly designed inventory log

Because volunteers only occasionally use the tables when recounting stock and double checking discrepancies, much of the information that was previously displayed was removed to reduce cognitive load. Only the most important information (as stated by volunteers) were chosen to be displayed.

Reflections

This was my very first venture into product design and to say that I learned a lot would be a massive understatement. While the product was finished and handed off even despite the unexpected COVID-19 closures, I would’ve loved to be able to speak with the volunteers and learn how they’re enjoying the new application and what more ways we can improve their experience.


In terms of collaboration, I got to experience working with a client and the many technical and creative challenges (and opportunities!) that come with constraints and meeting users where they’re at.


As a whole, I also learned that less is more. In previous iterations of my designs, I often got lost trying to fit as much as possible on a screen, thinking that users would want to see everything. But, from talking with volunteers to other designers, I learned the importance of really capturing what is most vital to users.

→ houml812@gmail.com

→ LinkedIn

handmade by mich

ᕕ( ᐛ )ᕗ