Design Process

01. Discovery Phase

Who are the users?

I met with product management to find out who the users are that I am designing for so I would be able to ask specific and straightforward questions in stakeholder interviews moving forward.  

• Inventory Manager - The Inventory Manager is in charge of buying, maintaining, and managing the allocation of physical assets throughout a hospital. They have the challenge of knowing where all hospital equipment is and what condition the equipment is in at all times.

• Nurse Manager - The Nurse Manager manages the schedule, duties, and whereabouts of nurses that report to them. They also need to be able to locate and contact doctors on behalf of patients throughout the day. 

• Nurse - The nurse spends time caring for patients and making sure they have all the medical equipment and medication they need.

App Audit, Existing Design Work Audit & Internal Stakeholder Interviews

• I kicked off the project by doing an audit of the non-MVP built application and of the previous designer’s work I would be taking over to gain an understanding of how the new features will work with the overall application and how much work was left to do. 

• I spent a week conducting 1-on-1 in person internal stakeholder interviews (pre-pandemic) with product managers and engineers to discuss what has been completed and what still needs to be done.

• I was unfortunately not able to conduct my own user research for this project so I learned everything I could about the users by speaking with the product manager who had done the initial market research to understand product market fit.

• I was put on this project when product management was very busy so I stepped in to help gather and document the product requirements for this release.

I surveyed the below designs to be able to define what work was left for me to do. These four major features were the last projects that needed completion prior to MVP launch and I was tasked with finishing them so they are engineering handoff ready.

02. Define Phase

Design Goal

Iterate on and complete the current designs for the final four features needed to complete the MVP release.

What I learned about the personas we are designing for

1 - Inventory Manager

Looking for ways to improve how they locate and track hospital inventory to make better informed equipment purchases that are based on more accurate equipment allocation and usage data. The Inventory Manager is in charge of buying, maintaining, and managing the allocation of physical assets throughout a hospital. They have the challenge of knowing where all hospital equipment is and what condition the equipment is in at all times.

• Pain Points: Needs better ways to locate and track hospital inventory because a significant amount of equipment goes missing each year, costing the hospital a lot of money. It’s difficult for them to know and manage the status of all equipment because equipment status relies heavily on human reporting. Current processes make it hard to purchase accurate amounts of equipment because they often do not know the real world counts, locations, and current condition of all equipment in the hospital.

• Goals: They are motivated to improve processes that enable them to have greater visibility and control over all the equipment they manage in the hospital.

2 - Nurse Manager

Wants to spend less time tracking down people and hospital equipment. The Nurse Manager manages the schedule, duties, and whereabouts of nurses that report to them. They also need to be able to locate and contact doctors on behalf of patients throughout the day. Nurse Managers also need to be able to locate hospital equipment in real time for the nurses they manage.

• Pain Point: They spend too much time searching for equipment and people during their shifts, the process is inefficient.

• Goal: Spend less of their day tracking down nurses, doctors, and equipment so they have more time to spend with patients and complete their other tasks.

3 - Nurse

Wants to spend less time tracking down hospital equipment so they can spend more time with patients. 

• Pain Point: They spend too much time searching for available equipment for their patients, it takes away from their time to spend with patients.

• Goal: Spend less of their day finding available and clean equipment for their patients.

four major Features needed to be completed to launch the MVP

1 - Report Builder

Inventory Managers need to be able to create custom reports that support them in viewing and managing their inventory by telling them where their assets are, how they are being used, how many there are, and what condition they are in.

2 - Custom Information Field Builder for Tags (i.e. Assets)

This feature is essentially a form builder that allows Inventory Managers to define which asset information is required to be recorded each time an asset is imported into the Where application. These information fields are a primary way assets are identified and searched in the system. 

3 - Redesign of Bulk Tag Import Feature

This feature allows Inventory Managers and Enlighted support technicians to import large quantities of tags at one time that represent People and Object assets in the system.

4 - Redesign of Tag Status Filter

The tag status filter appears in different features throughout the application and allows users to filter large quantities of tags quickly by live status selection to get to a specific set they want to see. Object asset tags represent objects like wheelchairs, IV pumps, and patient beds and have statuses like “moving”, “broken”, “in repair”, and “soiled”. People asset tags represent specific individuals that fall in predefined categories like nurses and doctors and have statuses like “moving”, “not available”, and “busy”.

I worked on the features in order of priority based on the engineering timeline

1st priority - Report Builder

2nd priority - Custom Information field builder for tags

3rd priority - Bulk asset tag import

4th priority- Tag Status Filter

Final Note: My goal was to maintain as much of the previous designer’s work for the report builder and custom information field builder feature as possible but make changes and add functionality where needed based on ongoing feedback sessions with engineering and product management.

The Problem

Software functionality problem:

Early versions of Where are not ready to be customer facing because they lack the full functionality necessary for Inventory Managers, a primary persona, to track and manage assets in their hospital. The MVP version is the first customer-facing release that will have all the functionality necessary for users to track and manage object assets in Where.

Problem Where wants to solve in the market:

Hospitals struggle to use their equipment assets and medical professionals as efficiently as possible because they are under pressure to constantly do more with less while still maintaining optimum patient care.

1st Feature

Report builder DESIGN PROCESS

02. define

What am I changing and/or adding in the current design before it can be handed off to engineering?

After surveying the current designs and meeting with product management and engineering teams I was able to define what was missing in the designs and what sections may need more design iteration prior to engineering handoff.

03. DESIGN, VALIDATE, ITERATION PHASE

Design Explorations

• The current design has preliminary filter components but I wanted to make the filter section easier to scan and use since it’s the primary function in the reporting feature.

• It’s important that Inventory Managers can easily scan and see all filters that are applied to a report since the filters dictate the content of the report.

Defining all reporting states proved to be more complex than originally thought

I mapped out all the interactions and available actions for creating and sharing new reports and editing saved ones for both live and historical reports. I used this to refine the requirements for the states.

04. results & Implementation phase

Final Designs & Engineering Handoff

I created both redline high fidelity documents and matrixes showing different states of the feature. I spent a lot of time sitting next to engineers as questions came up about this feature during development since this feature is complex and contains a lot of different states.

Final filter selection panel & filters

First page of feature

Supporting documents showing feature states

Outcomes

• Successful launch of a robust report builder feature that Inventory Managers can use to set specific parameters to view customized live or historical reports of their equipment inventory.

• Straightforward report sharing UI that allows Inventory Managers to setup recurring reports to their team members.

2nd Feature

custom tag information field builder design process

02. define

What am I changing and/or adding in the current design before it can be handed off to engineering?

After surveying the original designs and meeting with product management and engineering teams I was able to define what was missing in the current designs and what sections may need more design iteration prior to engineering handoff.

03. design, validate, iteration phase

Round 01 designs

• I added the ability for users to make fields required or optional since I hypothesized this is a product requirement and was able to validate it with product management.

• I added the ability for users to change the order of the fields since their order in this feature is maintained throughout all other instances

  • The order of this information is especially important in the tag detail panel since users typically read left to right and top to bottom. (see below for tag detail panel screen)

• I explored components that support moving field position

Why custom field order and the ability to make a custom field optional or required is important

• The asset detail panel shows all the information available for an asset tag, the custom field information inside it displays information specific to the asset not the tag hardware attached to it.

• The ability to make a custom field required will ensure that all the asset tags in a system have the same field of information.

The custom field and moving components so far seem too cumbersome and tedious to use. I made the mistake of trying to design this feature from my database of experience and realized I am actually just trying to build a form building user interface. I have no experience designing form builders so I decided to pause the design exploration and research design pattern conventions for form builders.

I cherry picked the best parts of the form builders I saw in Google Forms and Type Form and incorporated them into our feature.

This feature is essentially a form building interface that enables Inventory Managers to create custom form fields for the assets they add to the Where application.

• I decided to expand on the current design and make the form building component of the feature operate more like a typical form building UI that users may have seen if they ever used Google Forms, Survey Monkey, and Typeform.

• My goal was to make this feature as easy to use as possible since I hypothesize that inventory managers do not create surveys and forms regularly.

Round 02 Designs

• Users can now hover over a custom field component and drag the component to change the order

• Added a “Preview Template” option so users can see what their custom field order will look like in the add tag form and the tag detail panel

04. results & Implementation phase

Final Designs & Engineering Handoff

I created redline documents for engineers to reference and spent time sitting next to engineers as needed when they were developing this feature.

Changes from Round 02 designs

• I changed the form factor of the custom field components in the final designs because the custom fields may not always display as two columns throughout the application in the future.

• I simplified the preview screen for the final design because the preview screens I developed in Round 03 were too complicated to implement for this MVP release and the preview templates would have to be swapped out if the designs ever changed.

• I created redline documents for engineers to reference and spent time sitting next to engineers as needed when they were developing this feature.

Outcomes

• Successful launch of a custom field building feature that allows Inventory Managers to define what information must be entered every time an asset tag is added to Where so that it can be properly identified and tracked once it’s added.

• More powerful asset tag search capabilities since users can now search by the information in the custom tag fields.

• Asset detail panels now contain information that is specific to the assets attached to the hardware tags and not just details about the tags.

3rd Feature

Bulk tag import design process

02. define

What needs to be done with the current design to get it ready for the MVP release?

I was given this feature to redesign because earlier built versions of it did not support the growing functionality of the system in the MVP release.

03. design, validate, iteration phase

Pattern research to learn best practices

1 - Testing bulk import features in other apps to survey how they share import errors with the user

• I started this process by surveying how other apps handle bulk importing by creating and importing dummy spreadsheets with known errors to see how errors are handled.

• My goal was to make viewing and correcting errors as painless as possible for users since they were likely to be importing very large quantities of tags, getting error messages creates anxiety for people.

• I primarily looked at how Salesforce handles errors in their bulk user import feature and cherry picked the best parts and incorporated them into our feature.

2 - Surveying how other apps handle data table responsiveness across screen sizes

• I had to make the import table responsive so it could accommodate a variable and limitless number of columns.

• The challenge was making the table responsive in a way that maintains the header cell to the corresponding data cell relationship so users can easily scan and understand the meaning of cell values.

• I looked at how noteworthy apps like Dropbox, Monday, and Google Docs handle their data tables across different screen sizes.

Round 01 design

Round 02 designs

I abandoned the modal to show errors and explored showing errors directly in a spreadsheet format so that the location of errors is a 1:1 relationship with the errors in the users imported spreadsheet.

04. results & Implementation phase

Final Designs & Engineering Handoff

I created high fidelity redline documents for engineering and created a spreadsheet spec of all the errors than can happen in an import. I created the error spreadsheet doucment to make sure the error messaging is as clear as possible for users. I also created several specification documents describing table responsiveness since column count is variable and can exceed thirty columns.

Changes made to original design

• Made header row and header columns sticky to support horizontal and vertical scrolling under headers to maintain header and cell value relationship.

New UI added to support user needs

• Added list of errors to give users a way to see all the errors in a single list.

• Added sticky column for import results showing either success or errors for tags.

• Made table sorted by import state by default so users can immediately see which tags have errors.

• Added hover states for errors that display reason for error to facilitate easy error correction.

Outcomes

• Successful launch of a redesigned bulk import feature that allows users to view import errors in a 1:1 relationship with their original imported document.

• Easier scanning of errors and faster error correction.

• Responsive import status table that can accommodate a variable quantity of columns and work across different screen sizes.

4th Feature (final)

Tag status filter design process

02. define

Why does the status filter need to be redesigned?

• The current status filter was designed for an early version of Where that only supported one type of tag status and a short list of statuses.

• The filter now needs to support three types of statuses and will potentially be a much longer list to choose from, the see groupings of the three status types.

• The current dropdown menu status selection is cumbersome to use when multiple status selections are needed.

03. design, validate, iteration phase

Design Goal

Make the status filter list:

1. easily scannable across the three groups of statuses

2. make it as quick as possible to select statuses

Design Explorations

Final Design

04. results & Implementation phase

Final Designs & Engineering Handoff

I produced redline engineering documents of the final designs for web and mobile (iOS & Android).

Outcomes

• More scannable list of statuses to filter large quantities of tag assets, grouped by status type.

• Quicker user selection and clearing of status filter component across all instances in application.

Outcome

• Successfully designed and shipped the final features needed for the MVP and first customer facing release of Where.  

• Facilitated a fully functioning asset tracking and management application for hospital customers.

retrospective

I am grateful for this project because the challenging and complex nature of it required and empowered me to grow quickly as a product designer in a relatively short amount of time. This was a challenging project due to the amount of meetings and time it took to uncover and refine all the feature requirements for this complex system. A finalized feature requirement document ended up being a continuously moving target during the process because I often uncovered new requirements during my design iterations of the more complex features that I had to confirm and refine with engineering and product management.  Many curveballs appeared during both the design and development process that required the engineers and I to come up with quick design solutions. I am sure the final solution for each feature suffered some from not doing usability testing with users but I believe that we did the absolute best we could with the resources and time we had.

Go to next case study >>