Cin7.com

I joined Cin7 as a Senior Product Designer in late 2020 after being shoulder tapped by an ex-colleague.

I did my homework before joining, and learned that the platform was effectively a mini-ERP. An ERP is software that helps businesses manage their operations and sell stuff everywhere simultaneously; from retail outlets that needed a POS, to Shopify stores and big retailers like Walmart and Amazon.

The software Cin7 offered was an order of magnitude cheaper than traditional ERPs, and was one of the easiest ways that customers could go digital and set up EDI connections to big retailers that required it as part of the sales process.

For context: if you sell products to enterprise companies like Nordstrom or Walmart, most of the time you are contractually required by your terms of trade agreement to use a standard called EDI to make transactions happen as part of your sales process.

I was the first designer to be hired in a long time, and the company was in a state of exciting flux. As the company rapidly expanded, it encountered new obstacles in product development. At the time, it presented challenges like significant technical debt, and a platform that demonstrated immense levels of experience fragmentation.

Think about it this way — product design at the time was owned by a dev + product team of 50 people. Zero designers were involved in the product or engineering process. Challenge accepted.

This process came with a price. It resulted in a product platform that was held together by duct tape and effectively became a different product every time you switched modules ie: going from viewing products to customers

I jumped into the work headfirst, supported my team on every feature and bugfix I could get my hands on, and discovered a rats nest of problems.

The code was 20+ years old. I'm talking multiple different versions of React/CRA, AngularJS, and ASP.Net codebases smoooshed into a single app. The top navigation component was a separate react app to the current page. Likewise with the sidebar navigation. All of this was wrapped in an ASP.Net application running on an ancient .NET Framework backend.

In response to everything discovered above, the first thing I proposed was a consolidation of components into a single unified library and a partial re-architecture of the front end to simplify the experience. Deliverables in Figma for designers, and Storybook for developers.

This was impossible to tackle piecemeal — four designers before me had tried to do it module by module as conventional wisdom recommended. Every successive attempt failed, resulting in even more experience fragmentation.

To get stakeholder buy in across product, management, and engineering I put together a high level sitemap of the system with figma which you can see below, and then mapped out the current state of the platform.

I then did some rapid prototyping in our dev environment over a day and a half by using CSS editor chrome extensions.

I would've used Figma, but the product was incredibly data dense and data entry heavy. It was literally faster to build a lot of the interactions in code to get a feel for how the system would work.

Using code also meant that I could do rapid usability testing without spending too much time building out the interactions in figma.

This approach quickly and cheaply proved my hypothesis that we could make easy wins with CSS and basic semantic markup changes, at the cost of minimal additional tech debt. It also meant that we could cycle through iterations in minutes, instead of spending weeks building out text input prototypes in Figma that were incapable of emulating large amounts of data entry.

The prototype was a hit with management, and I was given the go ahead to start working on the frontend rebuild on the codebase as a product designer, which was hosted on Azure DevOps at the time.

A lot of the work after this included negotiating with engineering teams and getting mentored on how to write .aspx and .ascx up to an acceptable standard to get the design system into place while touching as little technical debt as possible ie: cutting our losses on difficult edge cases that would've taken months to rebuild.

One particularly egregious example included templated pages that were built in a way that made them impossible to redesign without a complete rebuild. I'm talking about webpages consisting of custom customer-defined HTML/CSS/JS, C# and SQL mashed together that were stored as string literals in the database. Many ungodly technical sins were committed. Some by me, and some by my team to get us to production.

I then set about building out a really basic design system in tandem, which included a Figma component library, a React storybook component library, and a set of design guidelines that would help us standardise the experience across the platform so that the rest of my team could fast follow.

This way, design and dev could be kept tightly in sync.

It took about two weeks to get 80% of the design system into place in a development environment. Maybe about a month after that to get the polish and a lot of responsive behaviors working across pages. overflow-x: scroll was my best friend when it came to many of the complex table components, especially for making dense components responsive.

position: sticky solved a lot of existing problems for support staff who had to constantly tell users to click the save button, and reduced a lot of friction on the platform when I made save buttons persistent on the page for users and staff.

Most of the work also involved improving the developer experience by stripping out outdated components styled with nested <table> elements, float properties, position: absolute; abuse, and redundant overuse of !important.

Turns out, moving to a more modern approach where components are constructed with display: flex; and display: grid; significantly improves the frontend experience for developers and helps the whole team ship faster.

To get it to production, we undertook a big bang approach to releasing the update. That meant every touchpoint and module on the platform was updated at once when we deployed the design system update in production.

It was a risky move, but it paid off. I had a lot of support from the engineering team, and we were able to get the update out in a week.

It worked.

I can't publicly provide specifics, but loosely after the rebuild..

• Customer NPS spiked upwards Redacted%
• Frontend development velocity increased 3X
• Support ticket volumes were down Redacted% YoY
• Churn was down Redacted% YoY

So after celebrating the successful launch of the system redesign, I got to work documenting all the new system norms.

On the problem validation side of the spectrum — I tried to normalise some parts of design thinking that I found useful. Our product team was mostly involved on the problem validation side — We would collaborate on research, user needs, and functional requirements at this step before deciding on bets.

On the solution validation side of the work: I set up a few design guidelines in the design system: Like rapidly prototyping with as few primary actions on a page as possible, setting consistent spacing between components, and normalising the use of consistent components like buttons, cards, and inputs across the platform.

Overall, we collectively purged the majority of the experience fragmentation that had plagued the platform for years. Once we had some breathing room, I documented most of this in Figma, and then propagated it to storybook — you can see me give a talk about it here at a meetup in 2021.

This work paved the way for further investment into design as a discipline at the company. Design was leveraged across more projects to get more wins, and I was able to scale the design team to 3 people before moving onto the next challenge.

I might write about more projects later on, but the Donut Design System was one the most impactful ones I was about to pull off at Cin7.