Problems:
• Complete lack of design system
• High instances of inconsistencies
• User interviews yielded confusion and hesitation with product functionality due to modules that differed in style
Goals
• Create visual consistency
• Build components that could be reiterated and built upon to make more rapid prototyping
• Bridge the gap between design and development by giving access to a published Figma library and including a hand-ff in Figma's dev-mode.
Once I established the atomic level (color, typography, layout, etc), I tackled the molecular level of buttons, input fields, tables... the real meat of SPHEREboard's components.
One key usability problem was the variety of button stylization. Users noted that they weren't sure what to expect when they pressed a button, thus avoided using certain components out of fear of incorrect submissions.
Users noted apprehension when performing actions due to button inconsistency. Do buttons with different styles perform the same or differently?
One of the most crucial problems that arose from my early research was the tables, which were the key feature in almost every module.
The new design of the tables helped to inform the creation of what became the SPHEREboard design system.
Working alongside experts across multiple teams (QA, Engineering, Security), I presented a solution in the form of 3 different tables that would address every user need: simple, actionable, and granular.
With each iteration of these tables, a large bulk of the design system came to life with many molecules that would go on to build new features in upcoming releases.
The most complex table was the granular table. This table had the most customizable features, from advanced filters to saved settings so that users could reference multiple views of data at any given time.
One key element that was highly requested was the ability to include and/or parameters when filtering data. Prior to this redesign, users had no choice but to make queries in SQL from the backend, completely ignoring the front end of the very product that SPHERE was selling to customers.
One key element that was highly requested was the ability to include and/or parameters when filtering data. Prior to this redesign, users had no choice but to make queries in SQL from the backend, completely ignoring the front end of the very product that SPHERE was selling to customers.
The SPHEREboard design system continued to evolve with each release.
Through an empathetic design approach, I listened to what users said and made data informed decisions to make their workflow as efficient and intuitive as possible.
I redesigned the functionality of the Asset Review Module (ARM) to include the game changing capability to accept or deny assets in bulk. Compared to the previous method where each asset had to be dealt with individually, now the same workload can be performed in a fraction of the time.
Through implementation and action, I showcased the importance of having a scalable design system. Not only did this visually elevate SPHEREboard to the enterprise level platform that it is, the system also made the process of updates and designing new features more seamless and efficient. The Development team also fully supported having access to the library via Figma with open communication.