The terminology was heavy
A lot of infrastructure sites used language that made sense internally but asked too much of users too early.
Flagship project
Fabrc Cloud
Making cloud infrastructure easier to understand, compare and buy.
Prototype video[Prototype video placeholder]
- Role
- UX / Product Designer
- Areas
- UX strategy, prototyping, frontend implementation, ecommerce UX, onboarding
- Platform
- Cloud infrastructure / SaaS
- Focus
- VPS, bare metal, account onboarding, purchase journeys
Overview
Fabrc was a cloud infrastructure platform created from the rebrand of two existing THG infrastructure businesses. The initial focus was VPS and bare metal servers, sold globally through monthly billing, with self-service account management for smaller customers and direct sales support for larger organisations.
My role covered UX strategy, interaction design, prototyping, frontend implementation and collaboration with product, engineering, marketing and sales teams.
The challenge
- 01Infrastructure products can feel intimidating, especially when the journey starts with dense specs, technical language and too many choices.
- 02Competitor sites often assumed users already understood the terminology, configuration process and tradeoffs before they arrived.
- 03The experience needed to work for different users: technical buyers, less technical business users and larger organisations who would speak directly to sales.
- 04Fabrc also needed to earn trust quickly as a new brand built from two existing THG infrastructure businesses.
What I noticed
I looked at competitor sites, existing journeys and internal knowledge from the people closest to the product. The same issues kept coming up.
Comparison was harder than it needed to be
Users needed to compare server types, prices, locations and configuration options, but many journeys made that feel scattered.
Configuration felt intimidating
The more options shown at once, the harder it became to understand what was required now and what could wait.
The pages were visually dense
Competitor pages often looked credible but crowded, with long blocks of specs and unclear next steps.
Onboarding needed more care
Signing up to a cloud service should feel clear and guided, not like filling in an enterprise form before knowing what happens next.
Sales routes needed to be clearer
Some customers would self-serve, but larger prospects needed an obvious way to speak to the right person without feeling diverted away from the product.
Why ecommerce patterns made sense
VPS and bare metal servers are technical products, but the buying behaviour is still familiar: evaluate the options, compare what matters, choose a configuration and decide whether to buy or speak to someone.
Ecommerce patterns gave us a practical starting point. Clearer product cards, easier comparison, progressive disclosure, pricing visibility and better onboarding all helped make the journey feel less intimidating without pretending the product was simple.
Patterns that helped
Product cards made the offer easier to scan
VPS and bare metal products still involve evaluation and selection. Clear cards helped users understand what was available without reading everything at once.
Comparison patterns reduced the effort
Users are used to comparing plans, features and prices online. Borrowing that behaviour made the infrastructure decision feel more familiar.
Progressive disclosure kept the journey lighter
The aim was to show enough detail for confidence, then reveal configuration choices at the point they became useful.
Sales-led enquiries still needed a product journey
Even when a customer needed to contact sales, the site still had to help them understand the offer and ask a better question.
Designing and testing the purchase journey
This became the most important part of the work because it exposed where the product, technical constraints and user expectations met.
I explored purchase flows in Figma first, then moved into working prototypes so stakeholders could click through the journey rather than respond to static screens.
The configuration journey changed several times, particularly around how much to ask upfront and where technical detail should sit.
Progressive disclosure tested better than a longer multi-page journey because users could stay oriented while working through the choices.
One important decision was location versus server type. Some server types were not available in every location, and testing showed that location could be just as important as the server itself.
The final direction needed to support both ways of thinking: users who started with the server they wanted, and users who started with where it needed to be hosted.
[Purchase journey prototype/video placeholder]
Iteration and tradeoffs
The work changed through testing and practical delivery conversations. A few decisions mattered more than the initial design direction.
The visual style became calmer
Early designs were too dark and gradient-heavy. They looked polished, but they did not help the product feel clearer or more trustworthy, so the direction was simplified.
Motion was reduced
Some scroll and motion ideas were explored, but they did not add enough value in testing. The page worked better when the interaction focused on understanding and selection.
Technical detail had to be balanced
Users wanted enough detail to feel confident, but not so much that the experience became another dense infrastructure page.
Bare metal moved out of self-serve launch scope
The functionality was not ready for a complete self-service journey, so bare metal users were directed to contact sales for a quote. It was a practical tradeoff, not a pretend launch.
[Early visual direction placeholder]
[Iteration comparison placeholder]
Collaboration and delivery
- 01Worked with product owners and backend engineers to check that the journeys matched what could actually be built.
- 02Worked with marketing on clearer terminology, page structure and product messaging.
- 03Worked through onboarding so registration felt more guided and less like a cold form.
- 04Improved the contact route so sales could understand where leads came from and whether users preferred email or phone follow-up.
- 05Used prototypes and testing feedback to build confidence with stakeholders before implementation decisions were locked in.
- 06Supported frontend implementation directly, which reduced handoff friction and helped move from prototype to production-ready UI faster.
Image and video placeholders
Prototype video[Prototype video placeholder]
Interface screenshot[Purchase journey screenshot placeholder]
Interface screenshot[Comparison card screenshot placeholder]
Case study media[Before/after visual placeholder]
Process artefact[Testing/iteration artefact placeholder]
Case study media[Journey flow visual placeholder]
Outcome
- The simplified purchase journeys tested well throughout the project.
- Users responded positively to the look and feel and found the experience easier to use than typical infrastructure sites.
- The work helped create a clearer, more modern product experience for a new cloud infrastructure brand.
- The direction gave the business a stronger foundation for future services, including Kubernetes and additional platform functionality.
Reflection
This project is a good example of the kind of work I enjoy: taking something technical or messy, understanding where people are getting stuck, and making it easier to use without pretending the complexity does not exist.
The strongest decisions came from testing and iteration, especially around the purchase journey, information balance and what needed to be simplified for launch.