Production line
Role: UX/UI designer from conception to completion Duration: May 2021 (one month)
Project vision.
Production Line is an inventory management app with an emphasis on tracking items used in work orders. Production Line strives to accurately track raw materials as they are turned into finished goods and make sure that the correct people are assigned tasks.
Target users: Individuals who oversee a team of people creating items in a business environment.
GOALS.
Track inventory in real time through different stages and multiple hands.
Be able to order efficiently based on accurate inventory tracking.
Have the correct number of finished goods created by capable team members.
Research
Focused on interaction design, I was devoted to designing a simple and efficient sitemap to help users accomplish their tasks.
I found that qualitative research methods were the most useful to find applicable features and user-flows.
This research included competitive analysis, user interviews, and persona hypothesis construction.
Competitor Audit.
I looked at several inventory management programs, most of which were only fully functional on a computer. Many of these programs were primarily for running reports on inventory data and keeping track of static inventory. I only found one computer program which offered work order integration, but it was very expensive and complex.
Product Line has the opportunity to capitalize on these gaps by offering of a mobile app with the capability to track inventory through stages by way of work orders.
User personas.
5 people were interviewed who either ran or worked in an inventory department at small to medium sized companies.
I took their interviews, synthesized the information, and formed personas.
Wireframing and Usability Study.
After creating wireframes in figma, I conducted an unmoderated and remote usability study with 5 participants.
They performed various tasks and provided feedback that I used to iterate and create mock-ups. I found that:
Users want consistent wording and terminology. They would also benefit from a definitions page so that everyone is clear on the meanings of certain terms.
Users want more straight forward paths with less deviation opportunities.
Users want prominently displayed due dates.
I went back and fixed the wording and then made some modifications.
Removed the option to reprioritize at every step in favor of adding due dates. Both simplifying pathways and allowing the team member to know when an item is expected.
Removed option to view information about each item. That information can be viewed in a different app feature and distracted users.
Added a stepper so that the user could stay focused on their task.
Mock-ups and high fidelity prototype.
Style guide:
The high fidelity prototype for the admin version can be viewed here: Production Line admin high-fi prototype
The high fidelity prototype for the team-member version can be viewed here: Production Line team-member high-fi prototype
Assessing Goals.
TRACKING through various stages and multiple hands:
“In progress” box to be checked by the team member after they collect the materials they need to complete that work order.
The administrator can view which work orders have already collected materials and which have not and who has any material at any given time.
EFFICIENT ORDERING:
Accurately keep track of inventory to know when to order.
The inventory amount is adjusted as soon as a work order is in progress.
Alerts are assigned to each item to let the administrator know when the amount is running low.
The admin will know about the low stock sooner and have a chance to reorder sooner.
CORRECT ASSIGNMENTS:
Have qualified people do the correct work orders.
I added chips that list team member’s skills.
Each finished good has a list of skills required; the app automatically filters out people without the skills when the work order item is selected.
Takeaways
While designing Production Line, I learned that the first ideas for the app are not always what need to be addressed. Through usability studies and feedback I found that my initial assumptions were actually just symptoms of an overlying cause. What users really needed was a solution to the root of the problem. It is important not to hone in on specific problems, but to always ask why. By broadening my view of the issue I was able to efficiently find a solution to all of my challenges.