Ninety.io

During my first year with Ninety, I inherited a legacy out-of-the-box Material design and worked with a pre-contracted outside agency to build up Ninety's first UI kit. With every page I redesigned, and every new feature I built, I gained a better understanding of Ninety's users: how they interact with the app, what's working, what's not working. In the summer of 2022, things changed – Ninety contracted a firm to undergo a holistic organizational rebrand. We were moving away from our overt affiliation with EOS™, and forging ahead on our own. On the product design side, I took it as an opportunity to start fresh: build something from the ground up that aligned to both Ninety's new identity and the needs of our ICP.

In Terra Design System, I dive into the process of designing, building and operationalizing Ninety's brand-new component library. Give that a read if you can, I promise it's at least mildly interesting. This case study, however, is purely about design – why did we make the decisions we did? And how do Ninety's new design language and patterns not only alleviate pain points for our existing customers, but set Ninety up to scale alongside future PLG?

While I started as the sole designer at Ninety, I eventually grew the team to six (including myself). You can read more about my approach to building the team in Building DesignOps. Generally, more people equals increased capacity. Being the only designer, there was a point where I began feeling like a bottleneck – bringing on more talent alleviated that concern and allowed us to roll out redesigned pages and features at a much faster pace. However (and this is, of course, not unique to design), unless everyone is on the same page, increased headcount can come with diminishing returns. My challenge was to make the new system discoverable and learnable enough that after some initial onboarding, designers could find the components they needed, apply them correctly, and ensure proper implementation with their devs without my involvement. The recipe for success here was threefold: intuitive structure and navigation, componentization, and robust documentation.

1. Intuitive structure and navigation

I housed the entire design system in a master Figma file that contained all requisite variables and components. I set up the component hierarchy using atomic design principles: tokens came first, followed by atoms, then molecules, then organisms. Specific pages and recipes were then kept in each pod’s dedicated Figma project. In addition to the core atomic components, the file also included responsive layouts for desktop and mobile, as well as a quick ‘sticker sheet’ that designers could use to copy common precooked recipes without needing to piece together their own, or dig through existing high-fidelity mockups. The key here was quick, consistent adoption.

2. Componentization

Anything in the design system had to be componentized to death. Some components in Figma had as many as ten properties on them. This wasn’t an effort to be overly prescriptive – on the contrary, this allowed for increased flexibility and reduced design drift. It was more upfront work for me, but ended up saving countless hours in design audit because designers no longer needed to detach or hack together components to repurpose them for their use cases. As soon as Figma rolled out support for variables, I also pulled as many hardcoded values (spacing, radius, etc) into the variable system to introduce even more consistency across dependent Figma projects.

3. Robust documentation

This part was key – not just for designers, but for developers (especially those tasked with building out the components). For each component, I created a page structure that captured anatomy, behavior, usage guidelines, variations, update history and related components. I also set up an area to track progress on the component across three vectors – design, guidelines and Storybook. This meant that for any component someone went to in Figma, they would see designs for all the component’s variations, guidelines on how and when to use the component (in both design and in practice), and where that component was in the status of being dev-ready. Again, more work upfront for me, but gauging by how seamlessly the components are being used across design and dev, and with how few direct questions I get about usage, it was well worth the time spent.

Redesigning an entire app, especially one as broad as Ninety, is no small feat. There are countless legacy pages to account for, as well as new features and pages constantly being developed. For a product design team, it becomes a balancing act – how do we redesign the app without completely overwhelming the product roadmap? How do we push design while maintaining a good relationship with our PMs? We didn't have the luxury of stopping all feature work to focus on redesign – and in any event, that's almost never the best way forward. A more iterative approach is always better for both the company and the user – thus, refactoring without scope creep becomes important.

I encourage all my designers to have at least a surface-level understanding of HTML, CSS, and if possible, a local dev environment that they can dig through. However, good rapport with an engineer will suffice. Designers should always have a high-level idea of whether something in their design is a simple HTML/CSS tweak, or whether it will require significantly more effort. They should also have a high-level understanding what's already available in the codebase, and what we can surface (or resurface). Those are the important tenets of a redesign – present the existing information in a better way, and look for opportunities to provide incremental value via small wins. There is a tendency for designers to go beyond that and introduce, say, a pie chart visualization into a table to add a splash of visual interest. The problem is, that pie chart requires a chart library, probably a bunch of custom styling, a ton of requirements – probably way more than is possible in the swing of a refactor. As designers, we need to be discerning with what's feasible now, versus what's more of a "next" or "later" roadmap effort.

In redesigning the legacy Ninety experience, good Gestalt principles are always my friend. I add visual anchors where possible, drawing the user's eye to the most relevant content. This also segues into visual hierarchy – I make a few key CTAs more prominent than others, and either reduce the rest, or hide them inside context menus depending on typical user interaction with that component. This applies to fonts as well – some content warrants additional prominence, while other content needs to be knocked way back. Finally, I add just enough whitespace to give the eye a break, while also making sure relevant content remains visible above the fold. In all of this, there is very little scope creep beyond a few HTML/CSS quick wins – I mostly leverage data points that already existing in the app, and surface them in ways that provide additional context or value to the user.

For me, the issue of workflows is always top of mind. How can we optimize a user’s workflow to align to their JTBD at that point in time, flattening the learning curve and reducing time to value? In conducting research (via observing recorded sessions, analytics funnels, reading chat support logs and, of course, talking to customers) it became painfully obvious that our users were hurting. Ninety, as it stood, did not provide much in the way of efficient workflows – if anything, we were actively reducing efficiency.

Any user, in any experience, exists somewhere in time and space. The question every UX designer should ask themselves is, are we doing a good job of helping the user orient themselves in time and space? Are we helping them get to what’s most relevant, most recent, most important? Or are we throwing everything and the kitchen sink at them, and expecting them to find their own way around? A metric often used alongside UX improvements is engagement, but all engagement is not created equal. The latter scenario inevitably leads to users spending more time on meaningless engagement, while augmenting the user’s workflow and leading them towards what’s most relevant offers meaningful engagement. The former is busywork, the latter is work with a capital W. Getting users to meaningful engagement faster shortens time to value, results in a higher degree of satisfaction, and is much more likely to elicit delight and eventual evangelism.

Time was clearly an issue for our users. We were doing a terrible job of saving time for our users through clunky, inflexible flows – it was clear that major changes beyond just a design refactor were needed. Luckily, I had tons of customer feedback to guide me in the right direction. We collect feature requests across a range of channels that subsequently gets funneled into our product analytics platform. The problem with feature requests is that they don’t always capture pain points or frustrations, and they’re also usually quite singular. For example, users will ask for the option to sort by users on a specific page, or the option to filter by date on a different page – what’s more beneficial from a global design standpoint is the rollup. I took on an initiative to do just that – roll up some of our detached feature requests into larger themes, which led me to realize that our filter pattern was in dire need of improvement. It was almost a 0-100 kind of situation: our app had almost no filter functionality, and users wanted more. This meant we needed not only to design something net new, but design it in a way that would scale across all legacy features and also support new ones. My research, discovery and ideation led to the pattern you see below, one that consolidates existing toggles and filters into a more compact component group. Subsequent usability testing revealed this pattern to be highly discoverable, usable and learnable.

Aside from filtering, perhaps the bigger crime was that Ninety didn't have any sort of notifications. The MVP for this ended up being an event-based email notification system that alerted users anytime a task was assigned to them (as an added bonus, we made sure the system was architected in a way that paved the way for other eventing in the future). The larger issue was, of course, that we weren't doing a great job of pointing our users to the most recent, relevant tasks. Each missing cue was a missed opportunity to kickstart a habit loop that would lead to increased daily and weekly engagement. I spearheaded multiple initiatives in this regard, including roll-up data ribbons, better contextual thought leadership, linking of related items, counter badges in the left nav for new activity, and real-time event-based toast notifications.

Once we solve the time issue, we need to think about the space issue. If an app caters to teams within a company, does the app's navigation align with users' mental models of their teams? Does observed user behavior align to the current info hierarchy, or is the latter a point of friction? Could we come up with a better way?

Ninety is a tool for teams. However, the concept of a 'team' is very hard to find in the UI, due to it being hidden inside the filters row within a page. There was a glaring hierarchy issue there from the start – why would a higher-level selection like a 'team' be present in a lower-level nav element? The problem was apparent, but the solution wasn't immediately clear. The team select could be relocated, but any solution the product team came up with inevitably had its downsides. It was clear that a more holistic shift was needed.

A prerequisite for actually interacting with the team selector was being in more than one team. With that in mind, I conducted segmented user research for users that matched the criteria – folks whose team count was > 1. The research consisted of database queries, session observation and 30-minute customer interviews. In my findings, it became apparent that involvement in more teams equaled more engagement, and more engagement equaled more frustration. Customers wanted to be able to move between teams seamlessly, and see activity across all their teams on a higher level. The answer was clear – teams (or, in broader terms, 'spaces') needed to exist as a higher-level navigation element, not a filter within a page.

Design ideation led me to a flexible pattern that allowed users to create a variety of spaces on the fly, as well as move 'into' to access a more focused view free of distraction. It's honestly no surprise that spaces-centric navigation has been gaining traction in recent years. A range of B2B webapps (beyond the usual communications ones like Teams and Slack) have adopted it, likely for the same reasons: users often want more control over what they put into an app, and where.

This design change is an example of a feature that benefits from an iterative approach – it's definitely not something you spring on users overnight and expect them to not take up arms. Instead, it's something that's offered as an option alongside the existing structure, and slowly integrated into the experience over time. Initial reactions have been very positive – once again, the future looks bright for our users.

Recency and relevancy aside, a theme that transcended the entire Ninety experience was unnecessary divergence. Things that should have been very similar at their core were being treated like two or three completely different experiences. Understanding underlying user behavior and building consistent templates and patterns around the Ninety experience gave me the opportunity to consolidate a lot of features that had previously been completely misaligned – great news for the user. Anytime a seemingly new pattern mimics one the user has already encountered, with just enough divergence to make it unique, the new feature becomes infinitely more learnable and as a result, much more adoptable.

One great example of this were the Team Meeting, Quarterly Discussion and Check-In features within Ninety. The first two had been part of our core feature set for some time, while the latter was a newer one in research and discovery. The former (Team Meeting) was an opportunity for teams in Ninety to meet on a weekly basis. The latter (Discussion) was a review between a manager and team member on a quarterly basis. The two had vastly different designs and interactions associated with them, and existed as two totally separate entities in the codebase, likely as a result of having built ‘as needed’ instead of strategically. However, the planned feature set for both, as well as the proposed functionality for Check-Ins MVP, sounded eerily similar. For all three features, we wanted timed agendas, with the option to move between sections on-demand. We wanted multiple parties to join simultaneously, and be able to interact with the feature in real-time. We wanted to be schedule all three as calendar events, and send notifications in advance and as the event was starting. And we wanted to be able to have a pre-meeting and post-meeting section where participants would either prep for the meeting, or synthesize results for the meeting. And finally, we wanted to allow users some degree of customization over the meeting agendas.

I’d already redesigned the in-meeting experience: lucky for me, my designs could now scale even further. All three aforementioned features were meetings at their core, and the way users were meant to interact with them matched the ‘meetings’ mental model. I immediately recognized the need for a consistent agenda view that had two distinct modes: a template builder and an in-meeting view. Both would consist of a left sidebar that would surface high-level info about the meeting and house the section-based navigation structure, with the right area dedicated to the section the user or team was currently on. While the engineering team was working on backend architecture for multiple meeting participants, I led the design team on a journeymapping and design ideation exercise to identify specific similarities between Meetings, Discussions and Check-Ins, and then converged the findings into a cohesive layout that ended up scaling not only to the three aforementioned tools, but also a different feature that focused more on content management (with the removal of the timer and the ability to add/modify sections on the fly).

Needless to say, PMs and PDs were stoked about the opportunity increased alignment. It meant killing more birds with one stone, and being able to reallocate resources to delivering more value instead of rebuilding disparate features from the ground up. And while the Check-Ins experience is still in the research and discovery phase, I know we'll have a much easier time getting it off the ground with a lot of the designs and core patterns already in place.