Stage 6: Build
On big projects, development could start before you complete the design (but hopefully not before the wireframes have been finalized). If you’re the designer, talk continually to the developers, discussing the flow and updating them on changes. Developers often have great ideas for simplifying processes, most of which require minor design changes. And if you have a good relationship with the developer, they will bend over backwards to accommodate any changes of yours that complicate the design.
Have you communicated setbacks and changes in functionality? During development, bring up any issues and setbacks as soon as they arise. You might have to alter your proposal, budget and time frame as circumstances change. Alerting the developer to changes in functionality is doubly important, because these will often have corollary effects.
Have you sent progress reports? As you build, send progress reports to the client, letting them know that things are on schedule. Designs often change subtly during development to be more usable. While the client doesn’t have to sign off on every little detail, discuss major changes so that they’re not surprised when they see the live website.
Are you demoing functionality as it gets built? Making minor changes early is better than when you’re running up against a deadline. If you can, periodically ask the client to choose between two options that are minor, equally good and easy to implement, so that they feel involved.
Have you met all legal requirements? Your client may not know the rules?things like terms and conditions, privacy policies and whether your country has requirements for limited corporations. Address all of these now.
Have you taken care of the alt tags, favicon, validation, meta data, page titles, 404 page and so on? These details will make your website look polished, even if the client isn’t conscious of them. At the end of the day, they are paying you for your expertise and professionalism; handling all of these things will reflect on your attention to detail.
Build in at least one special feature? As long as they don’t affect the user flow, little details and hidden features will please the client (and hopefully visitors). They will also excite you and your nerdy friends.
- Keep the client involved
- Continually talk to the developer
- Meet the client’s legal responsibilities
- Include alt tags, favicon and other details
- Demo the project so that the client understands the user flow
- Add a bonus goodie
Building a website entails making it easy for everyone to use. In some countries, providing a certain level of accessibility on a website is now law. Many of the techniques used for accessibility are also very relevant to SEO, so the effort is worthwhile.
- Do all pages have valid (X)HTML and CSS? Even if the client isn’t interested in this, the code should still be valid and meaningful for those who will maintain and update the website in future.
- Have you separated the structure from the presentation? Are you using semantic mark-up everywhere <ol>, <ul> and <dl> for lists, for example?
- Can users “skip to content,” especially on websites with complex navigation?
- Do all images have alt tags, even purely decorative images, which should have a null attribute alt=""?
- Is tabular data accessible? Don’t forget the <caption> element, the summary attribute, the scope attribute in the header’s cells, and <th> for the table’s headers.
- Is the primary language of the document indicated with the lang attribute in the <html> tag?
- Do you rely solely on color, size or font choices for critical actions? Changing an element to red to indicate an error, for example, won’t work for the color blind. You will have to explicitly state what the error is. Use more than color to convey meaning.
- Do all form controls have labels, and are they associated with the right inputs? Also, is the tab order logical, or should you use tabindex to make it bulletproof?
- Are links descriptive enough? They should make sense even when read out of context.
- Are users in charge of how links open? Warn users when a link opens in a new window.
- Are all links visible and recognizable as links?
- Is navigating the website without a mouse possible? Have you defined the focus state for navigation? This tells keyboard users where they are.
- Is all text rendered as HTML, rather than embedded in images? If you are not using Web-safe fonts, check how the fonts appear on various systems?especially when ClearType is deactivated on Windows (especially XP).
- Do pages remain usable when users enlarge text up to twice its original size?
- Are browser tab titles unique and meaningful?
- Is all interactive content, such as audio and video, described?
Website Speed Checklist
Users don’t want to wait for content; they get frustrated when they do. Designing and building for speed can significantly improve the experience.
- Have you taken out any code that is not required?
- Have you minimized the number of HTTP requests? (Image sprites can be helpful with this.) Also, are style sheets imported with
<link>, rather than @import?
- Is the content spread across different servers? Use a content delivery network to cut down on response times for users who are not close to the Web server.
- Are all images optimized for the Web? Don’t abuse the user’s bandwidth: do not serve large images if they will be displayed at low resolutions.
- Have you reduced the number of DOM elements? Are you throwing in more divs merely to fix layout issues? Maybe there’s a more efficient and semantic way to mark up the content.
- Have you minimized DOM access in your scripts?
- Tell browsers how long your content can be cached for. Use an Expires header to indicate the date until which a particular component can be cached. This way, returning visitors will enjoy much faster loading times.
- Are images in the right format? Use JPG for photos and true-color images, GIF for text-heavy screenshots and flat-color images, and PNG for lossless images with transparency and images that need more color support than GIF offers. The formats all have different trade-offs in quality and file size.
- Are you using the fewest images possible? The more you can do with HTML and CSS, the better.
- Is there any way to parallelize page loading (for example, displaying the content first and advertising second, even if the ads appear on top).
- Have you reused your CSS files and linked to them in the document header?
- Do links have a trailing slash? This makes it easy for the server to figure out that it’s loading a directory page, making the page load faster.
- Have you cut down on domain name system (DNS) look-ups? Every unique host name on a page requires a DNS look-up, so be aware of how many different host names are in your images, scripts, objects and other components.
- Is the AJAX cacheable? Optimize AJAX responses by adding an Expires or Cache-Control header.
- Are you hosting your assets on a cookie-less domain? Serving static resources from a cookie-less domain reduces the total size of requests made for a page.
- Are scripts at the bottom of the page?
- Have you avoided using redirects wherever possible?
- Are you using image compression tools such as SmushIt and CSS sprite generators?
If your client will be storing sensitive data on their server, security is probably a serious concern. Be prepared, especially if the client wants to be informed about the security measures required to maintain their quality of service and the security of the data on the website.
- Have you taken measures to prevent cross-site scripting (XSS) attacks? Treat input from GET, POST, or SERVER superglobals with filter methods of PHP.
- Are you preventing SQL injection? Use mysql_real_escape_string() or PHP prepared statements.
- Are you addressing cross-site request forgery (CSRF, or XSRF)? To save or alter data, always use POST. Try to avoid GET requests for altering. Use a nonce code (number used once) when saving or altering data. Generate a truly (pseudo-)random nonce, and do not write the nonce somewhere where an attacker would see it.
- Have you considered security issues with remote command execution? Do not ever use a superglobal value directly for including files; use a white list instead.
- Have you added a frame-breaking script to prevent simple clickjacking attempts?
- Have you disabled remote URLs for file-handling functions like
fopen and file_get_contents? Also, have you limited access to certain file name patterns?
- Have you restricted what PHP can read and write?
- Have you put limits on PHP’s execution time, memory usage, POST and upload data?
A lot of the techniques that make a website accessible would also help with SEO. Many clients don’t realize the work that goes into getting a good ranking. Explain to them that SEO is a specialized task, and while you will teach them the basics, they will need to hire a professional to improve their ranking. Make sure they understand that this does not happen overnight. Manage their expectations.
- Is honest, useful content the focus of the website? Is the website actually relevant and helpful?
- Is the content structured meaningfully in the mark-up?
- Are the URLs clean, meaningful and devoid of any shady keyword-sniffing tricks?
- Are all of the sources referred to in the content credible? Is the content itself a reliable source of information?
- Is the primary content on the home page, with no splash page?
- Do all images have descriptive alt tags?
- Does the home page link to important content on sub-pages?
- Is there a site map? Is it accessible to the major search engines?
- Have you created a
robots.txtfile to specify which content you do not want to be indexed?
- Would an analysis of current search engine results pages (SERPs) yield more effective keywords.
- Is the company’s address and phone number on every single page?
- Have you made a plan to update the content regularly?
- Are there links to useful external websites? Could you get them to link back to you?
- Do you have a plan to track progress? Use an analytics application to track traffic sources, and take a monthly screenshot of major SERPs. Also, create and maintain a spreadsheet of your rankings.
- Have you adhered to the practical limits of Web pages. A page should be no more than 150 KB in file size (not counting images, CSS and other attachments), contain no more than 100 unique links, have no more than 70 characters per <title> tag, have no more than two parameters in the URL and be no more than four levels deep in the URL (example: www.site.com/people/places/things/example/…).
- 1 https://www.smashingmagazine.com/the-lost-files/the-ultimate-web-design-questionnaire-and-checklist-part-5-of-8/
- 2 https://www.smashingmagazine.com/the-lost-files
- 3 https://www.smashingmagazine.com/the-lost-files/the-ultimate-web-design-questionnaire-and-checklist-part-7-of-8/
- 4 https://www.smashingmagazine.com/the-lost-files/the-ultimate-web-design-questionnaire-and-checklist-part-5-of-8/
- 5 https://www.smashingmagazine.com/the-lost-files
- 6 https://www.smashingmagazine.com/the-lost-files/the-ultimate-web-design-questionnaire-and-checklist-part-7-of-8/
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf New York, on June 14–15, with smart design patterns and front-end techniques.