Product story → clear next step
Whip Around
Buyer questionWhat does it do, and is it right for us?
Next stepStart a free trial or book a demo
Live B2B SaaS redesign
Website strategy · UX/UI · front-end
Whip Around had a strong product. The website made buyers work too hard to understand it. I rebuilt the path from first question to trial or demo.
The goal: Help fleet buyers understand what Whip Around does, see how it fits their operation, and choose the right next step: start a free trial or book a demo.
B2B SaaSComplex product, clearer story
2 pathsFree trial or demo
End to endResearch through the live build
01 Buyers
The conversion problem started before the demo page.
Whip Around already had a strong fleet product. The website made buyers work too hard to understand it. The goal was clear: help more of the right visitors reach the free demo page.
I treated this as a buyer problem, not a button problem. A louder button could not fix an unclear story, scattered paths, repeated content, or a mobile experience that buried the point on smaller screens.
I redesigned and rebuilt the website around the way buyers make decisions. I spoke with users and the team, then studied traffic and heatmaps. I reorganized the site, wrote the copy, designed and built the pages, and kept improving them after launch.
I did not redesign the Whip Around application. I owned the website and landing pages around the product: how buyers first understood it, how they moved through the site, and how ready they felt to request a demo.
The question behind every decision
Does this help a fleet buyer understand enough to take the next step?
What I studied before redesigning the pages
One source would not be enough. Interviews showed me the questions and doubts. Analytics showed the paths people took. Heatmaps showed what they noticed, skipped, or tried to use.
Interviews and conversations
I listened for the questions buyers asked before they were ready to talk to sales. I also noted the words the team used when the product finally made sense.
Analytics and traffic paths
I studied where people entered, where they went next, where they left, which devices they used, and whether their path led toward a demo.
Heatmaps and behavior review
I looked at where attention stopped, what people tried to click, how far they scrolled, and where the mobile layout hid the next step.
Page and content audit
I found repeated ideas, missing answers, competing buttons, and pages that listed features before telling buyers why they mattered.
The buyer questions I designed around
The website could not give every buyer the same pitch. Fleet owners, safety leaders, and maintenance teams had different jobs. But they all needed one answer fast: is this worth a closer look?
Fleet owner or operator
Needs the value in plain English. The product has to feel useful, easy to adopt, and tied to problems already eating up the day.
Needs to know: Will this make the operation easier without becoming another system nobody uses?
Safety or compliance lead
Needs confidence that the product will help the team stay consistent, see what is happening, follow through, and keep reliable records.
Needs to know: Can this help the team stay ahead of inspections and hold people accountable?
Operations or maintenance lead
Needs to see how the product fits the daily work: finding problems sooner, organizing follow-up, and keeping vehicles on the road.
Needs to know: Does this fit the way our fleet actually works?
02 Frames
I stopped treating the site like a library and rebuilt it as a decision path.
The site did not need more pages or more copy. It needed a clear order that matched how buyers decide: keep reading, trust the product, and request a demo.
01
Is this relevant to me?
Open with a fleet problem the buyer already knows.
02
What does it help with?
Explain the product in plain English before showing the details.
03
Does it fit my operation?
Connect features to real jobs, daily work, and useful results.
04
Can I trust it?
Put proof and answers close to the moment of doubt.
05
What do I do next?
Keep the demo path clear, visible, and easy to use.
Principles that drove the redesign
These were not style choices. They were rules for what went on each page, what came first, and what helped the buyer move forward.
Clarity before depth
Buyers needed the simple answer before the full product story. Each page first had to explain the problem, the value, and who the product was for. The details came after.
One primary next step
The demo path could appear more than once, but it could not compete with a new goal in every section. Other actions had to support the main path.
Copy and interface together
I shaped the words and the page at the same time. A better headline changes the layout. Stronger proof changes where the button belongs. The two had to work together.
Mobile is not smaller desktop
I rebuilt the order, navigation, proof, spacing, and buttons for a smaller screen. Mobile had to keep the story clear, not just shrink the desktop page.
The buyer had to assemble the story.
- Feature language often came before buyers knew why the product mattered.
- The site offered several paths without making the best one clear.
- Important answers were often too late, too dense, or too far from the decision.
- The demo action existed, but the page did not always earn the click.
- Desktop order carried into mobile, even when it made the journey harder.
The site carried the buyer through the story.
- Pages opened with familiar fleet problems and a clearer promise.
- Navigation and page templates gave buyers a more direct route.
- Proof and answers appeared closer to the questions they supported.
- The demo action returned after the page gave buyers enough reason to take the next step.
- Mobile content was reordered around understanding and action.
One connected acquisition experience
The redesign brought the site structure, product story, page layout, proof, mobile experience, and demo path into one clear system.
The point was not to make a few pages look better. It was to make the full path from first question to demo feel clear and connected.
03 Build
From information architecture to working pages.
I carried the work into the live build because page order, spacing, interactions, and button placement all shape the experience. Those were not details to leave for someone else.
01
Define the conversion job
The goal was not “make the website better.” It was to explain the product faster and give buyers a clear, well-supported path to the free demo page.
02
Map the current experience
I mapped the navigation, page types, repeated content, demo points, traffic patterns, and the gaps between what the company knew and what buyers could find.
03
Rebuild the information architecture
I organized the site around buyer questions, product value, roles, use cases, proof, and a steady path toward a sales conversation.
04
Wireframe the argument
I used wireframes to set the order of the message, proof, details, and actions before polished design could hide a weak story.
05
Rewrite and design together
I worked with the team to sharpen headlines, simplify explanations, connect features to buyer value, and give every section one clear job.
06
Develop, test, and refine
I built the pages for desktop and mobile, watched how people used them, fixed what was not working, and kept improving after the design files were done.
Structure first
Wireframes were where the conversion logic got honest.
A polished page can make a weak story look finished. Wireframes took that cover away. They forced us to decide what buyers needed to know before asking for a demo felt reasonable.
I used them to set the page order, place proof beside key claims, control the amount of detail, and decide when the demo action should return.
The question was never “What section comes next?” It was “What will the buyer ask next?”
Proof
Action
The page system I built around the journey
The work had to hold together across the whole site, not just one landing page. I created repeatable rules for the story, proof, interactions, and demo path as the site grew.
Navigation and IA
Clearer labels, stronger page groups, and fewer dead ends helped visitors find the part of the product story that matched why they came.
Reusable page hierarchy
Product and landing pages followed the same clear order: relevance, value, fit, proof, details, answers, and a next step.
CTA rules
The free demo action looked and worked the same across the site. It returned when the page had earned the ask, not as noise in every section.
Responsive order
Mobile layouts followed the reading order instead of stacking desktop sections from left to right. Important proof and actions moved forward when the smaller screen called for it.
Readable interaction patterns
Buttons, links, cards, spacing, headings, and states worked in a more consistent way. The interface behaved the way it looked.
Measurement points
Key clicks and paths could be checked after launch. That gave the team a way to keep improving instead of treating launch as the finish line.
Design into code
The build was part of the UX.
Building the pages myself helped me protect the logic all the way to launch. The result depended on more than polished design files.
- Section order and spacing that worked on every screen
- Consistent components across page types
- Clear link, button, and hover states
- Demo actions that stayed easy to find and use
- A final build checked against the intended experience
Mobile path
The page still had to make sense with one thumb and half the space.
Mobile exposed every weak part of the page. Long openings, small tap targets, late proof, and hidden buttons cost more on a phone. I treated mobile as its own decision path.
- Shorter openings that showed the value sooner
- Navigation built around buyer tasks
- Proof placed closer to the claim
- Tap targets and spacing made for real use
- The demo path brought forward at the right moments
04 Learn
The launch was not the end of the UX work.
Analytics showed where people entered, where they went, and where they left. Heatmaps showed what they noticed, skipped, and tried to use. I needed both to see whether the new page order worked.
Where people went
The pages people entered, where they went next, where they left, and which routes moved them closer to a demo.
What people saw
How far people scrolled, which sections held attention, and which important messages they passed without reading.
What people tried
Where people clicked, what looked clickable but was not, which actions competed, and which elements failed to help.
Where the path broke
How desktop and mobile behavior differed, especially when a smaller screen broke the story or hid the next step.
Heatmaps were not the strategy. They were a way to check whether people were seeing and using the strategy.
A page can look right in a review and still fail when people use it. Behavior data helped me challenge the page instead of defend it.
How evidence changed the work
The goal was not to fill a dashboard. It was to make better choices about the message, page order, interactions, and demo path.
01
When key content was skipped
I cut it, moved it, rewrote the opening, or removed it. Being on the page did not mean it was helping.
02
When an element looked clickable
I fixed the design instead of blaming the visitor. An element should work the way it looks.
03
When mobile created a dead end
I changed the order, shortened the distance between the idea and the action, and moved the demo path forward without filling the page with buttons.
04
When actions competed
I chose one main action and gave the others a supporting role. More choices did not always make the path better.
Observe
Review traffic, heatmaps, page paths, and behavior around the most important pages and actions.
Diagnose
Find out whether the problem is the message, the order, the interaction, or a gap between what buyers expected and what the page gave them.
Change
Make the smallest change that clears the path. Reuse it across related pages when it works.
Check again
Return to real behavior and see whether the page became easier to understand and use.
05 Iteration
The real deliverable was a site the team could keep improving.
The redesign gave buyers a faster way to understand the product and a clearer route to the free demo page. It also gave the team a reusable page system and a practical way to keep improving after launch.
A clearer product story
Buyers no longer had to piece the value together from scattered feature copy. Each page moved through relevance, value, fit, and proof in a clearer order.
A direct demo path
The demo action became part of the story. It returned after the page had answered enough questions to make the next step feel natural.
A consistent page system
Navigation, page order, components, mobile behavior, and rules for the demo path could carry across the site without starting from scratch.
An evidence loop
Analytics and behavior review stayed part of the work. The team could keep testing the path instead of relying on opinions.
My contribution
What I actually did on Whip Around
This was not a surface redesign. I worked across research, story, site structure, visual design, development, and post-launch review. That kept the path connected from the first conversation to the live page.
Interviews with stakeholders and users
Website traffic and visitor-path review
Heatmaps and behavior review
Page and content audit
Site structure and navigation
Buyer journeys and page flows
Wireframes and page order
Copy structure and UX writing
Visual design for desktop and mobile
Front-end development and quality checks
Demo-path and call-to-action design
Post-launch review and improvements
The work in one sentence
I did not build the Whip Around app. I rebuilt the way buyers met it.
The website became a clearer bridge between a strong fleet product and the people deciding whether to take a closer look. This was more than a cleaner set of pages. I connected the research, words, structure, design, development, and measurement around one practical goal: make the next decision easier.