AbstractOps
STARTUP
OVERVIEW
AbstractOps is a platform that helps companies better manage compliance across their scattered platforms. Through the unification of data from a user's HR and finance systems, they make admin work easier by streamlining tedious processes.
I was the only designer on the team, working closely with AbstractOps' engineers, paralegals, and clients. As of the past few months, I've been collaborating with 2 new designers from the Upperstudy team.
Design System
UI Audit & Cleanup
During my initial assessment of the entire product, I discovered many inconsistencies in layout and functionality that made it feel disjointed. At this point in time, the team only wanted me to clean up the existing UI in a low-lift manner so they could launch a new feature as quickly as possible, so using my audit notes, I identified patterns and created new consolidated layouts for each screen type category I found.
UI audit
UI cleanup
Creating a Design System
As the product evolved, the team wanted the interface to feel more friendly and less corporate, so I created a brand-new design system with new theming and components. This design system was meant to refresh the interface while still maintaining AbstractOps’ primary blue.
New Design System – Interface Theme (top), Interface Components (bottom left), Component Details Documents (bottom right)
OLD DESIGN SYSTEM
State Compliance
State compliance is an essential part of running a company, as businesses must be registered in all the required departments for the states their employees are located in to be payroll tax compliant and properly pay their employees. I worked on creating a user experience that broke down the entire legal process into easier-to-understand steps for users, giving them greater visibility over their responsibilities and the overall process.
Problem
A major issue I observed from client interviews was that users were often confused by the varying processes for each state. They felt like they were constantly in the unknown over who was handling the different parts of their registrations and would become frustrated at AbstractOps for delays even if it was actually another party’s fault. This was because the existing experience didn’t properly represent the back-and-forth nature of the process, the responsible parties, or the timeline.
Feature Requirements
Since the registration process isn't linear and is different for every state, I needed to find a consistent yet adaptable way to represent all states and their corresponding department registrations. Working with the team’s paralegals, I determined a set of key features for the new experience. These included:
A loose timeline showing what steps are dependent on others, who is responsible for each step, and specific statuses of registrations for specific departments within a state
A clear distinction between actions the user needs to do and actions other parties are responsible for
A place to store registration info and documents
A way to submit and manage issues
Since the goal was to launch these updates quickly, the team had me use the old design system that I done a quick UI cleanup of.
Dashboard
The previous dashboard consisted of a single table, which users found too vague, as it failed to flag issues and provide sufficient info about the status of their registrations.
Old State Compliance Dashboard
To give users a better understanding of their registrations at a glance, I created distinct sections for the new dashboard. These sections highlight the users’ main goals of seeing what they need to do, the status of things other parties are handling, and a general overview of their states.
New State Compliance Dashboard
State View
The old state view was a sequence of events combining and convoluting the user’s tasks and other parties’ tasks in a single workflow. This was highly misleading since department registrations aren’t processed one after another like the view suggests. In reality, they're processed in parallel, each with their own multi-step process.
Old State View
To better represent this parallel processing and the separation of responsibilities, I approached the new state view as more of a database, which provides a synopsis of all department registrations for a state and any tasks the user needs to complete. Breaking down the state into its departments and its departments into its responsible parties gives users more reassurance, as they can now hold specific parties accountable for the different processing stages.
New State View – In Progress Registrations
New State View – Completed Registrations
Issue Management
When users had issues or received notices from states, they would communicate with our team through email or Notion documents for help. Having external communication made it difficult to keep track of issues, both for clients and for AbstractOps’ paralegal team, so I designed a flow within the product for users to submit and manage issues.
Issue Submission & Management
NEW DESIGN SYSTEM
Compensation
After state compliance, the team developed a new platform centered on the idea of people and compensation. This platform draws from a company’s existing HR and finance systems to compile all its employee data. With all their data in one place, users can plan for the future of their company without needing to constantly jump between apps.
Integrations
Users need a means of connecting their apps to the platform, so I developed a flow to sign up, link and manage integrations. By connecting their integrations, users can pull data from their HR and Finance apps into platform.
Linking Integrations
Your Team
To make the most of integrated data, I created a team view that brings together select pieces of employee info that are used for common admin use cases. This gives users quick access to a common data sets they’d need in their admin tasks that would typically be scattered across different apps.
Team View + Person Drawer
I also worked on a full-page person view and org chart, but the team decided based on user interviews that a simple table and drawer to view info about people would be adequate enough for the first version of the platform, as those were the views users gravitated to and found most useful.
Person View (Archived)
Org Chart (Archived)
Creating a Comp Policy
Compensation planning is crucial to ensuring employees are paid properly. There are so many variables that influence compensation that things can get confusing for users when trying to figure out what’s right for their company. AbstractOps’ compensation app resolves this by helping users craft a unique compensation policy for their company based on specific framework settings catered to them.
User Flow
Creating a compensation policy is a mostly self-serve task with the help of AO Suggest (AbstractOps’ AI suggestions). The biggest challenge in mapping out this flow was figuring out the nature of interactions between the user and AO Suggest, as the process would ideally be automated but work closely with users to ensure recommendations align with their needs.
Creating a Compensation Policy
Reflection
ADAPTABILITY
Working with a seed startup that's constantly changing direction has taught me a ton about adaptability. The team has tried out so many different product concepts within a short span of time and in turn many projects and designs were scrapped along the way. From this, I've learned the value of being able to pivot quickly, as nothing is ever final and experimentation is simply a part of figuring things out. Without trying out new ideas (even ones that seem unconventional), there'd be no way of truly knowing what works and what doesn't.
QA with engineers
An issue the team has always faced is UI discrepancies between Figma designs and the actual built product. There was often a lack of communication regarding interface issues, so I created a table to lay out any implementation concerns and organize them into one place. This table improved collaboration with engineers and helped ensure that my design intents would actually manifest in the product.
QA Table