Interviews
I asked what buyers wanted to know and which questions the sales team kept hearing.
B2B software website
Website UX · Front-end build
I redesigned and builtWhip Around’s website.
Whip Around helps businesses manage vehicle inspections and maintenance. Buyers needed to understand the software before starting a trial or booking a demo. I spoke with fleet buyers and users, planned the pages, and built the responsive website and landing pages.
What buyers needed before a trial or demo
Whip Around
My role. Research, design, code, and launch.
What I owned
I spoke with buyers, software users, and the Whip Around team. I reviewed site traffic and heatmaps, drew page plans, and worked with the team on the words. I designed and coded the site, then checked what visitors did after launch.
Buyer questionWhat does it do, and is it right for us?
Next stepStart a free trial or book a demo
UX + front-endFrom wireframes to the live site
Two clear next stepsTrial or demo, clearly signposted
ResearchBuyer interviews + heatmaps
Design + buildWebsite + landing pages
IterationChanges guided by site use
01 Buyers
Buyers needed to see how the software would help.
The old website listed features before explaining what Whip Around could do for a fleet. Buyers had to work out whether the software fit their team before starting a trial or booking a demo.
I spoke with buyers and people using the software. I used their questions, site traffic, and heatmaps to plan the pages. I designed the screens, built the front end, and checked what happened after launch.
I found the answers buyers were missing.
I compared interviews with page visits, clicks, and how far people scrolled. I checked what the site said and where buyers stopped.
Traffic paths
I checked where people entered the site, what they read next, and where they left.
Heatmaps
I reviewed where people clicked and how far they scrolled, including on phones.
Content audit
I found repeated details, missing answers, and too many buttons asking for attention.
Who I spoke with
Fleet teams helped me understand what buyers needed.
I spoke with fleet teams, people using the software, and the Whip Around team. I needed to learn what buyers cared about before they would try the product.
-
Fleet + maintenance
Owners + operatorsThe people responsible for vehicles, equipment, and keeping maintenance work moving.
-
Software users
Day-to-day useThe people already using Whip Around in their work, not just reading about its features.
-
Whip Around team
Stakeholders + buyer questionsThe people explaining the product and helping decide what the website needed to support.
I connected what I heard
I used their questions to plan the new pages.
The new pages explained what the software did, then showed how it could help. Customer proof appeared near the answers it supported. Buyers had a clear way to start a trial or book a demo.
- Product explanation
- Page order
- Proof + answers
- Demo path
Summary of the interviews, not a word-for-word transcript.
See example buyer questions
Different buyers needed different answers.
These examples show the questions each page needed to answer for different audience groups. They are not direct interview quotes.
Fleet owner or operator
What it does and how the team would start using it.
Needs to know: Will this make the operation easier without adding a system nobody uses?
Safety or compliance lead
How the team records inspections and follows up.
Needs to know: Will this help the team stay on top of inspections and accountability?
Operations or maintenance lead
How the team spots issues, plans maintenance, and keeps vehicles available.
Needs to know: Does this fit the way our fleet works?
02 Design
I gave buyers a clear path to a trial or demo.
Buyers could see what the software did, how it fit their work, and where to go next. I put answers and customer proof before the trial or demo choice.
01
Is this relevant to me?
Start with a vehicle or maintenance problem the buyer knows.
02
What does it help with?
Explain how the software helps with that problem.
03
Does it fit my operation?
Show how the tools fit the buyer’s day-to-day work.
04
Can I trust it?
Show customer proof beside the question it answers.
05
What do I do next?
Keep the free-trial and demo choices easy to find.
The old pages led with features.
- Feature detail came before a clear explanation of value.
- Answers and proof were scattered or arrived too late.
- Competing paths and desktop-first order weakened the mobile journey.
The new pages answered questions first.
- Lead with a fleet problem, then explain value and fit.
- Place proof beside the question it answers.
- Give each page a primary action and rethink the order for mobile.
The redesigned pages explained the product clearly.
I brought the product explanation, customer proof, and trial or demo choices into one path. Then I built the pages for desktop and mobile.
These are pages I designed and built. Some images show the fleet software, which was outside my redesign.
- 01Explain the product
The headline says what Whip Around does.
- 02Support it with proof
Ratings and customer logos sit near the introduction.
- 03Keep the next steps together
“Try for Free” and “Book a Demo” appear together.
Mobile path
I changed the page order for phones.
I shortened the opening text and moved key answers higher on the page. I coded the mobile layouts and checked the links, buttons, and reading order on smaller screens.
- Value before a long explanation
- Proof near the relevant claim
- A visible action with room to tap
03 Build
I built the pages and checked how they worked.
I wrote the HTML, CSS, and JavaScript for the website and landing pages. I built shared parts so the pages worked the same way. Then I tested the layouts and buttons through launch.
Structure first
I used wireframes to plan each page.
I drew simple page plans to decide where the answers, customer proof, and buttons should go. I worked with the team to make the headings easier to understand.
We could review the page plan before I designed the final layouts and coded them.
Simplified page-structure illustration.
Proof
Action
I made the pages easy to reuse and update.
I built shared menus, cards, buttons, and styles. The team could use them across the site while giving each page its own message.
Navigation
I grouped pages by the questions buyers brought to the site.
Page hierarchy
I put the key answer first, followed by proof and next steps.
Demo actions
I made the trial or demo button easy to find once buyers had the answer they needed.
Responsive order
I changed the layout and reading order to make the pages work on phones.
Interaction states
I made buttons, menus, and other controls work the same way across pages.
Measurement
I reviewed clicks and page visits to see which paths people used after launch.
Design into code
I checked the design in the working website.
I checked the pages on phones and computers. Because I designed and coded them, I could fix layout and button problems in the same pass.
- Reusable components across page types
- Responsive order, spacing, and navigation
- Build review and continued refinement
04 Review
After launch, I checked where people clicked and left.
I reviewed visits, clicks, scroll depth and exits, then used those patterns to guide changes to the live pages.
01
When content was skipped
I shortened it, moved it, changed the lead, or removed it.
02
When something looked clickable
I changed the interaction or its appearance so the two matched.
03
When mobile hid the next step
I changed the order and brought the demo path nearer the relevant content.
04
When actions competed
I made one action primary and gave the others a supporting role.
See what I reviewed after launch
Where people went
Entry pages, next pages, exits, and paths toward the demo.
What people saw
Scroll depth and important content visitors passed over.
What people tried
Click patterns, competing actions, and elements that looked clickable but were not.
Where the path broke
Differences between desktop and mobile reading order and actions.
05 Results
I launched the website and kept improving it.
I delivered the responsive website and landing pages, built reusable page components, and used analytics and heatmaps to guide changes after launch.
Clear product answers
I explained how the software helped before listing its features.
Trial or demo
Buyers could get answers and then choose a trial or a demo.
Reusable pages
I built menus, cards, and page layouts that the team could use again.
Changes after launch
I used real visits and clicks to improve the pages after launch.
See the full scope of my work
My contribution
I led the website work from buyer interviews and page plans through design, code, launch, and improvements after launch.
Stakeholder and user interviews
Analytics and traffic-pattern review
Heatmaps and behavior analysis
Content and page audit
Information architecture and navigation
Buyer journeys and page flows
Wireframes and page hierarchy
Copy restructuring and UX writing
Visual and responsive page design
HTML, CSS, JavaScript components, and build QA
CTA and demo-path design
Post-launch review and iteration
What I took from the work
I could improve the design and the code.
I talked with buyers, planned the pages, and built them. When visitor data showed something was hard to find, I could change both the page design and the code.