Data Request System

Roles: UX Designer, Researcher, Interaction Designer, Presenter to Stakeholders

Skills: Research Process, Interviews, User Flows, Interaction Design, Wireframes, Mock-ups, Prototypes, Usability Testing, Software Development Life Cycle (SDLC)

Software: Sketch, Invision, Rally Software, Skype

Project Goals

The project’s goal was to create a repository for supplier information. The client relied on Microsoft Excel spreadsheets and manually contacting suppliers over the phone. Several team members were contacting the suppliers about the same information.  The suppliers requested a management system with the ability to approve or deny requests.

Resolution

UX talked with the users and clients to determine the problem and tested different layouts. The new system helped alleviate supplier frustration of being contacted multiple times for the same information. It increased productivity and visibility to open requests for information so that everyone can be on the same page.

Wireframes and Flow Charts

I created both low and high-fidelity wireframes. I organized the wireframes using a unique letter/number combination (e.g. A1, B, C) to clearly identify them during discussion and avoid confusion.  

Phases in the Product Cycle

Phase 1: Engineers request new data through a wizard.

Phase 2: A council approves or denies a request to contact the supplier for data.  

Phase 3: The data team receives an accepted request as an engagement to contact suppliers. Phase 4: Data gets added to the database. 

Future: Suppliers can view and edit their own information. 

Interviewing, User Journey, and Presentations for Stakeholders 

I interviewed people on the data team to learn more about their role and the current issues with the process. The interviews were transcribed, analyzed, and turned into actionable work items. A user journey map was created. At every sprint review, I would present an update to the stakeholders, discussed the project and gather feedback.  

Phase 1: Engineers request new data through a wizard. 

The first problem to solve was locating data and visualizing existing requests.  Engineers can now search the system for existing data.  If the data is not found they could search pending requests.  For the minimum viable product (MVP), the engineers needed to be able to fill out a request form. The requests could be managed or removed. A future enhancement would allow the system to auto-populate the requested information when the supplier provides the data. 

Below is part of the wizard I designed to guide engineers through the data request process. Another UX Designer helped me to animate the prototype using Invision. 

Phase 2: A council approves or denies a request to contact the supplier for data.  

A new interface allows the council to view all requests in a single table. They have the ability to filter, perform a single action or bulk actions. The mock-up below shows a user providing a reason to put multiple actions on hold. If the request is denied, by the council, a notification is sent to the requester with the reason. If the request is approved, the system sends the approved request to the data team for Phase 3. 

Phase 3: Data Team receives the accepted request as an engagement to contact suppliers  

The data team has the option to create a new or split the request into multiple engagements. The data team will contact the suppliers for the information to complete the engagements. 

Phase 4: Data gets added to the database. 

As the data team gathers the information from the supplier, it gets stored in a centralized database. The data will be visible to the Engineers as soon as it is entered.  Engineers can track the progress of their requests. 

Product Launch 

An article about the data request system launch was written and shared with the client. I on-boarded a new UX person to support the project post-launch. The client wanted me to assist on another project team.