Request Manager

Manage and monitor your team's progress on tasks - all in one platform.

Summary

Scispot, an all-in-one digital toolkit marketed towards biotech startups, encountered obstacles when enabling users with the ability to efficiently manage their teams and track their progress on tasks.

Our team has developed a request manager feature, empowering users to seamlessly share tasks and documents with their teammates directly within the platform.

Duration
March - April 2023

Team
Satya S. (Product Manager)
Rafael P. (Head of Engineering)
Thomason Z. (Software Engineer)
Saathana C. (Software Engineer)

My Role
User Research, UX Design, Prototyping, Testing

Background

Leaders face challenges in managing and collaborating with their teams.

Scispot offers a toolkit to biotech startups and science labs, simplifying research and company development. The platform enables users to manage their protocols, experiments, and documents electronically. Despite this, Scispot lacked team-management tools within the platform, making it difficult for scientists to guide their teams and work collaboratively with their others.

What are the challenges?

After interviewing some current users of the platform, I discovered 2 main issues that many faced.

Doodle of 3 people looking talking to each other
it's hard to manage the team's progress on tasks
Doodle of 2 people looking at a laptop.
it's difficult to share Scispot pages within the platform

Ideation

Market Research

I looked at popular team management platforms such as Monday.com and Smartsheet. Understanding common ways other team-management platforms enable users to supervise their team gave me an understanding of common feature patterns.

Being able to assign roles to users and project tracking was a feature that many Scispot users could benefit from - and the focus of my design.  

Our Solution
Create a request manager within the platform which allows users to send requests/tasks to other users within the company. The request manager would allow users to attach Scispot pages to them, such as electronic protocols and experiments.

Key Requirements

Construct the product in a scalable way.

As we were constrained by time, we knew we could not build everything we wanted to for the initial release of the request manager. I aimed to design the request manager in a scalable manner that would seamlessly integrate with Scispot’s current functionalities.

01
Assign tasks to other users
02
View the team's progress on tasks
03
Send the necessary documents for the task

Design

User Flow

Drawing insights from other popular team management platforms such as Monday.com or Smartsheet, and speaking to a few of our current users, I developed a user flow that I believed would align with the requirements that I previously outlined. In addition, I had to ensure the flow was simple enough to develop within the deadline of 2 weeks.

An image of a user flow for the request manager.

I developed a user flow consisting of three primary stages. ‍ I decided on criteria that would be important for the request to have, such as a due date, description, and documents.

First Iteration (MVP)

Because of time constraints, I didn't have time to conduct explorations and design low-fidelity prototypes. I instead went straight to designing an MVP.

Image of the request manager dashboard from the first iteration of designing.
1st Iteration of the Request Manager dashboard
Image of a request panel when a user receives a request.
Request panel when receiving a request

User Testing + Findings

Conduct 1 hour user testing sessions.

I conducted user testing sessions with two participants. My objective was to identify any points in the user flow that needed improvements. I asked our participants to “think out loud” and voice their frustrations or satisfactions as they created a request.

Creating requests takes too long
Assigning users to each “to-do” and using tags seemed unnecessary.
Leaders need more control over requests
Team leads would like more control over what requests are being sent through the company.
It's hard to tell what each role is
Participants couldn’t tell what each role was by the name alone. Is there a way to make the responsibility of each role clearer?
It's hard to keep track of requests
Once a request is sent, participants have trouble understanding where the request goes.

Second Iteration

Gather findings to help guide the next iteration of design.

After learning more about the participants' satisfactions and frustrations through user testing, I worked to make improvements to the overall design and experience in the Figma prototype.

Simplify and remove unnecessary steps.
Now, users could simply search for their teammates, rather than having to manually select each person. I also removed tags.  
Image of creating a request and assigning people to a request.
Image of a message that an approver can send. It reads: " This isn't a priority right now. Let's do this next week."
Add an Approver role for team leads.
Each request must be approved by the approver before it can reach the requestees.
Add descriptions to each role.
This helped users understand what each role meant, and who to assign. We also pre-populated the requestors and approver roles with the name of the person who is creating the request.
Add an audit trail and feedback.
The Activity panel keeps users updated on the progress of each request. We also added more feedback during each step of the request process.
Frame of viewing a request with its activity shown on the right.

Next Steps + Reflection

Active user participation is crucial to creating a truly exceptional product.

All assumptions about the users should still be thoroughly tested by the users themselves. I found that user interviews and research really helped to guide and validate my design process when I was stuck. 

Explore alternative designs and user flows.

Due to the time constraints imposed on the team, I had limited opportunity to explore alternative designs or user flows. Given more time, I would have liked to minimize the amount of "explanations" or descriptive text required to guide users through the product. In the future, I would like to conduct more explorations to test different user journeys and designs that may be more intuitive.