A new website is a powerful marketing tool. Keeping in mind up-to-date best practices in terms of conversion rate optimization (CRO), user experience (UX), and search engine optimization (SEO), you can launch a beautiful website that satisfies your audience and addresses your business priorities, whether that’s informational, leads, or sales.
However, the internet is littered with a graveyard of half-finished development websites or websites that were launched with no clear plan or direction.
In order to get to the desired outcome on time and on budget, while fulfilling all of the requirements of the original scope, there are a few helpful principles you should keep in mind. Let’s get started:
Clearly scope out the project beforehand
WordPress or SquareSpace? Plugins or custom functionality? Template or custom theme? Builder or static? Gated content or not? Stock images or client-provided? These are just a handful of the endless possible questions you have to weigh when planning a new website.
There are so many different approaches, far too many to explore here. My recommendation is to start with the end in mind, and then choose a setup that aligns with your needs.
For example if you need non-technical users to make content updates, you probably don’t want text changes to be restricted to GitHub pushes. If product sales are the most important, it makes sense to build on a platform like Shopify.
How many wireframes or mockups are needed? What custom functionality is needed? Are there any required integrations, such as feeding leads to the client’s CRM software? Is the sitemap staying the same, growing, or shrinking?
Work with the client and ask the right questions to ensure no stone is left unturned. You don’t want to find out a week before launch that they need a multilingual content setup, and you definitely don’t want to discover that the approach you decided doesn’t serve their business needs.
While you provide a ballpark estimate if a quick quote is required, doing your due diligence in the scoping phase will pay tangible dividends in the later stages of the project.
Clarify the unknowns
This builds off the previous principles, but you don’t want to leave anything up to chance. Who is writing content? Who is sourcing imagery? Where will the finished site be hosted? Do your future self a favour and never settle for “we’ll figure it out when we get there” for any part of the project plan.
If there truly are unknowns that can’t be answered in the scoping stage, I recommend going with an agile project management methodology versus waterfall so you can adapt the project plan to the evolving requirements.
For example if you are waiting on a third-party to finish up photography, that may require holding off on the mockups. However can you proceed with any tasks that are not dependent on these assets, like the wireframes or creating the development environment?
If you suspect that domain access may be an issue, tackle it early (way, way before pre-launch) so you have time to get in contact with the right IT people, start the transfer process, and so on.
Don’t be shy to ask questions. Clarifying the unknowns might be the difference between a project that launches on time and on budget, and one that never gets off the ground.
Learn from past projects
Derails are going to happen, and you can’t prepare for everything. However, there are learnings you can take from each project to broaden your anticipation skills.
If the last project had an issue with SSL propagation, make sure you build it into your discovery and project plan on your next one. If your last project ran into problems with form settings, then build the correction into your Q/A process for this site.
When you finish a project, you should do a debrief with the stakeholders and unpack what worked and what didn’t. Evaluate everything from communication to project management to technical specifications, and document your learnings so future you (and your future colleagues) wil benefit.
Solicit feedback early and often
It is much easier to throw a concept in the reject pile in the planning or prototyping stage, versus when you hand a completed development site to a client.
Solicit feedback from day one – what kind of design do they love? What functionality do they hate? What brands inspire them, and which websites or apps repel them? All of these insights will help you get on the same page with the client.
When you send designs for feedback, it is much better to start small and iterate as needed.
Many designers opt to start with a “style tile,” where you share colour schemes, fonts, and component designs, such as the look of a call-to-action (CTA) button or form.
This staged approach also helps to keep the focus on the right elements at the right time – focusing on layout in the wireframe stage and not being sidetracked by the colour of the call-to-action (CTA) button.
Get approval on the overall design direction before handing over the full brand style guide. Get feedback on the homepage mockup before mocking up all pages.
From the client perspective, be honest and detailed with your feedback. The more insight the designer has into your mindset, the more they can revise the designs to match your vision, or at least explain why they still want to advocate for the initial design.
Set aside time to really sit with the designs and share detailed feedback. For example, while mobile-first design is certainly key, you’ll want to review desktop mockups on a desktop device for a full visualization of the design vision.
Discuss risks in advance
When you start a new project, it’s fresh and exciting. Who wants to be a buzzkill and start talking about all the ways the project can go sideways? Especially if you don’t have an existing relationship with the client, you want to make a strong first impression.
It’s a tough lesson to learn, but the strongest impression you can make is one of being sincere and transparent. An expert does not get there by being perfect, with a flawless track record. Quite the opposite, your clients often rely on you because they know you’ve seen it all – good, bad, and ugly.
Lay your cards bare on the table. What could threaten the project on our end? Capacity issues, time management challenges, technical roadblocks like bugs with integrating third-party software.
What could threaten the project on the client’s end? Delayed response times, endless revisions, scope creep, too many decision makers, and so on.
Have an open dialogue about these risks, how you can work together to mitigate them, and how you all agree to move past them should they arise.
It’s not an easy conversation – but it’s much easier than having the conversation when the potential risks inevitably become a true project threat.
Have regular check-ins
Regular status updates help keep both sides accountable for their responsibilities on the project. The frequency of status updates will of course depend on the scope of the project and the proximity of the deadline. Long-term projects might be well-suited to biweekly updates, while a website rushing to launch next Monday might have twice-daily standups.
Choose the update method that is best suited to your client and project needs. For some clients, a simple email summary of what work was done, what’s in the queue, and any feedback needed is perfect. For other clients, a meeting or video call to get a visual on the project progress and Gantt chart is a better fit. You may have a project management software that you feel comfortable giving the client access to, to view updates in real time.
Determine a cadence in advance for internal status updates (say between the web designer and web PM), internal stakeholders (account managers or directors) and external stakeholders (whether the client or a third-party who has a stake in the project).
Prioritize change requests
In project management we speak of the “iron triangle,” balancing scope, budget, and timeline.
Revisions are inevitable, and indeed a core part of the web design and development process. However in order to keep the project on budget, they have to fit in the original project scope. And in order to keep the project on time, even changes the client is willing to pay for may not be possible to deliver as part of the current project.
Often, change requests are outside of the initial project scope. They may take a lot of time but do not necessarily deliver value to the end user. You need to have the transparent conversation with the client about whether this is a “need” or a “nice to have.”
If it’s a “nice to have,” save it for a post-launch phase 2 (more on that later).
Embrace the “phase 2”
A website is a living organism, not locked in place. Once you launch, you can continue to make changes and add functionality. Though this is ideally better determined in the planning phases, work with your client to identify which non-core requests can be saved for post-launch.
For example, that new search filter might be valuable. Is it valuable enough to delay the launch of the website by two weeks? When put in those terms, it can be clear which functionalities are truly necessary for launch and which can be put on the back burner.
(Unless it’s making the logo bigger. We can always make the logo bigger.)
Conclusion
Building a new website is a demanding endeavour, often with multiple stakeholders who have their own needs, priorities, and perspectives. In keeping the end goal in mind and sticking to these eight principles, you will more consistently develop and deploy beautiful websites, on time and on budget.
