In April of 2019 I accepted a position on the internal creative team at Splash, a SaaS startup in the event space, working to onboard new enterprise customers to the software by designing and building their new event websites in Splash’s CMS.
Throughout my time there I partnered with dozens of organizations in many verticals, to create branded event pages to integrate within their existing web ecosystems. This required me to become extremely adept at absorbing and re-interpreting existing design systems, and building with acute attention to detail to ensure a seamless experience for their customers.
Working inside of a CMS to implement the designs posed an interesting creative challenge: how can we create modern looking designs with a limited set of aging tools?
Planning for the future
Halfway through my time with Splash I was invited to New York to participate in a design sprint around planning the future of the CMS. Through the course of various design thinking exercises, some core themes emerged:
- The new version of the CMS should be data-agnostic
- Styles should be defined at an organization level
With a full rebuild of the Splash platform years in the future, the team focused on the second item, and within a couple months a new Org Level Stylesheet had been developed, and my Q4 goal became establishing the best practices for building moving forward.
Over the course of a month, I met with key stakeholders for the style guide project to gain an intimate knowledge of how the style guide worked. Through this understanding, I was able to do two things:
- Supervise the update of existing public themes so that they could take advantage of this new technology in a predictable way.
- Create a design system for the internal team to use when building new public and premium themes, to create a scalable future state.
A System for Design Systems
What I ended up creating is a framework that can be used by the designers at Splash Creative to quickly spin up new Branded Themes. I called it the Branded Themes Design System, and at it’s core it establishes the typographic scale, vertical rhythm, and layout grid, and serves as a template for how to apply colors and assign fonts in a way that will harmonize with the Organization Style Guide.
Any theme created using the principles established in this system could be applied to any event created by a customer who’s set up their Org Style Guide, and it will automatically be branded correctly. The really exciting part is that Splash customers are able to pull any block from a public block library. By setting all of these blocks up to use a consistent typographic scale, spacing, and layout grid for a basic framework, anyone can go in and pull any block from the library and they would snap together seamlessly.
In order for blocks to align to the grid they need to be built in a certain way, so I created this example to deconstruct the block building process, and show where to apply different paddings, and how different percentage values align to the different grid lines. An added bonus of the design system, is that the documentation actually serves as a teaching aide, and can be used to help onboard new designers to the team, and get them up to speed building effectively quicker.
This was a real passion project for me, and one of the last things I worked on while I was with Splash Creative. I worked closely with our team lead, and with partners on product design and engineering teams to make sure everything would align, that included biweekly check-ins with different stakeholders, and a final delivery presentation to the junior team members.
Designing new features
Another passion project for me while I was at splash was to pitch a new filter element for our event hubs. Clients would often request their listing pages have a calendar feature, but it wasn’t something that was supported by our software at the time.
During some down time I created a pitch deck for the new feature. Starting with a user story, running through some customer testimonials and associated TCV, then outlining the feature requirements, uses cases, possible design specifications, and a way to implement styling by tying the fields different elements to existing fields in our form styler.
Ultimately they decided not to prioritize this feature, but I remain optimistic that it will see the light of day in some iteration in the future.