In leading the design team at Tealium, I desired to convey my vision for how the design team would grow from a few designers to a full-scale team of 30+ designers over time. To strategically grow the team, beginning phases emphasized product feature design utilizing designers who were generalists, and with expansion of the team, including more specialized roles around supporting product designers via user research, build out of a design system, and asset creation, etc... As the team scales, more efficiencies could be realized.
To communicate the value add of individual roles within the design team, I created a one-pager that details out the primary responsibilities of each position. These roles and responsibilities highlight why each role is necessary, and what can be expected with the addition of that role to the team. In combination with the organization scaling plan, it was easy to communicate to both the current team and management the full picture of what the team would look like as it grows.
In a growing startup, it was important to have everyone on the same page. With new designers, new product managers, engineers, stakeholders, etc... creating a formalized design workflow helped communicate expectations, timelines, and responsibilities as features went from the product backlog to production. This workflow was customized around Tealium's overall product feature life cycle in combination with the development strategy. At Tealium, an emphasis was placed on ensuring solid business requirements and design specifications prior to beginning development.
This is an example of an annual plan of objectives which highlight the top priorities for the design team based on company strategy and areas for improvement. In this case, areas included usability and design validation prior to development, a lack of consistency across the product, the lack of graphics and visualizations for product features, the disjointed experience as users cross from the product into areas such as the support portal and documentation, and to prepare for future company growth and distributed teams.
In combination with creating annual design objectives, a roadmap I maintained a quarterly roadmap indicating when specific deliverables would be completed. This allowed for resource planning with the team that was in place, as well as communicated prioritized deliverables that would be possible with additional resources. In addition, it helped ensure prerequisites were addressed prior to taking on dependent tasks.
Tealium has had a few minor efforts at creating a design system. After two separate attempts that were incredibly incomplete, and difficult to maintain. It became a goal for 2020 to institute a full fledged design system. In doing so, foundational elements such as grids, iconography, and typography topped the list, with priority number one being a color system.
Unlike most design systems which focus on a just a few hues, and possibly 8 levels of brightness, Tealium's design system is intended to eventually extend beyond the product alone, and into customer touch-points including community forums, and marketing material. We desired to build out a full pallet across many hues that could be used for user generated badges and labels, while still looking good with the product pallet.
As a whole, the the color system was inspired by San Diego, the home of Tealium's headquarters. The vibrant colors of the consistently blue sky, aqua color of the water, yellow accents on buildings, etc. all played a part. The overall look of the product is white and bright, and the vibrant accent colors give it a friendly feel that is fitting with the company's culture and offsets the dreary corporate feel of legacy enterprise applications of the past.
Several system level constraints helped define our pallet such as reserving status colors like red, orange, and green to only be used for indicating status (success, failure, warning). This drove the use of desaturated colors like Mint and Coral to be incorporated for use in areas such as customer defined labels, as well as in charts and graph visualizations. Blues and purples, being status neutral, were expanded to allow a broader range of hues for use in gradients and well as charts and graph visualizations.
Care was taken to avoid a muddy looking pallet as dark shades of yellow and orange often do if applied uniformly across hues. Similarly, the pallet was reduced by removing many of the darker colors where it wouldn't be clear what the difference between the colors would be, for example Aqua 850 vs. Sky 850.
Another deliberate decision was to avoid a straight pallet of grays. Our system grays start out with no saturation on the light side, and build up a slight blue saturation as they get darker. While gray is appropriate and often used to shade areas such as header backgrounds and toolbars, the slightly saturated dark text helps takes away dullness of gray on gray.
This is an example of one of the components that I built out for the design system. These components utilize Figma’s auto-layout functionality to make it easy for designers to copy into their mockups and modify the content. Additionally, much thought and consideration was put into the naming, organization and variations to ensure they were relatively easy to maintain, and make creating mockups incredibly effecient.
This is an example of a UI pattern I created to replace our existing use of accoridions throughout the products. This pattern is designed to facilitate organizing and locating items from an enormous list of possibilities. As users need to locate and take action on a few items amongst thousands, this pattern is designed to handle the most extreme use cases Tealium’s customers face.
This is an example of a UI pattern I created to replace our existing use of modals. This pattern is designed to solve many issues by maximizing screen real-estate, keeping users in context as they dive deep into configurations, and enables users to be incredibly efficient.
In this example, you can see the iterations leading up to the final UI pattern. This pattern had three objectives, all which mean allowing the user to quickly navigate to list items which they may have pinned for quick access, items which were selected as part of a multi-step selection, and items which might otherwise get lost because they were added and don't match the currently applied filter. The end solution is a simple and elegant way to address these otherwise often skipped over use cases.
This is an example of a feature I designed to handle user permissions. This feature mockup showcases annotations, handling of edge cases, errors , and is an example of what would be shared with product managers and developers. This specific example is a V1 of a larger vision which would include managing roles and profiles.