provides alcoholic beverage companies software to manage their inventory, accounting, capital, customer service, and logistics. I was hired as their UI/UX Designer to help reduce CSS bloat, minimize design inconsistencies, and work with product owners to create new features.
Each tool had multiple features and sub-tools. Used by internal employees and clients. I worked with an incredible team composed of backend developers, frontend developers, and product owners. All committed to making this new venture of design and product improvements work.
Reducing CSS Bloat
When I started the team was already using Angular 1.x. Which presented a few roadblocks as to how we would move forward with our CSS architecture. We initially wanted to use Styled Components but that was not possible with Angular 1.x, at least, not at the time I was there. This is were BEM and Tachyons came into the picture.
Tachyons is a CSS framework where each CSS class has a single purpose. It does one thing and one thing well. Also known as functional CSS. At the end of the day we're trying to avoid the cascade as much as possible. BEM stands for block, element, modifier. It's a naming methodology in CSS to help get a grip over global styles.
Tachyons was perfect because it was just pure CSS. At that time the project relied heavily on an older version of Bootstrap. I couldn't just rip that out. At the same time, as a team, we were skeptical of bringing in any new CSS frameworks. We decided to play it by ear. I would bring in what we needed from Tachyons, as we needed it, and pre-fix it with additional letters just to be extra sure we wouldn't clash with Bootstrap. If it made more sense for use to use BEM to build out a component's css we would use it and place it in it's specific angular component folder. Here's a presentation I put together, with the help of our frontend team, to make the argument for using BEM and Tachyons to our CTO.
Accounts Receivable graph re-design
The original Accounts receivable graph was extremely difficult for our users to quickly read through and understand. There was no direct correlation between the graph and the table data. The two most important pieces information for users "what was overdue?", and "what was coming up due?" was difficult to quickly tell apart.
With the re-design, we gave the graph a title. Kept the dollar amount (Balance) on the y-axis with a clear dollar sign symbol and condensed the days on the x-axis into four different buckets. 0-15 days, 16-30 days, 31-45 days, and 45+ days. We differentiated "Total Amount Due" and Total Amount Overdue" by assigning each a distinct color. This color would then be used as a label to easily spot invoices that were "Overdue" or "Due in" in our card table data. Color was another project on to itself.
At the end we played it safe and went with colors that people who use accounting tools would be familiar with. The old design used the brand's red color, regardless if it was overdue or coming up due. We used grey for "Due in" because it's a neutral color. We don't want to set off any alarms for invoices that were still in good standing. We used orange for invoices that were "Overdue" because it's bright enough to set off a flag but not as harsh as red. We wanted to set off a flag not set off a full blown alarm. We wanted to leave red for drastic measures. For example accounts that were at risk of being sent to collections.
I worked on a few other features that I unfortunately can't share. But, the overarching theme through out the rest of the tools tries to be very similar. Easy to read text with clearer hierarchy. The use of white space to create some breathing room between elements. Minimizing random floating elements.
Again the idea was to create some sort of design consistency through out all the different tools. That's not to say we didn't come across features in which context mattered more than consistency and that's fine. It's in those moments where you realize your design system can, and should be flexible to future unknowns.