Voyadores
Elevated an existing NESV internal tool into a credible, market-facing SaaS product — brand, system, and implementation, solo.
- ProjectVoyadores
- Timeframe2 months
- RoleUX/UI Engineer
- Websitevoyadores.com
- Brand Design01
- Web & Experiential02
- Web Apps03
Voyadores was a working internal tool — functional, in production, and built on years of ad-hoc CSS decisions with no defined visual identity. NESV wanted to take it to market. The feature set wasn't the problem. The product didn't look or feel like something you'd pay for.
The constraint: one engineer, no external agency, no brand precedent to work from. The product existed. The work was to elevate it — without rebuilding what already worked.
The audit ran from the logo to the web application. On the brand side: nothing had been formally defined. No mark, no color system, no typographic decisions made with intent. Every visual element was an inherited default or an ad-hoc choice — none of it documented, none of it deliberate.
On the engineering side: twenty separate CSS files handling global and page-level styles, no shared token layer, components styled independently with no inheritance. The same visual decision made differently in at least three places. Bootstrap was already in use across the team's projects, but the ad-hoc overrides had accumulated to a point where the framework's structure had been effectively abandoned.
"The interface wasn't broken. It just never asked anyone to trust it."
The framing decision: define the brand before touching the codebase. Every downstream engineering decision — what to extend in Bootstrap, what token values to set, what the component visual language would be — needed something real to reference. Starting in the CSS without a defined identity would have meant making brand decisions inside a SASS file. That's the wrong tool for that problem.
Logo work came first. I sketched multiple directions, developed the strongest variations into refined proposals, and ran two rounds of stakeholder presentations with three rounds of logo iteration before the final mark was locked. The lighthouse held up across every round — a symbol of guidance and clarity that the product's own purpose could support. Stakeholder sign-off on the logo was the prerequisite for everything that followed.
Developed brand guidelines covering visual identity, color system, typography, shape language, and content standards — written to serve engineering, sales, and marketing from a single reference, not just the build.
Used the audit findings and guidelines together as the direct input for Bootstrap customisation: the audit identified what the existing framework couldn't cover; the guidelines defined the visual decisions that filled those gaps.
Extended Bootstrap with custom SASS — new utilities, component classes, and overrides compiled into a final CSS output; tech ops worked directly with the updated class system in markup, no SASS knowledge required.
Reduced 20 legacy CSS files to 3 — only the global context styles that Bootstrap's cascade couldn't handle remained; everything else is now covered by the extended theme.
Wired the compiled theme into core UI components and custom plugins so every surface inherits from the same foundation.
Documented the system in structured Markdown files — a design system site wasn't achievable within the one-month timeline, so documentation shipped as Markdown references that engineering, sales, and marketing could each use.
The rollout wasn't clean. Elevating a live product at this scope surfaces issues a contained redesign wouldn't. Component edge cases emerged. Inherited styles conflicted with the new theme. Extended classes needed adjustment once they met existing markup in production. Those issues were worked through in the iterations that followed the initial release. The first release established the foundation; the subsequent ones made it stable. The tradeoff: the extended class system required real adaptation time even though Bootstrap itself was already familiar to the team. Tech ops knew the framework. They didn't know the new utilities and component extensions — that gap was real, and the Markdown documentation, while accurate, wasn't enough to close it quickly. Better onboarding material at launch — structured walkthroughs, not just references — would have shortened the adaptation curve.
A coherent product across every surface — marketing site, login experience, web app UI, and help center. Seven people across marketing, design, engineering, QA, and support work from the same foundation: brand guidelines they can each reference for their own function, and a compiled theme they can apply without touching the build system. The 20-file CSS sprawl is gone. Visual decisions are documented, tokenised, and inherited — not guessed at per component.
I'd build the design system site alongside the guidelines, even at minimal fidelity. The Markdown references were accurate and complete, but they don't surface the relationships between decisions the way a living reference does. Seven people across five functions were being asked to work from the same source of truth — that demands a tool built for navigation, not a folder of files. The guidelines existed from day one. The infrastructure to make them actually usable across the team didn't arrive until later, and that gap created adoption friction that an early low-fidelity site would have prevented. I'd also establish the token layer before touching any components. Some visual decisions were made before they were systematised, which produced a round of backfilling that token-first thinking from the start would have eliminated.
