Timeline Visuals — Balancing Customization, Accessibility, and Scale
As Uptempo’s enterprise customers scale their marketing operations, the timeline becomes one of the most frequently used — and most fragile — surfaces in the product. For customers like Swire Coca-Cola (USA), timelines are not just schedules; they are shared artifacts used by global teams to align planning, execution, and reporting.
As timelines grew denser, customers increasingly asked for ways to visually differentiate activities. Many specifically requested the ability to use their own brand colors to represent regions, campaign types, or internal structures — something they were already familiar with from other tools.
This project focused on introducing color-based differentiation while carefully balancing customer flexibility, accessibility, and system stability.
-
Uptempo Plan (SaaS Platform)
-
2025
-
Lead Product Designer
-
Project Manager, Engineer Lead, Lead Software Developer, Four (4) Supportive Software Developers, Two (2) Professional Service Team Members, & UX Technical Writer
-
Marketing Technology (Enterprise SaaS)
Problem Space: Customization vs. Clarity
Customers wanted more control over how their timelines looked — especially the ability to map activities to their own brand colors. On the surface, this made sense: brand colors are familiar, meaningful, and already embedded in how teams think about their work.
However, during internal reviews with PMs and engineers, a deeper problem emerged:
Brand colors vary widely in contrast and accessibility
Many aren’t designed for dense calendar views
Allowing unlimited custom colors would make timelines harder to read, not easier
Without guardrails, color could quickly become decorative instead of informative — undermining the original goal of clarity.
The Challenge: Delivering Value Without Creating Risk
The challenge wasn’t whether to add color — it was how much freedom to allow.
Key constraints shaped the solution:
A mixed front-end architecture (Angular configuration, React timeline)
A third-party timeline library (Bryntum) with limited color control
Strict accessibility requirements
Customer requests for brand-level customization
Together with PMs, I framed the problem as:
How might we introduce meaningful visual differentiation now, without locking ourselves into an unsafe or unscalable system later?
results & impact
Although success wasn’t measured through quantitative metrics, the impact of the Color By feature was immediately observable in how customers interacted with the timeline.
Faster visual comprehension
Teams could instantly differentiate activities by attribute without clicking into each item, making timelines easier to scan during planning and review sessions.Reduced cognitive load in dense plans
Color introduced visual hierarchy where none existed before, allowing users to focus on patterns, overlaps, and risks instead of decoding identical activities.Safer customization for enterprise teams
By limiting choices to an accessible, curated palette, teams gained flexibility without risking inconsistent or unreadable timelines over time.Stronger alignment with enterprise expectations
The feature met baseline expectations set by tools like Monday.com while remaining enterprise-ready in terms of stability and accessibility.Improved confidence in the timeline surface
Timelines evolved from static planning artifacts into reliable visual narratives that leadership teams could confidently reference.
“Color By instantly changed how we read our timelines. We can spot patterns and issues at a glance now—no more digging through every activity.”
— Vice President, Commercial Digital Strategy, Swire Coca-Cola (USA)Design Approach Designing for Reality, Not Ideals
Given the clarity of the UX need, this project leaned heavily into UI systems, technical feasibility, and accessibility, rather than exploratory solutioning. My focus was on designing a scalable, enterprise-ready color experience that could survive real-world constraints.
Starting with alignment, not ideation
The project began with a kickoff session involving PMs and engineers from both the Plan and Spend sides of the product. Rather than whiteboarding solutions, the conversation focused on constraints:
What already existed?
What could realistically be reused?
Where would we incur the highest technical risk?
This early alignment helped set the tone: the goal wasn’t perfection—it was clarity delivered sustainably.
1
Responding to brand color requests with a safer alternative
Rather than supporting unlimited brand colors, I proposed:
A curated set of 10 accessible colors from Uptempo’s palette
Inclusion of Uptempo’s default purple to maintain continuity
Removal of shades and opacity controls
This allowed customers to differentiate attributes while avoiding low-contrast or misleading combinations.
Design Rationale
Brand colors are not inherently accessible. A controlled palette ensured immediate usability while leaving room for future expansion.
2
Accessibility as the backbone of the solution
Because color became the primary differentiator on the timeline, accessibility was treated as a design requirement—not a nice-to-have.
Tested all approved colors against timeline backgrounds and interaction states
Validated contrast ratios against WCAG accessibility standards
Balanced accessibility needs with strict brand constraints, without introducing new colors
Design Rationale
Relying on color without proper contrast excludes users and creates risk for enterprise customers. Designing accessible defaults ensured the feature worked for everyone, regardless of visual ability or screen conditions.
3
The Angular vs. React decision: choosing pragmatism for the MVP
One of the most important—and least visible—decisions was where the configuration UI would live.
The admin/configuration area was already built in Angular
The timeline itself was built in React
The Color Picker existed as an Angular component on the Spend side
Rebuilding the entire configuration experience in React wasn’t realistic within the iteration. After discussions with PM and engineering, we made a deliberate MVP decision:
Ship using Angular for configuration, adapt the React logic behind the scenes, and keep the timeline experience consistent.
Design Rationale
In an agile enterprise environment, momentum matters. This decision allowed us to deliver customer value without stalling the roadmap or introducing unnecessary technical debt.
4
Thinking beyond the MVP: spotting the “once-in-a-while” opportunity
While Color By shipped using Angular configuration, a parallel initiative around attribute types and type groups created a rare opening.
Attributes power everything:
Attribute definitions
Type groups
And ultimately, the Color By feature itself
During that work, I proposed redesigning this foundational section using React components. Opportunities like this don’t appear often in agile environments—and missing them means living with fragmentation for years.
Design Rationale
This wasn’t just about Color By. It was about aligning the system underneath it, so future features wouldn’t inherit the same limitations.
5
Collaborating with engineering on Bryntum constraints
Bryntum, the third-party library powering our timeline, came with strict constraints that directly influenced how color could be applied and rendered.
Key limitations included:
Restricted support for color layering
Fixed hover and selection behaviors
Limited control over how colors and text contrast were applied dynamically
Because Bryntum was already deeply embedded in the product, replacing or heavily overriding it wasn’t an option.
Instead, I worked closely with the engineering lead on the project to understand how Bryntum handled color rendering at a technical level. While engineering owned the testing and integration, we collaborated frequently to align on design intent—especially around legibility, accessibility, and edge cases.
Design Rationale
Strong design–engineering collaboration prevented brittle workarounds and ensured long-term stability.
Engineers Testing BryntumAutomating text contrast based on background color proved particularly challenging within Bryntum’s constraints. Engineers had to manually test and validate color combinations to ensure readability across different states, while I supported this effort by:
Defining clear contrast expectations
Limiting the color palette to reduce risk
Adjusting design decisions based on what proved stable in implementation
6
Exploring Real-World States with Miro (Iterative Wireframes)
While engineering focused on integrating Bryntum with our constrained color system, I used Miro as a fast, collaborative space to explore how the Color By feature would behave in the real-world scenarios our enterprise customers care about most.
Instead of broad ideation, these wireframes were grounded in known customer usage patterns. I created four focused iterations, each representing a high-impact timeline state where visual differentiation plays a critical role.
Design Rationale
Iterating in Miro allowed us to pressure-test the feature early, using realistic data density, without blocking engineering progress. It ensured we designed for how customers actually use timelines — not just ideal, low-density scenarios.
These iterations explored:
High-density timelines with overlapping activities
Different “Color By” attribute selections (status, region, type)
Long-range planning views where color repetition becomes more noticeable
Mixed activity types sharing the same time frame
Each iteration helped refine:
Where color meaning was immediately clear
Where visual noise started to appear
Which states required stricter constraints to remain readable
I reviewed these wireframes regularly with the PM and shared them with engineering to ensure alignment with Bryntum’s technical realities.
7
Final Design in Figma: From Intent to Execution
Once we aligned on the most valuable states through Miro and engineering confirmed feasibility, I transitioned the work into high-fidelity designs in Figma.
These designs reflected the final, approved Uptempo color palette, which had already passed accessibility contrast checks. At this stage, the goal was no longer exploration — it was clarity, consistency, and readiness for implementation.
Design Rationale
Moving from exploratory wireframes to locked high-fidelity designs ensured that design intent survived implementation. It also reduced last-minute changes, accelerated delivery, and made validation with Swire more focused and productive.
The final designs included:
The complete Color By user flow, from configuration to timeline output
Clear default behavior using Uptempo’s purple
Accessible color application across hover, selection, and overlapping states
Visual parity between configuration and timeline experiences
By this point, design and engineering were fully aligned on:
What the feature would look like
How it would behave
Where flexibility intentionally stopped
8
testing : Enterprise validation
The most important validation step was reviewing the feature with Swire’s VP of Commercial Digital Strategy.
Using their real timelines, we walked through:
Different attribute-based color views
Dense planning scenarios with overlapping activities
Leadership-level questions like “Where are the risks?” and “What’s happening in this region?”
The feedback focused on outcomes, not UI:
Timelines were easier to read
Patterns and overlaps surfaced immediately
The constrained color set felt sufficient, not limiting
Design Rationale
Validating with an enterprise decision-maker confirmed that the feature supported real planning and prioritization—not just visual polish.
9
Confidence before scale
By the end of testing, we had confidence that:
The feature behaved predictably across real data
Visual clarity held up under scale
Accessibility requirements were met within technical constraints
The experience aligned with enterprise expectations set by similar tools
Design Rationale
Enterprise features need to earn trust before adoption. Thorough, context-driven testing ensured this feature could scale safely across customers without creating downstream issues.
Final Productkey learnings
This project reinforced that strong enterprise design is rarely about finding the most flexible solution—it’s about making thoughtful trade-offs that protect clarity, accessibility, and long-term system health.
Designing the Color By feature showed me how easily well-intentioned customer requests (such as using brand colors) can create unintended complexity. Translating those requests into a safer, more scalable solution required aligning early with PMs and engineering, and being comfortable saying “not yet” in service of the product’s future.
The work also highlighted the critical importance of accessibility when colour carries meaning. Contrast testing, state validation, and real-world density checks weren’t optional steps—they directly shaped design decisions and reduced risk for enterprise customers.
Finally, this project reaffirmed the value of close collaboration. Working alongside PMs to frame the right constraints, and engineers to understand Bryntum’s limits, ensured that design intent survived implementation—and that the final solution worked reliably at enterprise scale.
project takeaway 🧠
This project reinforced a core principle of enterprise design:
The most valuable solutions are often the most restrained ones.
By prioritizing clarity, accessibility, and system health over unlimited customization, we delivered a feature that scales — not just visually, but operationally.