Company
Expeditors, a Fortune 500 logistics company based in Seattle
Role
UX Designer
Product
exp.o Visibility is a web-based reporting tool that lets Expeditors' customers access their logistics data (shipments, orders, customs, and inventory), as well as view electronic document images. At the time of this project exp.o Visibility had about 30,000 external users and 10,000 employee users.
Project summary
For convenience, our users would typically schedule a report to run on a regular basis and have the results emailed to them as an attachment (e.g. as a .xlsx or .csv file). Expeditors management decided to disallow the emailing of report attachments, and instead require that users sign in to access their results online. The rationale given for this decision was that it would ensure that only authorized individuals would be able to see sensitive business data.
Problem
We knew that many of our customers and employees received report result attachments via group email addresses and shared inboxes. We also knew that not all of these users were authorized to see the reports online, so once email attachments were turned off, they wouldn’t be able to access results.
We also had a hunch that employees at branches were using group email addresses to receive report results so that they could use incoming results as operational triggers to kick-off workflows, and to have team visibility to tasks that were pending.
We needed to understand why group email addresses were used to receive results so that we could figure out how to best support the use cases.
Research/Analysis
Interviews
We interviewed 3 branch employees that received exp.o Visibility results via a group email address. We didn’t always have access to customers for research purposes, so we'd sometimes use employees as a proxy. In this case, our employees were also report recipients and users of the system.
We interviewed 3 branch employees that received exp.o Visibility results via a group email address. We didn’t always have access to customers for research purposes, so we'd sometimes use employees as a proxy. In this case, our employees were also report recipients and users of the system.
Excerpts from initial analysis document
Interview findings:
- Two out of the 3 employees I spoke with indicated there was no workflow in place for report results. Results for customer reports went to a shared mailbox/database for the purposes of “just in case.”
- One person did have a workflow, but it did not appear to be part of a team queue. She received one result daily, which she would format/filter as needed and share with the customer. The result went to a shared mailbox in case she was out of the office.
Our next step was to cast a wider net via a survey to validate what we learned in the interviews.
Survey
After first piloting the survey with 10 participants, we sent the final survey to 87 participants. The results supported what we learned in the interviews, which is that group email addresses were used to ensure everyone on the team had visibility to their customers' reports, either as a best practice or to ensure continuity if someone was out of the office.
After first piloting the survey with 10 participants, we sent the final survey to 87 participants. The results supported what we learned in the interviews, which is that group email addresses were used to ensure everyone on the team had visibility to their customers' reports, either as a best practice or to ensure continuity if someone was out of the office.
Excerpt from survey, and resulting user stories
Design
Brainstorm
In brainstorming sessions, one suggestion from the team was to build functionality that enabled report owners to create and manage groups within exp.o Visibility. I didn't like this approach for 2 reasons:
In brainstorming sessions, one suggestion from the team was to build functionality that enabled report owners to create and manage groups within exp.o Visibility. I didn't like this approach for 2 reasons:
- It put the onus on users to remember to sign-in to the application and manage the group every time someone needed to be added or deleted. exp.o Visibility is just one of many applications and systems that our customers use every day, so this was an unrealistic expectation.
- It was an over-engineered solution that would require a lot of work to build and maintain.
Instead, I looked to applications like Google Drive and Analytics to understand how they approached the problem of someone trying to access a file or report they didn’t have access to.
They solved it by displaying a “You need access” page like the one shown below. When the user selects the “Request access” button, the owner of the file/report is notified, and they can choose whether or not to provide access. I felt this solution would work for us because it would:
- Be fairly simple to implement and maintain.
- Be easy for our employees and customers to understand and use.
- Solve the problem of providing report visibility to members of group email addresses.
Request access feature in Google Drive
User Flow/Wireframes
The team didn't connect with this idea right away, probably because it solved a general problem of providing access rather than addressing email groups specifically. I demoed the Google Drive functionality to our Technical Manager, and collaborated with him to create the following user flow to illustrate how this would work in our application. Once he agreed to the approach, the rest of the team was on board.
While the initial version of this feature would require a report owner to log into exp.o Visibility to add the recipient, or submit a request to our Support team, future iterations would streamline this process.
The team didn't connect with this idea right away, probably because it solved a general problem of providing access rather than addressing email groups specifically. I demoed the Google Drive functionality to our Technical Manager, and collaborated with him to create the following user flow to illustrate how this would work in our application. Once he agreed to the approach, the rest of the team was on board.
While the initial version of this feature would require a report owner to log into exp.o Visibility to add the recipient, or submit a request to our Support team, future iterations would streamline this process.
User flow
Mockups/Solution
I designed a simple request page inspired by the similar screen in Google Drive, using content that would make sense to our users. This is the design that was implemented.
I designed a simple request page inspired by the similar screen in Google Drive, using content that would make sense to our users. This is the design that was implemented.
Screenshot of solution
Beta Test
Once the feature was implemented, we conducted a beta test with employees and surveyed them to understand if we needed to make any changes before rolling this out to everyone. We surveyed members of email groups to get their feedback on the request access process, and we surveyed the report owners to get their feedback on the notification email and steps they had to take.
Once the feature was implemented, we conducted a beta test with employees and surveyed them to understand if we needed to make any changes before rolling this out to everyone. We surveyed members of email groups to get their feedback on the request access process, and we surveyed the report owners to get their feedback on the notification email and steps they had to take.
We learned that:
- The email notification needed to provide more guidance on the steps needed to approve a request.
- Over 30% of requestors weren't notified by owners when their request was approved. This feedback helped us improve our communications to report owners for the larger rollout.
Survey results from requestors was mostly positive
Additional steps
There were a few additional steps we took to ensure the launch went as smoothly as possible for our employees, customers, report owners and Support team:
There were a few additional steps we took to ensure the launch went as smoothly as possible for our employees, customers, report owners and Support team:
1. Prior to launch we reached out to report owners to collect email addresses for members of group emails that were listed as recipients on their reports. We then added these individual email addresses as report recipients. This ensured that once attachments were turned off, these individuals could immediately access their results, and would help prevent our report owners and Support team from being overwhelmed by initial requests for access.
2. Employees had access to an internal reporting system called Report Writer, which delivered reports to users via exp.o Visibility. This was a legacy system that had no validation in place for the report owner field. Our solution depended on having quality report owner data, so this was a huge problem. In order to remedy this we:
- Made report owner a required field, and validated that the value entered was the email address of a current employee
- Identified all invalid report owners, and manually cleaned up this data by replacing them with valid owners. This was a tedious job but absolutely essential to the success of the project.
- Put a process into place to audit report owner data on a regular basis.
Conclusion
The keys to success with this project were:
- Conducting research to understand why group email addresses were used.
- Getting buy-in from the Technical Manager on the proposed solution.
- Beta testing the solution to work out any kinks before rolling it out to everyone.
- Adding as many group email members as individual recipients as we could before launch.
- Cleaning up report owner data and establishing a process for keeping it up to date.
Methods
- Interviews
- Surveys
- Prototyping
- User flows
- Mockups
- Surveys
- Prototyping
- User flows
- Mockups
