To comply with my NDA, I have withheld information that is considered confidential in this case study. The information below is my own and does not necessarily reflect the views of Glint Inc.
Glint’s mission is to help people be happier and more successful at work, and we do this primarily by collecting employee feedback from things like employee surveys. We then synthesize all this information using advanced analytics and AI, and make it available in real time. From these insights, we give leaders visibility into the health of their organization, increase employee engagement, help managers at all levels take action on this feedback and improve business results.
Glint has two distinct products, Engagement (Engage) and Performance (Perform). Engage is the powerful employee engagement platform that delivers insights to help organizations improve employee happiness and satisfaction, and Perform is the agile management platform that helps create a feedback culture through more continuous conversations between leaders, managers and all employees. Engage was used by all our clients and Perform’s MVP was in a charter program, used by only a handful of our clients. Historically, not many companies tie employee engagement to their performance management processes, but recent research has shown that employee performance is definitely tied to employee engagement. We envisioned these two products becoming one platform in the future, so we began to work towards that vision.
To give some context, both Engage and Perform were available on the web and native platforms (iOS and Android). On the web, each product had been built on different versions of the same code frameworks and each one had a separate style guides with significant differences between UI components, interactions and patterns. From the start, we knew that unifying both products would be a massive team effort. We needed to figure out what steps needed to be taken so the work could be done in phases and in parallel with the release of new features.
At Glint, we believe performance management and employee engagement are inextricably linked. By unifying both products, the goal was to create a unified platform where leaders could have a holistic view of the health of their organization, improve employee engagement and create a culture of feedback where managers and employees have meaningful conversations. As we looked at the roadmap and decided how to prioritize this effort, the team and I embarked on a journey to build the foundational building blocks to get us closer to the vision of a “People Success Platform."
Alongside a team of Product Managers and Engineers, I worked on these foundational features that included the following:
For most of these features, we had to account for three different user types and three different product access use cases. HR Business Partners, Managers (from all levels) and Employees each had access to different versions of the products. Also, depending on the customer, there were those who had access to both products and others who had access to Engage only or Perform only.
Throughout this process, I created prototypes to explore different solutions, considered all use-cases, assisted in user research to validate the solutions, and iterated on the feedback. I will briefly go over the problem, goal, process and outcome for each one of these features that made up the initial work to unify both Engage and Perform products.
When I joined, there were two UI style guides supporting each of the products. These style guides were built in a way that focused on going to market quickly, but overtime were bloated with unused components and were very difficult to maintain. The end goal was to build a well documented design system with a robust UI component library for the design, a set of ready to use UI elements in code for the engineering team and for it to become the source of truth for the whole team. This would allow us to improve our efficiency, consistency and collaboration as we scaled by building a unified platform.
I began by meeting with the UI team who maintained the style guides for each platform and learned that these libraries had shared components, but lacked consistency. Colors, icons, typography, etc. were all over the place and most were not made to accessibility standards. I proceeded to audit both products and made a list to identify the differences and similarities between the two products. Since the style-guide supporting Perform had the most up to date UI components, we decided to use it as the foundation for the future design system.
Along with the UI team, we created a component prioritization checklist to identify and prioritize which components we would work on first and make sure all the changes we were planning to make worked well in both products. I led the creation of all of these new components in Adobe XD that included: Icons, color palette, forms and buttons, typography styles, along with many other components. Besides making sure these components and colors were accessible, we redefined Glint's design principles to reflect our latest thinking.
Glint's UI Kit served as a solid starting point to define each component and help with the effort of unifying both products. Below you can see a couple of the components.
From there, we worked with the UI team to translate and implement these new components into the new style guide. With this new UI Kit we made a good progress, enhanced cross-team collaboration and brought consistency to the current user experience. It brought parity between code and design file components and gave the design team more space to explore since we did not have to reinvent the wheel. There is still a lot of work to be done, but we are closer to create a robust Glint design system.
In parallel with this project, I also got a chance to work on the Android app. I recreated all of the Android app in Adobe XD and partnered with the Android developer to create a basic component library that provided guidance and consistency to the Android experience.
The goal of this initiative was to create a simpler, more secure login experience that allowed users to login to Glint regardless of their method (SSO or Password), activation status (activated or unactivated) or product being accessed. This solution had to also support Glint internal teams to easily access demo clients securely and with minimal friction.
We began by speaking to members of different teams, including Customer Success (CS), to get an idea of what were the current client needs and frustrations. We found that there was no easy-to-find login page that worked for all of our users. We then met with engineering to find out the current limitations and constraints of the current login experience. After working with the Product Manager on establishing the problem and use cases to solve for, we created an IA diagram that could help us understand the flow and entry points. We shared it with other teams to get their feedback which included: Engineering, IT, CS and others. After a few revisions, we got the ok from all stakeholders to use the proposed solution.
I did a bit of competitive research, analyzing different login methods, page structures and design patterns among different products. From our initial conversations with the team, we all agreed that the page had to look clean and minimalistic. I then began the exploratory phase, designing different low-fi concepts and collaborating with the PM. One of the concepts included the screen divided into two columns with space to promote product features, events or new releases.
After a couple of design reviews, revisions and iterations, we converged in two potential concepts. I ran some usability tests, both in-house and with clients, to make sure the interactions worked and uncover any resolvable issues early in the process. I also worked on simplifying the set of activation, validation and confirmation email notifications that served as entry points to Glint's products. We worked with the Marketing and Customer Success (CS) teams to come up with a strategy to help transition existing users to the new login experience.
At the end we designed a solution that was not only much simpler and cleaner, but secure for all users. This new experience made it easy for both clients and internal teams to access Glint regardless of the authentication methods, activation status or entry points. We are still in the process of implementing this new experience, but as we plan the release, we are keeping in mind a couple of questions we want answered to measure success.
The goal was to create an integrated L1 navigation bar that would unify both Engage and Perform in a seamless way and allow users to locate specific features and content. The plan was to rearrange some of the pages, change the position of key elements and improve the overall UI. The new tabs would provide a clear visual indication of what content can be found on each page and would clearly place the current location in context by highlighting it with an underline. Below you can see the previous navigation bars for each product.
As you may notice, these two navigation bars had a lot of inconsistencies. The height, hover states, selected states and icons etc. were all different. The Engage product had a L1 navigation with a tab called ‘Explore’ where it housed additional pages and reports that would appear on a secondary navigation. On the Perform product, there was a search bar where users could look up teammates from the whole organization. For clients who had access to both products, there was a ‘Product Selector' where they could toggle between products. It was a clunky user experience, but it was an interim solution until we could integrate both products.
One of the key elements that needed to be moved was the Program Selector. This selector allowed admins to search and choose different survey programs. Originally, it was placed on the top right inside the navigation bar, but we needed to find a new location for it. Along with the team, I made a IA diagram with the three different use cases to figure out what was the best was to display all the information. The use cases were the following: Users with access to Engage only, users with access to Perform only and those with access to both Engage and Perform.
After considering different options and getting feedback from clients and internal teams, we decided the best place was to place the program selector was on top of the dashboard at a secondary level navigation. This new location, made the dropdown more prominent and was the best option based on the conversations we had with our customers.
The PM and I had a conversation with the engineering team to discuss all of the cross-dependencies between products and define the most efficient way of phase the integration. We decided that on phase 1, we would work on the UI (page states, icons, patterns) and phase 2 we would make all functionality changes.
I created a clickable prototype with all the UI and functionality changes and sent it to a couple of stakeholders for feedback. Once I got the feedback with a couple of tweaks, we scheduled some calls with users and shared the prototype with them to make sure the changes made sense. We also communicated with the CS team to start conversations with customers to share the new navigation and to let them know that those changes were coming soon.
As we continue to track user feedback for the new UI, this first version of the newly integrated navigation solved the problem for each user type and client. It got overall positive feedback, but we still need to iron out some kinks with the placement of some of the pages.
The Reports page allows admins and managers to access different reports where they can view and analyze survey data. Each report breaks down the data in different ways and give users the ability to slice and dice it by applying a set of filters. Users are also able to save and bookmark reports to easily access them when needed. Depending on the user’s access some of the reports included: The Executive Summary, Comments Report, Alerts, Driver Report, Heat Map Report, Multiple Choice Report, Response Rate Report, Action Plan Report, Goal overview and Conversation overview, among others. Below you can see the difference in style, layout and design patterns between both pages.
The goal was to create a page where users with access to both Engage and Perform reports could easily search and select a specific surveys from different programs. These programs would be listed and ordered by most recent usage and categorized into 3 groups: Conversations, Goals and Surveys.
Additionally, inside each program, reports were displayed as card tiles with the name of the report, description and a representative illustration.
As I began working on this page, one low hanging fruit was the card tiles and illustrations. For consistency purposes, I used the same illustration style that had been established in the past. I improved the UI on the card tiles and created new illustrations for the new reports that were being introduced on this page. I then began exploring different layouts that could potentially work. As I shared these concepts with the team, one layout that featured a tree folder structure, seemed like a potential solution. I made a prototype and shared it with the Engineering team to make sure this solution was feasible. After many design reviews and getting feedback from clients and internal teams, we decided that it was the best solution.
This is still an ongoing project that will continue to be worked on for months to come. Working on this solid foundation to unify both products definitely reminded me the importance of progress over perfection. There are parts of the product where I would have wanted to spend more time ideating and conceptualizing more solutions, but for the sake of moving forward quickly, we had to make certain tradeoffs.
Being constantly reminded of the larger picture, kept the whole team focused and allowed us to meet most deadlines. I look forward to seeing how this foundational features will allow the team to scale Glint's unified platform without compromising the user experience.