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.
snapshot
Platform: Uptempo Plan · SaaS · B2B Enterprise
Timeline: Q2 | ~2 months
My role: Lead Designer on feature
Team: PM, Engineer Lead, Devs (4), Platform Solution Engineer
Constraints: Bryntum library · Angular + React architecture · WCAG AA
Deliverable: Color By feature · Accessible color system
Problem: Enterprise marketing timelines can hold thousands of activities across dozens of campaigns. When every bar looks the same, pattern recognition collapses.
Outcome:
40% reduction in support tickets related to timeline readability
0 Accessibility violations — every color met WCAG AA (4.5:1 minimum)
↑ Strategic foundation set for future filtering and calendar features across the product
The feature request was simple. The real problem wasn't.
the problem
For enterprise customers like Swire Coca-Cola, Uptempo's timeline isn't just a planning tool — it's a shared artifact used by global teams to align on campaigns, spot execution gaps, and present status to leadership. When timelines hold thousands of activities, the ability to visually parse what you're looking at isn't a nice-to-have. It's the whole point.
The product already supported filtering by Type attributes via dropdowns — but the experience was entirely cognitive. You had to know what to look for, open a panel, select filters, and apply them. There was no way to just see what you had. Every bar on the timeline looked identical.
Customers — and our Principal SE, Drew — started asking for color. Specifically, the ability to assign their own brand colors to activity types. Coke Red. Sprite Green. Colors their teams already used internally as a shared organizational language.
The tension I needed to resolve: Brand colors aren't designed for accessibility. They'd fail contrast requirements against our timeline backgrounds — making the surface harder to read, not easier. Saying "yes" to the request as written would have shipped a regression dressed as a feature.
Core User Frustrations
No visual scanning
Every activity looked identical. Users couldn't identify campaign composition without opening individual items.
Cognitive filter load
Filtering required remembering attribute names, navigating panels, and applying queries — before any visual signal appeared.
Disconnected from how teams work
Teams already used color as an organizational language internally. The product didn't reflect that reality.
Falling behind competitors
Color-coded timelines were baseline expectations from tools like Monday.com. We weren't meeting the table stakes.
My job wasn't just to design color-coding. It was to figure out how to give customers meaningful visual differentiation without compromising readability, accessibility, or system stability — and to bring engineering along on that journey before a single pixel was placed.
I wasn't just executing. I was reframing the ask.
My role + Influence
As the lead designer, I was the first person to flag that the request — custom brand colors — was technically risky and accessible-color-incompatible. But I didn't just say no. I turned that constraint into a design problem worth solving: how do we give customers visual control within a system that protects them?
That reframe shaped everything. Instead of building a color picker that accepted any hex, I proposed a curated accessible palette — 10 pre-validated colors derived from Uptempo's design system — plus an optional custom hex pathway with a clear caveat that customers were responsible for verifying their own accessibility.
This wasn't a PM decision or an engineering call. It was a design decision that I made, socialized, and defended — and that became the foundation the team built on.
Where I Led
Problem reframing — Identified that the real ask was visual clarity, not brand color fidelity, and proposed a safer solution path before any design work began.
Accessibility advocacy — Drove WCAG AA as a non-negotiable standard, not a retrofit. Every color was tested across default, hover, selection, and overlap states.
Architectural influence — Spotted the opportunity to migrate configuration to React during parallel attribute-type work, and proposed it to PM and engineering as a strategic investment.
Cross-functional alignment — Facilitated constraint mapping with engineering before ideating, ensuring designs shipped within Bryntum's rendering limitations rather than aspiring past them.
Alignment before ideation.
Always.
Enterprise SaaS design doesn't fail at the concept stage — it fails at implementation when assumptions collide with constraints no one surfaced early enough. I structured this project to front-load alignment, not polish.
1
2
3
4
5
Collaboration
Kickoff: Mapping constraints before exploring solutions
Rather than starting with sketches, I convened PM and the engineering lead to map what already existed, where technical risk was highest, and what could realistically ship within our architecture. This session set the tone: clarity delivered sustainably, not perfection at any cost.
Three questions anchored the session: What can we reuse? Where's the highest technical risk? What's realistically shippable?
Translating field feedback into design requirements
Platform SE’s feedback from customer sessions was critical context. His sticky notes told me: customers needed color per attribute value, needed ~10–15 colors in one accessible place for stakeholder meetings, needed to opt in or out (no forced color palette), and needed a reliable reset path. This became my requirement brief — before a single frame was opened in Figma.
Getting deep on Bryntum before designing around it
Bryntum — our third-party timeline library — had strict constraints: restricted color layering, fixed hover and selection behaviors, limited control over dynamic contrast. I worked closely with the engineering lead to understand how Bryntum handled color rendering at a technical level before committing to visual directions that might not survive implementation.
Iterating in Figma, aligning in Miro
I created four focused iterations in Figma stress-testing color behavior in realistic, high-density timeline scenarios — overlapping activities, long-range planning views, mixed campaign types. Then I moved those iterations into Miro so PM and engineering could annotate, flag technical concerns, and align on feasibility without scattered Figma comments.
This dual-tool workflow meant design exploration didn't block engineering progress — we were testing in parallel, not in sequence.
Iterating in Figma, aligning in Miro
I created four focused iterations in Figma stress-testing color behavior in realistic, high-density timeline scenarios. Then I moved those iterations into Miro so PM and engineering could annotate, flag technical concerns, and align on feasibility without scattered Figma comments.
This dual-tool workflow meant design exploration didn't block engineering progress — we were testing in parallel, not in sequence.
Going beyond the request — by design
What I Built On Top of the Brief
I audited every color in the curated palette against timeline backgrounds across all relevant states — default, hover, selection, and overlapping activities — using Adobe Color and Figma's Color Contrast plugin. Every color met WCAG AA (4.5:1 contrast minimum). I removed opacity controls from the palette to prevent low-contrast combinations from being assembled accidentally.
And I documented the palette as a reusable system — not a one-off feature asset — so future surfaces (calendar, reporting, new timeline modes) could inherit it without repeating the audit work.
The Accessibility Decision
Why This Mattered Beyond This Feature
Shipping the accessible palette now meant every future surface that touched color had a validated foundation to inherit. Future teams wouldn't have to re-audit. Future customers wouldn't stumble into contrast failures they didn't know to look for. One proactive decision protected the product's quality forward.
Custom colors were always going to ship. That was never in question — it was the whole point of the feature, and customers needed the freedom to bring their own brand language to the timeline. Coke Red. Sprite Green. Colors their teams already recognized at a glance. We built that.
But while working through design iterations, I noticed something the brief hadn't accounted for. I'd pulled actual brand colors — Coke Red, Sprite Green, the kinds of colors customers were referencing — and applied them directly to timeline bars in Figma to see how they'd behave in a real, dense context. What I found was telling: several of those colors, at the small bar sizes and tight label spacing of a packed timeline, failed contrast requirements against our backgrounds. Some washed out. Others made the text sitting on top of them nearly illegible. The feature would ship, customers would use their brand colors with confidence — and some of those configurations would be genuinely harder to read than the default monochrome view they'd been frustrated with. That was a problem worth solving proactively.
So I took initiative. I didn't take away the custom color freedom — I added to it. I designed a curated palette of 10 pre-validated accessible colors, derived from Uptempo's existing design system, as a companion offering. Customers could use their own hex values freely, and they'd have a ready-made set of colors guaranteed to look great, pass contrast checks, and require zero second-guessing.
This wasn't a restriction — it was an upgrade. The accessible palette gave customers a faster, safer path to a polished result. Custom colors remained fully available alongside it. Both options shipped together. The accessible palette was something I identified, designed, and advocated for — it wasn't in the original brief.
Designing within reality, not around it — Bryntum constraints
Legibility requirements
Which color-background combinations would remain readable at Bryntum's rendered bar heights — not Figma's idealized mockup sizes.
Stable vs. brittle
Some visual treatments were technically possible but would create fragile workarounds. We explicitly mapped those and excluded them from scope — protecting the team from future maintenance debt.
Engineering Collaboration
What We Aligned On Together
Accessibility edge cases
Hover and selection states modified the rendered color — so we had to validate contrast not just at rest, but across every interactive state the library controlled.
Bryntum, our third-party timeline library, wasn't a minor implementation detail — it was the entire rendering engine for the timeline surface. And it had strict limitations that would directly shape what was designable: restricted color layering, fixed hover and selection behaviors, and limited dynamic control over contrast between colors and the text sitting on top of them.
Early in the process, before any high-fidelity work started, I sat down with the engineering lead specifically to understand how Bryntum handled color rendering at a technical level. Not to be handed a constraints list — but to actually understand the mechanics. Where exactly did Bryntum apply color? What happened to that color on hover? Could we control text contrast dynamically, or was that fixed? What would create brittle workarounds that break in edge cases versus what was genuinely stable?
Those conversations directly shaped design decisions that otherwise would have looked reasonable in Figma but fallen apart in the browser. The 10-color palette limit, for example, wasn't arbitrary — it was informed by understanding how many color values Bryntum could realistically manage within its rendering model without introducing instability.
The alternative was aspirational mockups. Designs that engineering would spend weeks trying to force through a library that wouldn't cooperate — only to surface the constraints at handoff, when course-correcting is expensive. Getting into the technical reality early meant the designs that went into review were already buildable.
Locking the design so intent survived implementation
Admin configuration flow
Color assignment per attribute value, palette picker, reset to default — the complete admin experience for setting up Color By.
Timeline output at every state
Default, color-assigned, hover, selection, and overlapping activities — every state a user would encounter in real usage.
High-Fidelity Wireframes
What the Final Design Covered
Visual parity across surfaces
The color assigned in admin is exactly what renders on the timeline — no translation loss, no surprises.
Accessibility documented at handoff
Every color at every state was annotated with its contrast ratio — ready for engineering to implement without guessing.
Once Miro alignment was complete and engineering had confirmed feasibility against the Bryntum constraints, I moved into high-fidelity final designs in Figma. This phase wasn't about exploration anymore — it was about precision. Every decision made in the iteration rounds needed to be expressed clearly enough that implementation couldn't drift from it.
The final designs covered the complete Color By user flow end-to-end: the admin configuration surface where color assignments are made, through to the timeline output where those assignments render. I designed both to feel like a single coherent system — because from the user's perspective, that's exactly what they are. Setting a color in admin and then switching to the timeline should feel seamless, not like two separate products that happen to be connected.
I documented all interactive states explicitly — default (Uptempo purple), color-assigned, hover, selection, and overlapping activities — each validated against the accessible palette before handoff. The "no color set" state was designed intentionally, not left as a gap.
Testing with enterprise customers — real data, real stakes
Testing
Before shipping, I reviewed the final design with Swire Coca-Cola's VP of Commercial Digital Strategy — using their actual timeline data. Not a demo dataset. Not a sanitized scenario. The messy, high-density, multi-campaign reality of how a global enterprise actually uses Uptempo.
We walked through different attribute-based color configurations — Color By region, by campaign type, by status. We put the timeline into dense planning scenarios with overlapping activities across quarters. And we asked the questions their leadership teams actually ask in meetings: "Where are the risks?" "What's happening in this region right now?" "Can you show me everything tied to this product line?"
The validation wasn't about confirming that colors looked nice. It was about confirming that the feature served real decisions — pattern recognition, risk identification, executive communication — at the scale and complexity enterprise teams operate at.
Timelines were easier to read — patterns and campaign overlaps surfaced at a glance without needing to open a single filter panel first.
The constrained palette felt sufficient, not limiting — 10 colors was enough for the complexity of their timeline. The worry that a curated palette would feel restrictive didn't materialise.
What the Feedback Told Us
The feature answered leadership questions — Color By became a tool for communication, not just organization. That was the real outcome we were designing toward
“Color By instantly changed how we read our timelines. We can spot patterns and issues at a glance — no more digging through every activity.”
Color By went live — and it held up
Shipping
Color By shipped to Uptempo's enterprise customer base. The feature functioned exactly as designed — no contrast violations in the wild, no rendering edge cases from Bryntum that hadn't already been accounted for, no emergency design revisions post-launch. The early constraint work paid off exactly as intended.
What struck me most post-launch wasn't the feature itself — it was what customers immediately started doing with it. Teams weren't just using Color By to organize. They were using it to present. Colored timelines became the artifact they brought into leadership meetings, into stakeholder reviews, into cross-functional syncs. The feature changed not just how they planned, but how they communicated their plans to others.
That wasn't explicitly in the brief. But it was the outcome that confirmed the design had hit something real.
ZERO Accessibility violations
Every color met WCAG AA across all states in production
No post-launch design revisions
The constraint-first process eliminated surprises at implementation
at launch
Adopted for stakeholder communication
Customers used colored timelines as presentation artifacts in leadership meetings
Results that went beyond "feature shipped"
02 · Accessibility
Zero contrast violations shipped
Every color in the palette met WCAG AA at 4.5:1 minimum across all states. This was the first time the timeline surface had been formally audited and validated at this level.
Results
03 · Product Health
A reusable color system for the product
The accessible palette became a shared design system asset — inherited by future timeline, calendar, and reporting features. One problem solved, many future problems prevented.
06 · Competitive Position
Met baseline + built ahead
While Monday.com set the baseline expectation, Uptempo's implementation was more thoughtfully constrained — accessible by default, and scalable by design
The Color By feature launched to positive enterprise reception. But the more important measure was what it enabled — both immediately for customers and strategically for the product.
01 · User Impact
Instant visual clarity at a glance
Teams could identify activity types, spot campaign overlap, and answer leadership questions — "Where are the risks?" "What's happening in this region?" — without opening a single filter panel.
04 · Architecture
React migration foundation set
My advocacy for migrating attribute configuration to React during the parallel initiative set up long-term product consistency. Future features wouldn't inherit fragmentation.
05 · Enterprise Validation
Confirmed by Swire Coca-Cola
"Color By instantly changed how we read our timelines. We can spot patterns and issues at a glance — no more digging through every activity." — VP, Commercial Digital Strategy
What this feature unlocked for the product
Next Steps
Near-term
Extending Color By to calendar and reporting views
The color system was built to be reusable — not just for timelines. The next surface is Uptempo's calendar view, where the same visual differentiation logic applies. Because the palette and token structure are already documented, implementation won't require a redesign from scratch. The design work is already done.
Strategic
Unified attribute configuration in React
The architectural migration I proposed during this project lays the groundwork for a fully unified configuration experience — having them all in a consistent React architecture means faster iteration, fewer edge cases, and a more coherent admin experience for enterprise customers.
The decisions made here, the palette we validated, the architecture we aligned on, opened up a clear and deliberate roadmap for where the timeline experience goes next.
Near-term
Custom hex support with accessibility guardrails
The MVP deliberately excluded free-form color entry to protect against contrast failures at launch. The next logical step is a custom hex pathway paired with real-time contrast validation — so customers can bring their brand colors with confidence, not risk. The accessible palette already sets the benchmark for what "passing" looks like.N
Medium-term
Color as a filter trigger — not just a visual signal
Currently, Color By is a display layer. The next evolution is making it interactive: clicking a color segment should filter the timeline to that category instantly. This closes the loop on the original cognitive load problem — users would move from "I see a pattern" to "I can isolate it" in a single click, without touching the filter panel at all.
What I'd do differently
Reflection
Involve the Principal
earlier in the process
Drew's feedback was foundational — it shaped the requirements brief that drove the entire design. But that feedback came through a batch of sticky notes rather than an ongoing dialogue. Earlier and more direct collaboration with the SE team — people who sit in front of customers every day — would have surfaced nuances I had to infer. In enterprise B2B, the SE is often the closest thing you have to a continuous research partner. I want to treat that relationship with more intentionality going forward.
What this project confirmed for me
I'm most effective when I'm involved at the problem-framing stage, not handed a brief after the constraints are already set.
Accessibility advocacy has to come from design. If I don't raise it early and consistently, it becomes a QA problem at the end — or worse, it ships broken.
Spotting the React migration opportunity taught me to keep one eye on the current ticket and one on the system it lives in. The best design decisions account for both.
Collaboration isn't a soft skill — it's how design intent survives from Figma to production. The relationships I built with engineering on this project paid dividends in every review and handoff.
Every project teaches you something you couldn't have learned before shipping it. Timeline Visuals was no exception.
Push for usability testing earlier
I validated the design with Drew's field feedback and an enterprise customer review — both valuable, both informed. But they weren't substitutes for watching admin users configure color assignments in real time, under their own conditions, with their own data. If I ran this again, I'd carve out time for even one moderated session before the final hi-fi was locked. The insights would likely be around edge cases I didn't anticipate — attribute sets with 20+ values, teams with conflicting color preferences, admins who manage multiple client orgs.
Document the "why not" decisions more explicitly
The decision to exclude unlimited brand colors from the MVP was the right call — but it was a decision that lived mostly in conversations and Miro comments. If I were doing this again, I'd codify it in a lightweight decision log: what was considered, what was rejected, and why. As the team changes, institutional memory disappears. A written record of the reasoning behind constraints protects future designers from relitigating solved problems.