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.
Try the working prototype (opens in a new tab)
This is the v0 testing prototype, not the production build.
- Role
- UX Designer, THG
- Duration
- About 4 months
- Team
- Me as the only UX designer on the project
- Client
- THG / Fabrc Cloud
- Platform
- Cloud infrastructure / SaaS website
- Focus
- Purchase journeys, account onboarding, full frontend build
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.
I designed and built the entire website, from the homepage and product pages to the purchase journeys and onboarding. There were no frontend developers available to pick up the work, so I built it myself, with my AI-assisted prototypes doing the heavy lifting. Alongside that, I worked with product, backend 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.
Research and testing
THG's UX research team ran three studies with 10 participants each: a mix of CTOs and technical buyers, and general users interested in running their own servers. I designed what was tested and used the findings to shape each next round.
- 01Look and feel. Compared the Fabrc direction against competitor sites to confirm the overall visual approach.
- 02Server selection. The first configurator tested positively, but some users still found it hard to know which server to choose, and where.
- 03Two variants. A dynamic, step-by-step configurator against a standard ecommerce approach with selections made inside product cards. 8 out of 10 participants preferred the dynamic configurator.
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.
The dynamic configurator, revealing each choice as the previous one is made, was preferred by 8 out of 10 participants over a standard card-based approach.
The third study also changed the order of the journey. In testing, location came first, but most participants said the server was the most important part of their decision. So server type moved to the first step, with each server card showing which locations it's available in, so nobody picks a server they can't get where they need it.
01Server type cards lead with the specs people compare, what each one is good for, and a starting price.
02The chosen server collapses into a summary. Locations show availability, because not every server type is offered everywhere.
03Each completed choice stays visible and editable while the next step opens.
04A pinned summary keeps the running monthly price and the deploy action in view.
Screens from the v0 testing prototype, not the final production build.
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.
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.
More from the testing prototype
Outcome
- Three research studies with 30 participants shaped the look and feel, the configurator and the order of the journey.
- In the final study, 8 out of 10 participants preferred the dynamic configurator over a standard ecommerce approach.
- I designed and built the site, and it launched. THG moved away from the infrastructure business before the site was marketed, so there's no live performance data.
Reflection
What I enjoyed most was taking something technical and messy, understanding where people were getting stuck, and making it easier to use without pretending the complexity did 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.
Like what you see? Let's talk.
Email me at davidedwardsjones@googlemail.com, or get in touch through the contact page.