← projects

ux design web design client project

del vecchio home care

building trust and visibility for a word-of-mouth contractor in central jersey.

designer & developer 1 client · 0 photos provided figma · html / css / js njit · 2025
view live site →

the question

how does a skilled local contractor compete and convert new customers when his only marketing tool is word of mouth, and what does a first website need to do to close that gap?

what i did

nick runs a one-man home repair and renovation operation in central new jersey. he had no digital presence; no website, no google business profile, no portfolio. every customer came through a personal referral. if someone got his name from a neighbor and went to look him up, there was nothing there.

i was responsible for all discovery, design, and development: identifying the core user and business problems, defining the information architecture, writing all copy, and building the full site in html, css, and javascript. working with a sole proprietor who runs a fully active business meant designing without a steady content feedback loop, which shaped several key decisions.

figma html / css / js information architecture copywriting trust design client constraints

brand strategy

before designing anything, i identified nick's brand archetype as a blend of the regular guy and the hero. the regular guy comes through in the positioning: a neighbor, accessible pricing, no job too small, first-name basis. the hero enters when a customer has a crisis: a burst pipe at 11pm, a repair no one else will take on. these two archetypes in combination informed every copy and design decision: approachable enough that you'd call him for a small job, trustworthy enough that you'd call him for an emergency.

the site applies four of cialdini's principles of persuasion deliberately:

  • social proof — three named, located testimonials address the specific fears people have about contractors before they're even stated
  • liking — first-name framing, neighborhood-specific copy, and a conversational tone build familiarity with someone the visitor has never met
  • authority — "licensed & insured," the guarantee section, and the process breakdown reduce perceived risk
  • urgency — the emergency service CTA in the hero creates a separate conversion path for high-intent visitors who need help now

key problems

the absence of a website was not only a visibility problem, but a trust failure happening silently. when someone's neighbor recommends a contractor, the first thing they do is google them. finding nothing doesn't just fail to impress; it actively raises doubt. the website's primary job was to validate referrals that were already happening, not just attract new ones.

users don't approach contractor hiring neutrally, they arrive with anxiety. the dominant pain points (no-shows, ignored calls, upsells, ghosting, contractors who only want big jobs) are consistent across the category. competing on price or range of services alone doesn't address the real reason people hesitate. the design had to directly counter these specific fears, not just list what nick does.

"Other contractors wouldn't even return my calls for 'just' drywall patching."

this review, written into the site, is the thesis: nick's differentiation is reliability and willingness, not capability. the design reinforces that throughout.

visitors arrive in one of two emotional states: emergency (burst pipe, broken outlet, needs help now) or consideration (planning a kitchen reno over weeks). these users need completely different things from the same page. the emergency user needs a phone number immediately and zero friction. the consideration user needs trust signals, a service range, and a low-commitment way to reach out. the hero section holds both CTAs; "call for emergency service" and "get a free quote" as a direct response to this split.

generic contractor sites feel like they could be anywhere. naming specific towns signal that nick is a neighbor, not a distant service provider. the copy frame ("your neighbor you can trust," "serving central jersey") and the explicit service area section aren't just seo decisions. they're trust decisions: i know your area, i'm not a stranger.

designing without a content pipeline. this was a real client project with a sole proprietor who runs a fully active business, not a controlled classroom brief. working with someone managing jobs, calls, and customers daily meant i couldn't rely on a steady content feedback loop. the portfolio section was designed as a launch-ready placeholder system, intended to be populated as nick builds his photo archive over time. the service photography uses stock in the interim. launching before all content exists is a genuine and common real-world constraint, and designing a system that accommodates it, rather than waiting on it, was a deliberate decision.

design decisions

the site is structured around a single conversion goal: get nick a call or a form submission. every section exists to reduce a specific reason someone might leave without contacting him.

the process section (free quote → simple deposit → job done right) addresses the anxiety around hiring someone you don't know. the guarantee section ("we answer the phone. we show up. no job is too small.") is written directly against the contractor stereotype rather than ignoring it. the contact form is kept minimal: name, phone, and what you need, because adding friction to an inquiry reduces conversions.

the service area detail in the footer is partly seo infrastructure, but it's also a signal to the user that nick is local. the footer copy mirrors the hero: "big projects. small repairs. one neighbor you can trust." repetition of the core value proposition is intentional.

ux implications

01
design for the trust gap, not just the information gap
a first website for a service business isn't an information product, it's a credibility artifact. the user isn't looking for details; they're looking for reasons not to worry.
02
address category anxiety directly
in low-trust service markets, naming the fear ("other contractors don't answer the phone") and then countering it is more persuasive than a neutral feature list. the design that wins is the one that says: i know what you've been through, and i'm different.
03
support two user modes from a single entry point
when a page serves both high-urgency and low-urgency visitors, the hero must immediately route both. hiding the emergency path below the fold loses the user who needed help five minutes ago.
04
specificity is design work, not just content work
naming towns, including real testimonials, and using a specific local phone number are design decisions as much as layout is. generic = untrustworthy in a local services context.
05
plan for content you can't control
designing with real photos vs. stock photos is not an aesthetic decision, it's a trust decision. if a client can't provide assets, design a system that accommodates the gap gracefully and makes the next step clear.

what i learned

this was the first project where i had to do both the ux thinking and the full build with a real client rather than a fictional brief. working with a sole proprietor who runs an active business, not a classroom partner with time to review deliverables, meant making a lot of autonomous decisions. i couldn't always get feedback when i wanted it, so i had to develop a stronger instinct for when to move forward and when to hold. that was harder than any of the design problems.

i also came away with a much clearer sense of what trust design actually means in practice. it's easy to say "build trust" as a principle, but it's harder to identify the specific fears a user is arriving with and make design choices that address each one deliberately. this project made that concrete for me in a way that classroom examples hadn't.

midway through the project, nick temporarily stopped accepting new clients. rather than creating a feature branch to hold that state separately from main, i committed the changes directly with the intention of reverting later. it worked, but it was the wrong call. it made the codebase more difficult and created unnecessary risk around cleanly reverting. the right approach would have been a dedicated branch for the "closed" state, merged into main only when live, and easily switched off when he reopened. i know that now because i felt the friction of not doing it. version control isn't just a technical habit; it's a decision about how you manage a site as a living system over time.

the known gaps: stock photography standing in for real project photos, and a portfolio section waiting on content, are things i'd address as the engagement continues. knowing what the next version of the site needs, and why, is part of how i think about design as an ongoing system rather than a one-time deliverable.

view live site →