Design Process

 

01. DISCOVERY PHASE

The users

Hospital Inventory Managers are the primary users of this feature. They are in charge of buying, maintaining, and managing the allocation of physical assets throughout a hospital.

They have the constant challenge of managing the hospital equipment under their watch and minimizing equipment theft, loss, and damage. These managers are responsible for maintaining and tracking massive amounts of equipment and most are open to new processes and technology that can help them.

 

This feature allows Inventory Managers to import large quantities of asset tags at one time into Where.

 

app & design Audit

I did an audit of the current bulk tag import sequence to identify the sections that needed updating to support a larger and variable list of information for each imported tag.

1 - Create and upload tag import spreadsheet

2 - Review import errors, correct them, import again

3. Review the imported tags & save to finish import

 

02. DEFINE PHASE

 

The Problem

The current import feature makes viewing and correcting multiple import errors tedious and cumbersome.

 

Design Goal

Show users their import errors in a format that makes it easy to view their errors and quickly correct them in their tag import spreadsheet document so they can import again with success.

 

DESIGN plan

Current error handling modal (below)

Current import table (below)

1 - Improve error display

  • The Inventory Manager needs to be able to easily match the error message with the matching value in their spreadsheet to correct it before they can import the document again.

  • Current error handling modal will not scale well for a large amount of errors


2 - Make import table responsive to be able to support large quantity of table columns 

  • I had to make the import table in this feature responsive because this MVP release supports custom tag information fields that will add more columns to the table.

  • This will be a problem for users to view the table if there are a lot of columns and/or if they are viewing it on smaller screens.

 

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 designs

I explored keeping the current design’s error modal format but improving the error messaging within it. The modal was the easiest solution for engineering to implement, but not necessarily the best for users.

Import error modal (below)

Problem with this approach

  • After users import their spreadsheets and have to read errors from a list that is a tedious to make a one to one comparison with spreadsheet cell errors.

  • A scrollable list inside a modal only works well if the list is not very long (i.e. less than 15 or so errors)

    • Scrolling through more than 15 errors could become bewildering and exhausting for users

 
 

Round 02 designs

I abandoned the error modal 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 user’s imported spreadsheet.

 

Collapsed error view (below)

Expanded error view (below)

Problem with this approach

  • The errors in the spreadsheet cells indicated with red font may not be readable for color blind users.

  • I proposed this design to engineering and the variable row height in the expanded cells would be too much effort to implement for the MVP.

 

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 document 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.

Table showing errors

Hovering over an error shows the reason for the error

Expanded view of the error list, a secondary way to view errors

Table with no errors

 

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.

 

Table responsiveness spec document

Created an error message grid for user facing import error messages

 
 

Outcomes

  • Successful launch of a redesigned bulk import feature.

  • Improved import error handling for faster error correction.

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

  • Defined all possible error messages to ensure error message consistency and clarity.