Why you should design the website first
Let’s talk about why starting building the website before you’ve even designed it is the total wrong way around of doing things.
Okay, so what do I mean? Well, we often have people approaching us saying, “We really don’t like our website”. To explore further we ask them what are the pain points, and what has the process been to get where they are at. All too often they’ll explain that the web designer essentially took a brief from them, disappeared for a month, then returned showing them a ready built WordPress website.
Then come the issues:
- Not as briefed
- Not on brand
- Not well designed
- Buggy
- Looks generic
- Hard or impossible for the client to edit
- Other reasons to weep
Disclaimer: This is not everyones experience of course, and some developer/designers really excel at a code first approach. If you find them, pay them lots of money and love on them as much as you can! ?
Core Limitations Of A Build First Approach
Why is it a bad idea to start building the website before there’s even a design?
- You are limited by the technology. The person building your website is limited by what the CMS, theme, and plugins can achieve. Their decision process will be restricted by what they can quickly achieve on that infrastructure.
- You’re also limited by the skill of the web designer. In many of the cases we have experienced, the “web designer” is either a talented developer or a “theme implementor”, meaning they do not necessarily have the “design eye”. If they are the latter, they likely do not have the technical ability to create the functionality your business needs, therefore relying on off-the-shelf plugins.
- Then finally, if you want to change anything it’s really difficult. To change something in a graphic design application is a case of spending a few minutes making minor adjustments. If you give that instruction to a designer that’s a very simple process and they can amend and send you the latest version for you to review. If you want someone to do that in code, they’re going to have to write some CSS to do that. It takes much longer to make amends in code than in Sketch/Photoshop/AI/InDesign.
The Elephant In The Room
Obviously there are some great page builders out there like Beaver Builder, which you can still do a few tweaks on which makes things a little quicker than code. Surely that negates the need to do anything in a design application?
Nope! Regardless of the page builder used, everyone in your team will be reviewing the site on different browsers, screen resolutions and accessibility settings. If you’re sending out a design, a picture of what it’s going to look like from a designer, you’re all seeing the same layout and you’re all signing off the exactly same thing.
This then gives the developer the blueprint to create the final signed off design either in code, or with a page builder, and then do all the relevant cross browser testing.
So What Is A Good Approach?
The basic design to build process should be:
- Discovery
- Wireframe
- Design
- Code
Discovery: you talk about what you want to achieve, create the specifications, explore brand assets, establish goals, explore who the end users are, plan the structure, the site map, establish what technology will be utilised to achieve the specifications, et cetera.
Wireframing: done with the design team, you are laying out in simple block and illustration form how the site will be laid out, with user experience and journeys considered. Some folks use PowerPoint to replicate clicks to go to other areas of the wireframe, or tools such as Mockingbird.
Design: Then you want to take that into the design process with your designer/design agency.
Once you’ve done all this, you’re all signing off exactly the same look and feel. You all know what you’re expecting, you all know how it’s going to work and how it is going to look, and what technology you use.
The benefits of having a discovery and design-first approach are:
- you to see what you’re going to get
- select the correct technology
- find the relevant developers to match the requirements
- avoid nasty surprises
Don’t start with an assumed technology first.
Don’t start without a designer at the beginning.
Do go through the process of discovery, wireframe, design and then build.