DIES
Approx. reading time:
5 minutes
Role(s)
Design Engineer (Visual Designer)
Industry
Employer of Record (EOR)
Duration
6 months
Project Snapshot
Context
A leading EOR company sought to boost its website’s conversion rate. After doing internal and external consulting, they decided on overhauling their landing page funnel’s experience. They hired two contractors, Contractor A: to guide the strategic and creative direction of the product, and Contractor B: to bring the product to reality (that’s my team!).
Challenge(s)
Having spent 6 months running co-creation workshops, the core team had tailored down a bunch of great ideas (including an AI-powered chatbot) to structure the MVP’s PRD. The challenge? They had six months to launch and hadn't written a single line of code. That’s where we came in.
Goal(s)
With only 6 months left before launch and no code written, we were tasked with transforming a Framer prototype into a live, scalable platform.
Design Process
I like to present my case studies using the three milestones that we can find if we squint our eyes and take a look at the Double Diamond (UK Design Council, 2003). I borrowed the methodology’s terminology to facilitate understanding, calling them Discover, Define and Deliver.
Discover
Working at an agency meant adapting our workflow to meet both client needs and tight deadlines. We started by diagnosing the situation and finding the projects main challenges:
Siloed work (yay!): each contractor worked isolated in their own world, only reaching out to the other to deliver final decisions that weren’t as actionable as they could’ve been.
Frequent visual changes: visuals were still evolving when we joined, causing delays as we had to constantly track changes and update the code. These changes had to be manually tracked using browser inspection tools… and I believe we all know how lethargic that can be.
Time constraints: we had 6 months before launch.
Define
Contractor A used Framer to quickly bring the product to life. Even though the tool facilitated socialization, it was of no use for a smooth implementation (at least back in 2023). To align design and development, we migrated key UI elements from Framer into Figma and adopted Tokens Studio to build a scalable, dev-friendly visual foundation. Using Atomic Design principles, we divided the process into three stages:
Defining the foundation: we defined core colors and text styles, as well as spacing values, to create a “Primitive” token set in Tokens Studio and establish a single source of truth for platform-wide visual values.
Auditing and scaling: we audited the existing UI to categorize these values in a “Semantic” token set that linked directly to the Primitive set, ensuring bulk updates could be made efficiently. Naming conventions were co-defined between design and development by matching the best practices that mostly suited the project’s needs.
Building atomically with tokens: using the defined token sets, we designed, documented, and delivered components at the atomic level. These were then nested to form molecules, organisms, and templates, providing solid, scalable foundations for a Design System.
Deliver
Development began as soon as we joined the project, starting with manual UI coding until we could deliver a more organized system. Throughout the project, we held regular hand-over sessions to streamline collaboration. These sessions evolved in three stages:
Initial definitions: we scaffolded the way the UI would be temporarily handled, agreeing on which elements would become components, their names and token naming conventions.
Token implementation and first hand-overs: after defining and auditing the tokens, I handed over a .JSON file that contained all the design tokens, along side a few atom components for them to start aligning/implementing.
Recurring hand-overs: once I either finished or had to update a component (due to Contractor A changes), we had hand-over sessions to communicate and properly implement the elements. This went all the way until we had all atoms, molecules, organisms and templates in code.
Outcomes
Results
After tons of hard work and constant synchronization, we landed in December with the MVP in UAT and began 2024 with a live product. There were three big results that came out of this process:
0 to Live in 6 months: self-explanatory, but still deserving recognition. We went from manually inspecting and coding elements to building the whole UI via design tokens and atomic elements in a matter of months
Design System: by working code-to-code with development (pun intended) and designing in both Atomic and programmatic fashions, we delivered a lightweight, scalable Design System, that reduced hand-over time by 92% — from 60-minute weekly sessions to 30 minutes every two months, plus 5-minute bi-weekly updates. A key gain for us to meet tight deadlines.
First day, first lead: even though our engagement was over, we were delighted to hear the early impact of the solution when the Product Owner reached out to tell us it had captured its first lead on day one.
Next Steps
We were so keen to solve today’s problems that we lost sight of tomorrow’s opportunities. Despite the fact that our contract ended once the MVP launched, we managed to share our thoughts a couple of times around key areas to focus on afterwards:
Post-launch enhancements: we were really keen on gathering post-launch user feedback through surveys, analytics, and/or usability testing to identify the MVP’s opportunities for optimization. We especially wanted to test out key conversion touch points, like the end quote screen or the contact information form, to validate design hypotheses and iteratively improve the experience based on real user behavior.
Future features: looking ahead, our focus was on expanding the platform’s capabilities with personalized AI features, such as voice chatting and predictive text suggestions to facilitate HCI.
Scalability: we knew the Design System would need to grow to accommodate future features. We saw these challenges as opportunities to strengthen collaboration with product, marketing, and growth teams to ensure alignment with broader business objectives.
Learnings
I ended this engagement with three key takeaways, both from the work I did and from how I saw others do theirs:
From my work
Designers ≠ only executers
We were brought in merely as a means to an end: code and launch. Even though we stuck to doing that (with exceeding expectations, I daresay), we proactively contributed beyond our quest —eg. developing initial future features and post-MVP integration proposals. These opportunities arose due to the fact that, as time passed, we became intrinsically ingrained within the project and its key stakeholders. Give a designer a brief and they will comply, give them an opportunity and they will design.
From others’ work
Even if someone says “I understand”, it does not necessarily mean they indeed understood
We had the misfortune of encountering UI bugs and coded discrepancies that reached the client's eyes and raised concerns. Why? The team struggled with implementing design tokens. The reason? Not everyone was familiar with the concept (true story). This called for:
Design documentation refinement: by adding more details where necessary and fine tuning the language to better align with tech’s expectations.
A proper 'Design Tokens 101' session: to walk the team through the concept from the ground up, resolving remaining doubts to ensure clarity in both the concept and its implementation.
Even Cristiano Ronaldo needs a team
Contractor A was essentially a one-man band. To this day, I’m still amazed by the speed at which they could develop highly creative and functional work. Their Achilles' heel? They were not the best team players. Our biggest setback was still manually keeping up with the changes they made to the product. There were no heads-up and no explanation as to where, when, or why changes were being made —just the expectation that we had to keep up with them.
Let's create something together! Hit me up using the following form.
