Redesign of the Onboarding / First Time User Experience for an AI startup
Platform: Desktop
Platform: Desktop
Role: UX Writer, Researcher, and UI Redesigner
Project Type: Data Analysis, Research, Redesign, Logo Animation
Industry: Implementation Consultancy, AI, Project Management, Data Migration
Tools: Figma, Posthog, Zoom, Claude, Final Cut X
Background:
AI tools are a dime a dozen these days, but Glossa differentiates itself as a tool for implementation consultants to easily generate requirements from zoom meetings, documents, emails, videos, and more. Glossa centralizes all of this information, allowing both the client and the consultant to upload data. It can track task progress, reduce redundancy and manual data entry, and crucially - integrate with Google, Outlook, Onedrive, Zoom, and Teams. Pretty nifty!
The Problem:
Only 12% of users completed the full project creation flow
(2 out of 17 users within the 1-month period leading up to our UX research.)
Glossa’s onboarding / first time user experience needs some work. Glossa isn’t seeing high rates of new users completing the creation of their first project and actually using the tool. Glossa wants users to quickly and confidently use their service, and knows there are UI slowing down that journey.
Now, I won’t pretend I walked into this project understanding what the company does on a deep level. I had some experience with data migration at a previous job (and knew how much of a pain it could be), but I didn’t understand exactly who specifically would use Glossa and how they would benefit from using it. But I will say this:
Although I was new to the industry and its nuances, this proved to be an advantage rather than a limitation. Approaching the project with fresh eyes allowed me to design an onboarding experience that felt intuitive from the start.
If the onboarding experience made sense to me, a new user, it would certainly be clear and effective to experienced professionals too.
Working toward a solution:
Fundamentally, this analysis uncovered three discrete flows to explore for Glossa:
Account Creation
First Project Creation
A Quickstart tutorial of some kind
The team and I talked through a few potential avenues to pursue. Though we knew we were going to lean on user interviews for our first actionable steps, we wanted to brainstorm a few ideas of possible avenues to pursue. One of those ideas was a first time user experience / quick start tutorial similar to those generated by Intro.JS. These tools would provide an overlay to the existing user experience walkthrough, acting like a tour guide through the dashboard and menus.
Would a product walkthrough like this make the first time user experience better? Yes, but…
But upon manually reviewing the onboarding flow with one of the cofounders, we realized that the experience itself needed work. The language was inconsistent between menus and buttons, and ultimately the user might end up confusedas to why and how the steps they were taking would be used to help them set up a project.
Buttons and menus like this one were confusing. The copy needed improvement.
What is a system? What is a service?
An analogy - you don’t want to hire a tour guide for a museum if you’re already looking to change the way the museum is laid out. You should start by redesigning the museum - you can worry about the tour guide later.
Then… A Discovery
An Unused Onboarding Flow buried in the company Figma file.
While exploring Glossa’s existing Figma file, we discovered an unused onboarding path that immediately had a few usability improvements that felt more intuitive. It was also old and needed updating, including pricing info that was no longer relevant.
Was this a buried treasure? Has our work already been done for us? Well… No.
"Buried Treasure" Figma Onboarding screen
Existing Onboarding Screen
There were some helpful workflows in this existing onboarding flow (and a bunch of unused assets!). But it became clear during user interviews that this unearthed flow only solved some of our problems. Glossa’s onboarding challenges were more heavily rooted in the project creation stage.
Prioritization
A streamlined, effective onboarding experience sits neatly at the intersection of Glossa's business goals and their user's goals.
Feature Roadmap
Narrowing the scope of this project so we can achieve measurable results.
Persona: James
James is tech savvy, trying out tools as he encounters them to see if they make his professional life easier. How does Glossa stack up?
Low Fidelity Prototyping pt. 1:
Animating the Glossa Logo
Take a look at this logo. What do you see? How might it move?
The Glossa team didn’t have a clear answer - so I went with my intuition.
I asked the cofounders and developers these questions during our first meeting. In the spirit of goodwill and building rapport with the Glossa, I decided to create an animated version of their logo.
Let’s get sketchy:
In my mind, the logo would animate from left to right. The screen would start blank, and then column by column, the pieces would flow from the left side of the screen towards the right, transforming from circles into squares with rounded corners as they landed in their respective rows.
Though Figma isn’t strictly a visual animation platform, I realized it had a few things working in its favor as the ideal platform for creating this flow.
Converting squares with rounded corners is actually quite easy in Figma; all I needed to do is: vectorize the full logo, duplicate a frame, adjust the corner radius for each shape on a frame, prototype a delay transition between each column’s entrance.
The full flow ended up looking like this:
And here is the finished product:
This animated glossa logo could show up all over the place, including in videos on title cards, as a loading icon any time Glossa is performing process that requires the user to wait, And potentially, as the very first thing the user sees after they create their accounts and begin the onboarding process.
From Low to High Fidelity Prototyping:
Wireframes
The user flow acts as a catalog of which screens would be essential - including ones that already existed but needed a revamp, and ones that needed to be created from scratch. Because of space constraints, (see “No Scrolling,” above), we elected to go with expanding and collapsing components whenever possible.
Several new components would need to be created, including:
An explanation of Glossa’s data security policies, as several users brought this up as a chief concern. This explanation should be placed at the point where the user is asked to input their data, as this is where they would need reassurance that Glossa does not train its LLMs on user data, and it won’t retain their data for months or years down the line.
Low Fidelity Data Privacy Button
High Fidelity Data Privacy Button
An explanation of the specific ways Glossa interfaces with other apps, how the user sets them up and points Glossa only to the specific data they want to use for their projects.
This second component in particular went through several iterations including. We asked questions like: Should the component have a hover state? Where should the “Connect” Button be in relation to the connected app name? How much text explaining the ways in which the app interfaces and pulls the user’s data is necessary?
The primary consideration here was that we wanted to make all data fit on an initial screen without requiring the user to scroll. Based on our user research, one of the key aspects of an effective onboarding experience is SIMPLICITY. We want to reduce the potential overwhelm a user might experience, and one of the best ways to do that is to reduce the amount of information displayed on each screen. The user can choose to dive deeper and learn more if they want, but they shouldn’t be required to read about every potential connected app’s features when simply walking through an onboarding flow.
Iterations:
Before
After
Screens revised included:
Renaming Project Capabilities to Project Categories.
Establishing consistent naming conventions with “Team” (as opposed to “organization” or “company”)
Removing the “Project” breadcrumb from the onboarding flow, since that became its own series of breadcrumbs itself.
Standardizing UI patterns across screens: Nick identified inconsistency between screens with and without input boxes. Maintain consistent visual design and component usage throughout the flow. Position instructional text close to relevant input fields.
Adding "you can change this later" messaging: Jeff emphasized wanting to know when he can revert changes and Jeff specifically wanted to know he could update client structures later. Add reassuring copy throughout that decisions aren't permanent.
Reframing source/target location of existing data as a user-friendly question like "Where is your client's data today?" and "Where are they moving to?
Adding expandable information for Connected Apps: including collapsible sections explaining what data transfers, how connections work, and limitations (e.g., no historical Slack data). These would be short explanations that assuage users’ concerns about unintended data accidentally being brought into Glossa. These explanations would explain in a few short sentences how each connected app works so that the user knows what to expect when they choose to connect it.
Reorganizing screens so that the user inputs client information before project-specific information. This allows users to create client records before projects to support real-world scenarios of clients with multiple projects over time.
Adding role definitions and permissions clarity - a short explanation of what permissions are available to a “member” vs. an “owner.”
Additional Recommendations to our stakeholders:
Several requests from the users were outside the scope of this UX project, and needed considerable input from the developers. We packaged up those requests seperately with our recommendations. Those included:
Creating and integrating a sample/demo project: Three out of four participants requested this. Offer it after initial setup completion but before users create their first real project. Include pre-populated requirements showing conflicts, duplicates, and different categories so users can explore hands-on without risk.
Making a short video tutorial (45-90 seconds) that tells you what the onboarding experience will entail. This could go at the very beginning of the experience to set the stage elegantly and succinctly.
Adding a Help Button in the event the user gets stuck, has additional questions about a specific screen, or wants to learn more in a different way. Glossa already has a business relationship with Intercom (using it in their Help Center) so it wouldn’t be a huge lift to incorporate it into other places on the app too.
In tandem with the “Sample/Demo project,” a tooltip walkthrough could be useful to showcase within an existing project. Since the Glossa experience is so nuanced and fundamentally “new,” the user may very well benefit from onscreen prompts that function as a guided tour through the app.
Implementing and Validating the Revised Onboarding Experience
Using Posthog, we will be able to track each individual users’ full onboarding experience and test the effectiveness of the new onboarding flow.
Once the revised user experience has been released (in about 2 or 3 weeks), we will be able to compare a “before” implementation and “after” implementation flow.
We will explore metrics in Posthog like rate of completion of the onboarding process overall, frustrated clicks, task success rates, time spent on each screen, and how the users interact with subsequent screens after onboarding to evaluate the effectiveness of the new onboarding flow - shortfalls or triumphs - for an effective compare/contrast between the old and new onboarding experiences.