Don't Build Every Client's Website the Same Way
Don't Build Every Client's Website the Same Way
One thing I've learned from building websites for different businesses is that experience doesn't mean you stop learning.
Even if you're a highly experienced website developer, you still have to learn the niche.
You still have to look at the competition.
And even if you're already familiar with the niche, you can't assume that everything you've learned from one business automatically applies to another.
Businesses can have similar customers and still operate very differently.
That's exactly what I ran into with one of my recent projects.
The clientele was similar to other businesses in the niche, but this particular business was in a different market. Its customers were accustomed to doing things a different way.
So I couldn't just take what I had built somewhere else and drop it onto this business.
I had to adapt.
That doesn't mean you throw everything you've learned out the window.
Quite the opposite.
You take those existing principles and use them as a starting point.
They're your stepping stones.
Then you build upon them based on what you learn from the actual customers you're serving.
Experience Should Be a Toolbox, Not a Template
This applies whether you're just getting started or you've been building websites for years.
Don't get stuck thinking:
"This is how I do it for every client."
That's one of the easiest traps to fall into once you've been doing something for a long time.
You develop a process.
You figure out what works.
You build a few successful websites.
Then you start thinking every new client should follow the same formula.
But every client is different.
Every audience is different.
Every market is different.
And sometimes the things you think a business needs aren't actually what its customers need.
Your experience should give you a bigger arsenal of tools—not a reason to use every tool on every project.
Start With the Fundamentals
With each new client, I think you should start from the beginning with the basic fundamentals.
What does this business do?
Who are its customers?
What information do those customers need?
What are they already accustomed to?
What are competitors doing?
What can be improved?
What actually needs to be on the website right now?
Those fundamentals give you your starting point.
Then you adapt them over time based on what happens in the real world.
That's the part you can't completely figure out in a staging environment.
You can spend weeks or months building a website, adding features, tweaking layouts, and trying to anticipate every possible customer need.
But eventually, you have to launch Version 1.
Because that's when you start getting real information.
Your Customers Are Part of the Testing
Here's the funny thing about spending too long developing a website:
You and your client may be the only people looking at it.
Day after day.
You're staring at the same pages.
Clicking the same buttons.
Reading the same sentences.
After a while, you stop seeing things that are right in front of you.
Then you launch it.
Suddenly, you start catching things.
A spelling mistake.
A weird sentence.
A button that isn't as obvious as you thought.
A form that works perfectly when you test it but confuses an actual customer.
Something that looks great on your desktop but is awkward on a phone.
Or a feature that technically works but doesn't make sense when someone who has never seen the system tries to use it.
You can catch a lot of these things during testing.
But you can't catch everything.
That's because you're testing in a controlled environment.
Real customers aren't controlled.
They aren't going to use your website exactly the way you imagined they would.
They're going to click things you didn't expect them to click.
They're going to ask questions you didn't anticipate.
They're going to use their phones, tablets, laptops and desktops.
They're going to have different levels of technical ability.
And they're going to approach the same problem in completely different ways.
That's when you learn what actually works.
Launching Is Another Form of Testing
This doesn't mean you shouldn't test a website before launch.
You absolutely should.
Check the links.
Test the forms.
Check it on mobile.
Check it on desktop.
Proofread it.
Test the functionality.
Do everything you reasonably can before putting it in front of the public.
But understand that there is a limit to what you can test in a controlled environment.
Eventually, you have to put it into the uncontrolled environment.
That's where real-world testing begins.
The same thing happened with the newsletter.
Once we started sending emails, we began seeing things differently.
We learned which information people actually cared about.
We caught wording that could be clearer.
We learned which links people clicked.
We learned what questions kept coming back.
The newsletter itself became another way to test our assumptions about what customers needed.
And those lessons went right back into the website.
Sometimes the answer wasn't to add more technology.
Sometimes it was to simplify the technology.
Because the best solution isn't necessarily the most sophisticated one.
It's the one that makes the most sense for the people actually using it.
Don't Over-Engineer Version One
One of the biggest mistakes you can make is over-engineering a website from day one.
You might think:
"I added this feature for another client on Day 100, so obviously this client needs it on Day 1."
Not necessarily.
This particular customer base may not need it right now.
They may not need it for another six months.
They may never need it at all.
That's okay.
You can keep those ideas in your arsenal.
Keep them in your coat pocket.
They're tools you can pull out when the situation actually calls for them.
You don't have to apply every lesson you've learned from previous projects on the first day of a new project.
That's the difference between having experience and being trapped by your experience.
Everybody Has a Version One
Every website has a Version 1.
Every product has a Version 1.
Every system has a Version 1.
You can call it a beta test if you want.
You can call it a soft launch.
You can call it an initial release.
The name doesn't really matter.
At some point, real people have to use it.
Sometimes you have to test with real people and let real things happen.
Then you adjust.
That's not an indication that you didn't know what you were doing.
It's how you learn what you couldn't have known beforehand.
I would rather launch a well-built Version 1 and learn from real customers than spend months trying to build the theoretical perfect website before anyone has used it.
Start with the fundamentals.
Build what you know the business needs.
Test it as thoroughly as you reasonably can.
Launch it.
Pay attention.
Then improve it.
The website should evolve as your understanding of the business evolves.
And sometimes that means removing things just as much as adding them.
Because the goal isn't to build the website with the most features.
The goal is to build the website that works best for that particular business and its customers.
Your experience gives you a head start.
It doesn't give you all the answers.
Every new client is another opportunity to learn.
So don't bring your last client's website to your next client.
Bring the experience from your last client.
Then start learning again.
Thanks for reading The Deep Dive!
What do you think?
Have a thought about this Deep Dive? I'd love to hear it.
Email me at thedeepdive@touchesoftech.com and let me know what you think—or send along an idea for something you'd like to see explored in a future Deep Dive.
I can't promise I'll write about every suggestion, but I'm always interested in hearing what you're curious about.