Introduction to our Web Design Process
This purpose of this article is to explain our in house web design process for a basic, informational website. We have built hundreds of websites over the years, have learned a little bit along the way- and would like to share some of this information with you. Because we are developers, this article is written primarily from the developer’s perspective. However, anyone should be able to follow along and hopefully they might learn something interesting- if not a lot more!
Related Articles
Table of Contents
- Step 1: Gather Requirements
- Step 2: Proposal
- Step 3: Navigation Summary
- Step 4: Wireframe
- Step 5: Content Collection
- Step 6: Project Timeline
- Step 7: Mockup Design
- Step 8: Development
- Step 9: Prototype
- Step 10: Launch
The Funnel. We like to think of our process much like a funnel. At the top, information is swirling and much of it is undefined. As we progress down the funnel, i.e. our “the steps of our process,” information and output become more clear, concise and ultimately becomes a turnkey website.
Developers need to follow documentation when they build. Ever heard of the biblical Tower of Babel? This is what happens when the size, scope and expectations are not defined- or followed. We have a saying in the IT field: “for every one hour of proper planning, you will save six hours in Development time.” This is very true and is a major factor in the profitability (or not) of a development shop.
Now that we have the philosophical stuff out the way, let’s have some fun!
Related posts
- Website Project Cost Overrun
- Website Change Order
- White Label Reseller
PalmettoSoft White Label Reseller Program
- Your client does not know us.
- You get recognition for the work done.
- You are free to resell work at any markup.
Step 1: Gather Requirements
In many cases, especially for those with little business experience, this is the most important step of the process. Understanding the expectations, scope and resources needed can properly align both the customer and developer for future success. This is important because any type of business transaction should be done only in a “win-win” situation for all parties involved.
IMPORTANT NOTE: YOU MUST IDENTIFY THE SIZE AND SCOPE OF THE PROJECT- AND IF THE CUSTOMER HAS MONEY TO PAY FOR IT.
If you accept the terms, this is what happens: You excitedly begin working on the project the first few weeks. However, no revenue is coming into your business. Then, you begin to work on other projects that actually pay you money. Then, your new business partners begin to get irritated with you with their stalled project… wash, rinse and repeat.
This always ends in disaster and you want to avoid it like the plague. Here is what you tell them as soon as you hear this type offer: “Thank you for your offer, but this is your dream. I have my dream and it is my company doing work for customers just like you. In addition, we work for U.S. currency only- I am a developer/small business and don’t have the resources to be your bank.” They will quickly be gone and you will never hear from them again. But don’t worry, it’s best for both parties.
Technical Requirements. Think of everything technical related to the project. Domain name, website hosting, content management system, email, etc. should be identified as line item work orders and each priced accordingly. If the customer is not tech savvy, offer to do it for them with their company credit card.
Provide a Ballpark Estimate. By this time, you should have a ballpark estimate (+) or (-) 10% of the total fee in your head. Verbally tell them and see where they are on things. In the event the customer wants a lower price, you can offer to scale down the size of the project and any type of special functionality it may have. And keep in mind you should never go below your basic fee. Why is this important? You should factor in accounting, design, management, copywriting and other miscellaneous fees when considering your starting price.
Following a website design process is critical in ensuring satisfaction and profitability. It also makes work more efficient, helps in communication and almost guarantees a happy customer at the end!
Step 2: Proposal
When you need to formalize something, write it down. You can call it a contract, estimate, proposal, etc.; the main point is to have a document that both developer and customer both understand what is being delivered- along with expectations, timeline and price. A proposal also helps to control the scope of the project or “put a fence around what is being requested” so there are little-to-no misconceptions about the work being done.
The proposal should at minimum feature the following sections: Introduction, expectations, Navigation Summary and functionality, development process with integrated schedule and fee. An example of our proposal is found here. In addition, the proposal should be a predefined template that you populate with the customer’s requirements. Hint: Learn about the Website Project Cost Overrun!
When creating your Proposal, make sure to add an Expectations section which covers such basics a response times, working hours, assumptions, etc… This is very important!
Step 3: Navigation Summary
There are many names for this to include but not limited to: Site tree, site structure, Navigation tree, site navigation, site organizational chart, etc…Essentially, this is the time to organize the website’s main pages and associated sub pages and to also describe technically how they will display. For example, there are drop down menus, fly outs, hover overs, mega menus, top navigation, side navigation…you get the point. This is the time to explain “how” all this is going to happen.
A navigation summary is the roadmap for the website. An experienced developer should be able to take hundreds of web pages (if necessary) and organize them for the user to find anything with 1,2,3 or 4 click- max. Try and keep the main navigation links to less than ten. Why? Imagine walking into a library and every book is off the shelf and opened. You would literally be bombarded with information and see nothing- think information overload. By keeping the web page interface clean and simple, the visitor should easily be guided to the information they are looking for.
The navigation summary is the “driver” of the wireframe. Each page mentioned in the navigation summary should have a corresponding wireframe. And ensure the navigation summary is approved before going to the next step.
Think of the Navigation Summary as a visual version of your site tree. It gives a better understanding of the project and also helps to “put a fence around it.” This fence is important in keeping the scope contained along with your profitability. Change Orders begin here too!
Step 4: Wireframe
Wireframes are not-to-scale black and white blueprints to show every page on the website.
I cannot overstate how important wireframes are to the creation of a great website. Nobody builds a house without blueprints, yet many amateur developers skip this very important step and jump into the mockup design phase. They do this because they think blueprints are a waste of time. In reality they are a massive saver of time. Blueprints match both customer and developer expectations for what is being built. Furthermore, when the client is engaged in the blueprint creation process they see the developer’s professionalism and attention to detail for the project. So make wireframes as detailed as possible! Guess what? Later on in the project, the customer tends to already have a favorable view of their project since they have been involved since the beginning.
Special Note- We use Balsamiq as our wireframe building tool.
Remember- The wireframe drives all the required content! Not only is the content defined, the file name in which in needs to be sent is also shown. Having the proper file name makes it the developer’s job much easier when building the website. We like to mention all required content in a red font so it easily catches the eye. In our next step; Content Collection, we create a Content Inventory spreadsheet pulled directly from… see below!
Wireframes are blueprints of the web application that is about to be built. Think architectural plans. Blueprints are done first before any aircraft, spaceship, building, bridge, ship, etc…is ever constructed. Don’t make the novice mistake of designing first… or you will end up in the abyss.
Step 5: Content Collection
Typically, this usually represents somewhere close to the midpoint of a project. More importantly, this is typically where more than 60% of projects stall. Why? Content collection is much of a client-dependent task as copy, images, testimonials, videos, bios and other types of content need to be gathered. One of the ways to mitigate this problem is to explain this scenario to the customer up front (without scaring them away) and ensure they are “bought in” and understand the importance of getting this information.
Use your magnificent wireframe to create a Content Inventory spreadsheet.
Warning! Do not proceed until the next step until 100% of the content has been received and inventoried. Would you build a house if you were missing the second floor windows? No. Would you build the roof if you were missing the shingles? No. Imagine a half built house sitting in the elements for six months deteriorating as each day goes by. This is what happens if you try and build a website without all the content.
Step 6: Project Timeline
At this point in the project, most of the “heavy lifting” has already been done. It is also the first time where the developer truly has some level of control regarding the remaining time left on the project. And this is where you create the project timeline. I recommend creating this with your team first and then sending to the client. Since they have already been involved quite a bit in the project, now is a good time to let them know “things are about to speed up and the rest of your project should be a downhill effort.” This is good for the customer to hear- especially after they have spent many hours proofing copy and gathering images and testimonials.
The project timeline step is also when the project manager meets with the development team in a kickoff meeting. All prior documentation is reviewed. It begins with the proposal, navigation summary, wireframes and ends with content collection. Also any change orders that have occured will be also be discussed. It is extremely important for this event to take place and have the proper amount of time allocated to it. On larger projects, this may actually take place over a couple of days.
The project timeline is truly when you understand exactly how long a project will take to build. Why? Mainly, there are NO more major client dependent tasks and the developer “has the architectural plans, wood, and windows to build the house- all on site.”
Step 7: Mockup Design
Mockup Design Questionnaire. By this step you should be extremely familiar with the site layout and its message. Create a less than one page document asking design related questions such as, but not limited to: What are your company colors? Please describe 2-3 websites you admire and specifically detail what style related features you like. Do you have any recent marketing material for us to look at? Basically, the questionnaire needs to be short and to the point. Study the feedback the client gives and you should be on your way towards creating a nice design.
Mockup Concept. With an informational site, you only need to create a Home, Inner (a main service offering) and Contact page. It is extremely important to also use the content you have already collected because it will influence the “likeability” in the customer’s eyes. After all, you have done all this work so far- use your content to your advantage. On the flipside of this, using latin text (lorem ipsum) as filler content will typically get an opposite response.
Page Elements. During the mockup step is best time to introduce page elements into the design. Think of supporting graphics, call-to-action buttons, PDF icons, thumbnail styles- basically anything that is not copy and images. Establishing the look and feel now helps to “polish” the mockup design. For further clarity, page elements should only be placed in the content areas and not in the head and footer.
When sending mockups, don’t send 2-3 examples- only send one style. Think about it: When you have followed your web design process meticulously, by the time you get to the mockup, all inputs and considerations should flow into one design. Using multiple designs will only muck up the process and waste design hours.
Stick with your original design concepts and make changes as required until the customer says “this is exactly what I want.” Then, politely let them know (by email- a digital trail) “we are going to accept this Mockup Design approval.”
Step 8: Development
As we move through the web design process, this seemingly difficult step can be one of the easiest. After all, development is more of an assembly job than anything else. And typically the project can begin to rapidly accelerate towards the ultimate goal of the website launch. The fastest way to achieve this is to assign multiple developers to the project. These technicians can work in different areas of the project simultaneously.
Don’t provide a development link as you are building. Unfinished or in-progress jobs simply look bad and send a negative psychological message to the customer. Remember, they are not IT professionals and don’t understand much of what we do. Developers make the mistake of doing this mainly because they want the customer to see they are making progress on the project. Don’t do it. Wait until you are finished. Following your process with good communication skills will give the client confidence in your abilities.
After initial development- it is time to vigorously test. If you have the extra personnel on staff, have an independent tester look over the project who has not worked in the project. They should look over all documents to date to ensure nothing is missing, done incorrectly, functionality is working properly, etc… Why an independent developer? Since they have little-to-no knowledge of project, they will not have biases and predetermined notions when they are testing. Having an uncorrupted view of something makes finding errors/bugs much easier. In the event you have a small staff (or it is just you), try and go into this task with the same mentality. You want to try and find mistakes.
Development is considered the “fun phase” as your team now has all the documentation, content and client input to build the site. It can be done quickly- especially if multiple developers are simultaneously working on the project much like a construction team would on a house.
Develop your own in house website testing checklist. At minimum, it should feature a line item list of things to check. During testing, The developer simply notates each item they check and also the mistakes they fix.
Special note: Our Website Testing Checklist is divided in three parts- Development, Prototype and Launch. We use one document mainly for efficiency reasons.
Step 9: Prototype
Once the development step (with internal testing) has been completed, you should send the client a prototype link so they can begin testing and reviewing the website from their side. In the same email, it is extremely important to have a list of instructions for them to follow such as, but not limited to: “During this time the client needs vigorously test their website for any broken links, images not working, text errors, pages not working, etc.” Basically have them only look for bugs/errors and things that are broken or not working properly.
Important Tip: In a second, supporting paragraph you should clearly state: “During this time, the customer will NOT be adding new pages, images, changing copy, modifying programming, etc… this constitutes NEW WORK and will be quoted as a new project after the website goes live. Be very careful of this scenario as it happens all the time. For some reason(s), customers like to try and swap copy, images, add pages… just be aware of it! The best way to mitigate the problem is by educating the customer beforehand as to what is in scope- and what is out of scope.
Also, recommend to the customer that only one person proof their site, and not a group of people. Why? Different people see things different ways- and you don’t want too many chefs in the kitchen…you know how that turns out and it’s always bad. In the event the customer does not feel good about their personal ability to test, you can always show them your internal testing document and usually that will get the approval you need to move forward.
The prototype is a rough draft (beta) version of the website. And it should be vigorously tested by the client. However, this is NOT the time to be adding new pages, copy, etc… That is scope creep and requires a change order.
Special Note: As clients typically are not developers, we don’t send them website checklists in which to proof their sites.
Step 10: Launch
After the customer approves the prototype, you should begin the launch sequence. Some call it “go live,” etc., these terms are essentially the same thing. Because this step is technical in nature, below are some main things to do.
- Migrate website files from development server to live server
- Install SSL certificate
- Integrate customer email ID in the contact form(s)
- Thank You page redirection
- Upload robots.txt and sitemap.xml file/li>
- Recheck Prototype step
Special Domain Name & Hosting Note: The above process is based on the assumption the client has an existing website on their server- and this is a website redesign project. During this time, the domain name and website hosting details are handled in the Development step. We work in this order mainly for time saving purposes.
Have the customer vigorously test their website for any bugs or errors. Once this is completed, have them reply with an “I accept this project as completed” type email. This confirmation helps to officially end the project!
90 Day Warranty. Have some version of a warranty you send to the client after going live. You should also review it with them so they understand you are not liable for the next 10 years or 100,000 miles- or whatever comes first.
Maintenance Agreement. Another important policy to have is a customer maintenance agreement. Moving forward, this defines how the developer will work for the customer and under what terms. You will be amazed at how many customers think that once their site is built, the developer is responsible for the next several years of unlimited updates. Because of this unrealistic assumption (and similar ones) a clearly defined maintenance policy helps you stay profitable in the long run.
