Scispot - Plato

First, let's define our problem

DEFINE & SCOPE

Current Workflow

Scispot's primary challenge was a fragmented workflow for managing plates across its three main products: data collection and analysis, note-taking, and lab process tracking.

Hang on a minute, what are plates?

Users found the multiple entry points to similar workflows confusing, each offering inconsistent experiences. They also expressed they wanted more guidance, as the steep learning curve left many features undiscovered and unused.

How might we leverage AI to guide users through complex plate management tasks, and streamline navigation between fragmented workflows?

DEFINE & SCOPE

Establishing Product Requirements (Scoping)

In recent months Scispot has been moving towards intelligently incorporating AI wherever we could find a use case. I began scoping this project by considering which of our current plate-related workflows could use the help of an AI assistant.

The challenge was to design a UI for an AI agent whose backend was mostly already built. To ensure users could discover, understand, and utilize its features, I collaborated closely with engineers to fully grasp the AI's capabilities.

Next, let's conduct some research

PRIMARY RESEARCH

User Interviews

To better understand our users’ needs, I watched some previously recorded user calls, and documented any pain points relevant to the plate workflows.

Some questions I asked myself while conducting research, include:

What workarounds do users use when stuck? Are they redirected to helpful features or lost in unrelated tasks?
Where do users need the most guidance—navigation, understanding features, or troubleshooting?
How do users prioritize plate-management tasks? Are there clear goals they’re working toward, or do they browse to see what features are offered?

SECONDARY RESEARCH

Competitive Analysis

Since most of the functionalities we were building, or had built, were unique and original, conducting competitive analysis was quite difficult. So, I began by sketching out possible UI elements I could use to intuitively guide our users through these different workflows.

For example, I knew one thing I wanted to incorporate was having our AI agent suggest the different workflows it could help our users with, so I looked into other platforms’ AI search suggestions.

Now, let's get to ideating!

IDEATE

User Flow Diagrams

Using feature requirements and research, I created user flow diagrams to map entry points and address fragmented workflows.

Since our timeline was quite tight, this phase of the design process was just some quick sketches on paper, which I validated with my team before moving to wireframes.

IDEATE

Mid-Fi Wireframes

I then moved on to creating wireframes, which took several days of lo-fi and mid-fi explorations and playing around with different design conventions.

This step in the ideation process involved the most collaboration not just with the product team but also with the engineers. I consistently asked for developer feedback to see if my designs were feasible given our budget and timeframe.

Next, it's time to get some feedback & iterate

FEEDBACK

Design Critique!

Next it was time to get formal feedback from the team.

I found it useful to run two separate design critiques with different teams. With the engineering team, I asked mainly for feedback on feasibility. With the customer success and sales team, I received feedback on the main flows customers tend to call to ask for help.

ITERATE

Design Decisions

Design decision #1: choosing a centralized entry point

I considered a few options for a centralized entry point:

Homepage

Its primary role is to introduce the platform rather than provide workflow-specific tools

Could use an onboarding experience here, but that only makes sense the first few times and would become cumbersome for seasoned users

Results analysis spreadsheets

Only makes sense if plate workflows were exclusively tied to data analysis

Lacks the flexibility to support the entire workflow

Lab Processes Tracking App

Does not naturally align with the hands-on, experiment-focused nature of plate workflows

Note-taking App

Users rely heavily on this app to plan experiments, and plate workflows are contextual to specific experiments

Ensures that users encounter it in their natural workflow, maintaining continuity

Some things I considered when making this decision include:

Where do users currently spend most of their time on the platform?
Does the entry point support easy navigation back to other parts of the platform?

Design decision #2: page architecture

Where on the page should we introduce this feature?

Embedding the feature as a button or toolbar

Simplicity and a clean interface

Lacks sufficient context

Leveraging our platform's backslash embedding feature

More contextualized approach

Allows users to interact with plates in a familiar format while maintaining a clear association between Plato and plate workflows

Some things I considered when making this decision include:

How often do I envision our users using this feature?
How can I introduce Plato in a way that both explains what it is to new users AND does not get in the way of existing users’ experience?
How does this feature scale? What if our user wants to embed many plates into one page?

Design decision #3: modal or fullscreen?

Fullscreen

More real estate, allowing for detailed guidance and context for onboarding new users

Allows for a more immersive experience where the entire screen is dedicated to the feature

Risks isolating users from their primary workflow (creates the impression of navigating to a separate area of the platform)

Users may lose context of the experiment they were working on

Modal

Balance between providing enough space for functionality and maintaining the user’s context within their current workflow

Allows users to interact with Plato as an embedded component of the note-taking app (reinforcing its role as an extension rather than a standalone tool)

Offers less space than fullscreen designs (to work around this, I prioritized content and chose a clean, structured layout to not overwhelm users)

Some things I considered when making this decision include:

How much time do users typically spend (or want to spend) engaging Plato? Are users likely to want a quick interaction or a deep dive into this feature?
How much screen real estate is necessary to display the feature’s content effectively?

Finally, it's time to present final designs!

PROTOTYPE

Final Designs!

Click through the prototype below to see the final designs:

Reflecting on this project...

REFLECTIONS

Lessons Learned

No design work is ever wasted

There were many times when a piece of user feedback, or a new stakeholder need would completely change our design direction. Each time, I was pushed to drop everything and explore new ideas and interactions. Although it was challenging (and sometimes discouraging), I’ve learned to be adaptable. It’s difficult to know which design is “final,” since the world of tech is always changing. I’ve learned to neatly document every iteration because sometimes our past designs could inspire future solutions!

Sketch first, Figma last

When I go straight into designing in Figma, I tend to get distracted by the visual elements and making everything look “pretty.” Yet, without finalizing the UX of the platform, a lot of my Figma iterations end up being scrapped. By using a UX shorthand and sketching on paper, I can eliminate my tendency to get carried away setting up components and variables and just focus on the first task at hand: designing the UX.

REFLECTIONS

Next Steps

Conduct user research

I believe that the solution to any problem is to first go down to the root of the challenge. Since a lot of our users could not find many of the features we offer, I believe the root of the issue lies in our navigation. To better understand how our users think, and what information architecture is intuitive to them, I would first conduct a series of tree testing or card sorting before ideating.

Conduct usability testing

I would also validate my design decisions to see how our users interact with our product. Usability testing sessions would perhaps highlight some assumptions I had made when designing as I am not the main user group I am designing for.

Explore accessibility

As Scispot continues to expand its user base to more clients including government organizations and university institutions, I expect many of them will have accessibility standards to upkeep. As a result, I would advocate for Scispot to do more research and consider accessibility in their designs.

Design for responsiveness

Having worked in a few wet lab environments, I understand that some scientists may want to use an iPad or tablet when conducting their experiments. The current designs were optimized for desktop, but may become too cluttered on smaller screens. Given more time I would explore responsiveness best practices.

Consider scalability

I believe the mark of a successful product is how it will translate in the long term. Though this project started off as a smaller feature, in the past few months I have noticed that more and more scientists have begun using it (some scientists even use Scispot solely for the plate management workflows). I would consider designing a centralized place to host all plate-related workflows, perhaps even bringing the entry-point to that Plato screen at the highest level of navigation.