The Process

tl:dr Version

You tell me about your business and what you want to achieve with your web site. I tell you how I think we should do it, how long it will take and how much it will cost. We tweak things until we agree. We sign a contract to that effect. You make a first payment. I do the work in stages getting your approval along the way together with further staged payments. We launch the site. Everyone cheers. We tweak a few things as you get used to the site post launch. I do long term support and maintenance. Tea and chocolate biscuits are liberally interspersed throughout the process. Read on for more detail.

“Designers are usually hired for their design skills, but they are nearly always fired for their lack of project management skills.” – Fiona Robertson Remley

First Contact

I like to keep the initial discussions very loose and informal. The aim here is not to come up with any detailed designs. I’m looking to find out whether we’re a good fit for each other. Can I offer you the skills you need? What are you aiming to achieve with the project? What’s your business about? What’s your budget? What’s your time frame? What’s the rough scope of the project? What’s your knowledge of web design and development like? How do you like to run a project?

The Brief

I’ll follow this initial discussion up by sending you a tailored project brief for you to fill out. There’s a sample here for you to look at. Leaving you to your own devices on this allows you to mull things over without feeling pressured into giving immediate reactions to questions which really require some consideration. After our initial chat this brief should be asking you the right questions and after you’ve completed it I should be in a position to put together a detailed project plan and quotation; otherwise known as:

The Proposal

This is a pretty detailed breakdown of the project. What static pages we’ll produce, how the site navigation will work, the initial design ideas, what domain name we’ll buy, what long term support and training you’ll need, the time-scales involved including deadlines, the overall cost broken down into instalments with due dates. Here’s a sample proposal. Once we’ve done tweaking things we’ll both sign it as a commitment to proceed.

The Contract

If the proposal is the plan specific to your project then the contract is all the generic admin stuff that backs it up. It’s where we define our rights and responsibilities to each other. I’ve cut mine down to a bare minimum and I’ve tried to make it as user friendly as possible. Broadly speaking it’s not project specific but it’s intimately tied into the proposal. The two together give us the confidence to proceed in what is usually only a fledgling relationship by this stage. Take a look at a sample contract here.

sprezzatura /sprettsa’tu:ra/ Ease of manner, studied carelessness, nonchalance – Shorter Oxford English Dictionary

Initial Payment

This is the point where you get to cough up some cash. For most projects, the up-front payment is 30% but on very large projects there may be more payment stages to spread the load a little more evenly. Once I’ve received the payment I’ll start on the real work.

Wire-frames and Designs

The absolute best way to de-risk a web development project is for you to see what I’ve been up to. The more frequently you see progress, the less chance there is of me falling down a rabbit hole and wasting my time and your cash producing something you don’t want. Initially that means two things. Wire-frames and designs. Producing these in isolation is much quicker and cheaper than trying to integrate them into a functioning web site which is evolving rapidly at the same time.

Interim Payment

All the way through the wire-framing and design stage you’ll be able to see the progress and provide feedback. Once these are complete you should be confident enough to make the interim payment. Again, this is usually 30% of the total project cost but larger projects may vary.

Coding and Testing

At this stage we should both be comfortable proceeding to code and test. This is where I take everything we’ve produced so far and integrate it into a beautiful feast of shiny. The wire-frames will become a solidly coded foundation. Copy, images and user interface elements will be layered on top. And the whole thing will be styled using the ready and waiting design elements. All the interaction elements get tested, the copy is proofread, the site is checked across a suite of browsers and devices and everything gets a final buff and polish.

Approval and Final Payment

Once you’re happy with the final product you make the final payment to cover the remaining balance of the project cost and I hand over all the assets we agreed as part of the contract. You’ll get passwords and anything else you may need to keep the project going should I be abducted by aliens. Once everything’s approved, paid for and handed over, that’s my cue to go live.

“When I have a ‘concept’ and people smile, I take the next step. When there are questions, I go back and try harder.” – Hartmut Esslinger


Quite often a web site launch will be accompanied by press releases and the like. It’s important to realise that a web site launch is a process in itself though. It’s not simply a case of flicking a switch (although it can be made to seem that way to your users). It takes a little time to upload all your site content and set up the databases etc. And of course you’ll want the live site testing before launch just to make sure no gremlins crept in during these last crucial stages.

Ongoing Support and Maintenance

Once the site is up and running, I’ll set up and test backup routines, start any site analytics packages we’ve put in place and then monitor the site for a week or so. If you’re signed up for ongoing maintenance then over time I’ll be running backups and updating plug-ins etc. After a month or so, you should be pretty comfortable with your new site but just like a move into a new house, you’ll probably start finding a few things that you want to change around.

Follow Up

I’ll always be in touch a few times during the post launch period. Both to make sure that you’re happy with everything and to see if there’s anything else I can do for you.

The Tools

Not everything is a nail, so I’m familiar with more tools than just hammers. Often a hand-cut HTML site, backed by PHP and a custom MySQL database, is the best solution but modern CMS systems like Drupal and WordPress combined with frameworks like jQuery and Twitter’s Bootstrap can really produce amazing results in remarkable timeframes with consequentially impressive cost benefits.

I’ve developed a fantastic tool-set over the years which allows me to do a huge amount with very little.

  • Sublime Text. Wonderful code editor. Spend most of my day here.
  • A great hosting provider. Private servers allows me ssh and root access to do pretty much anything I need to.
  • XAMPP. An Apache, MyQSL and PHP stack running on my dev machines allowing me to run local copies of web sites.
  • Dropbox. Fantastic for syncing everything across all my machines.
  • CrashPlan. Cloud based backup so I can be sure your site isn’t going to disappear on me.
  • Git. Version control is pretty much vital. I need to know I can revert any changes so I can experiment freely.
  • Illustrator and Photoshop. The usual suspects for web design.
  • Apache, MySQL, PHP, HTML5, CSS3, JavaScript. The usual suspects for web development.
  • Sass (Compass) and LESS (SimpLESS) for intelligently writing my CSS style sheets.
  • Windows Power Shell, Take Command and Cygwin for command line wizardry. Scripts mean I can automate a lot of work.
  • WordPress. Whenever clients need content management, WP is my first port of call.
  • Various 3rd party plug-ins and libraries. I don’t have the time and you don’t have the money to reinvent the wheel.
  • A simple text based calendar and to do list with time tracking and estimation. Captures everything with no friction and maximum flexibility.
  • A MarkDown based ‘memex’ type system for capturing reference and design inspiration material.

Why NOT To Choose Me?

You’re here trying to find a needle in a haystack and the only way to make an informed choice is to weigh the pros AND the cons. Here are a few reasons why I may not be the right man for your job:

  • I’m not up for endless procurement meetings. If your process involves a 200 page RFP then move on – there’s nothing to see here.
  • I don’t do big, complex sites for big corporates. I’m simply not familiar with the tool-sets required. Modern web work is broad and complex and a single person must focus their skills to avoid being incompetent at everything.
  • If you want stunning original digital artwork then I’m not your man. I’m a competent designer but there are astonishingly expert artists out there.

Having said all that, if your requirements DON’T fit my skill set then drop me a line anyway. I can probably offer some advice and/or put you in touch with some of the right people to get things moving correctly for you.

Why Choose Me?


There are a million web guys out there so what makes me special?

  • I’m quiet. You’ll find a calmness in my design work as well as in my project management. You won’t hear claims of my own awesomeness or the lameness of my competition.
  • I do right. I do what you want rather than what my designer ego wants to do. But I will tell you if what you want to do is wrong.
  • I give you business tools. I do stuff that is focused on generating return on investment.
  • I’m efficient. I have a ruthlessly honed development process that gets results for you safely and quickly.
  • I know my toolbox. I use only a small selection of tools that I can apply to a wide variety of jobs. I know my toolbox intimately and shiny new tools very rarely get granted access.
  • I’m experienced. I’ve got 25 years in the business on big projects and small. Everything from managing a team of fifty engineers on a multi-million pound fast-jet defence contract, through writing code for the International Space Station, right down to writing little day to day web apps to keep track of my billable hours.


So what hard skills do I bring to the table?

  • Creative. This isn’t about drawing cute dancing bears. This is about translating business goals into engaging content. Which is, admittedly, sometimes a cute dancing bear. Everyone loves a cute dancing bear.
  • Coding. This is predominantly about pushing constraints to enable the content to shine. Layout, user focus and attention, browser capabilities, limited bandwidth, convention and expectation.
  • Analytics. Raw web site data is freely available. Converting it into useful information is three parts great tooling, two parts hard graft, and one part mystical incantation. It’s the digital equivalent of panning for gold.
  • Content. A picture paints a thousand words. But try explaining those last six words with a paint brush. A well turned sentence can be every bit as powerful as a whole gig of JPGs.
  • Mobile. It goes without saying.
  • User Experience. UX is creative’s wingman. He’ll work hard to facilitate all his crazy schemes but when the wild and drunken session gets just that bit too crazy he’ll take his keys off him and call him a taxi. UX is the guy who makes sure you don’t have to scroll hoizontally.
  • Social. There’s a good chance you’ll need to hook into social as a significant part of your online presence. Whether it’s email campaigns or Vines or just a good ol’ FB page.

What Do I Do

Broadly speaking my work falls into four camps:

  • Web Site Production Working closely with clients to bring their web site ideas to reality is at the heart of my day to day work. Whether it’s a sharp and elegant single page site, or an e-commerce behemoth with social media features coming out of its ears, I can produce exactly what you’re looking for. To spec, on time, in budget.
  • Site Maintenance This service is designed for those who already have a web site up and running but want to make some improvements. Perhaps the site is looking a little old and tired. Perhaps you’re still relying on what your favourite nephew knocked up for you during startup. Perhaps you simply need to update your contact details.
  • Internet Presence Many clients love the idea of handing off their entire internet management responsibilities, freeing them up to just get on with business. This includes everything from renewal of domains, through setting up new email accounts, and right on up to updating Twitter, Facebook and blog content or implementing a pro-active online customer service by hunting down and solving problems identified in bad online reviews.
  • Analytics The purpose of a web site is to generate revenue, even if only indirectly, for your business. As with all revenue sources you need to have at least a basic understanding of how well it’s working for you. My analytics service helps with that task. I can tell you how many visitors you get, how long they stay, where they’re from, what pages they look at, or even how many of them give up during your over-complex checkout process.

Some of the specific tasks I’ll undertake would include:

  • Business and brand analysis.
  • Securing the right domain for you.
  • Setting up web and email hosting.
  • Branding, style-guide and web site design.
  • Web site development, coding and testing.
  • Content creation, including a blog if appropriate.
  • Social media campaigns.
  • Ongoing security updates, backups and traffic analysis.
  • Future development based on business needs.

None of this is fixed in stone of course. Maybe your site’s been hacked and your old web guy has vanished. Maybe you’ve just moved premises and need changes to your web site’s contact details and Google map. Perhaps you’ve already had some great print work done and you want to use this in your web site rather than starting from scratch. Not a problem.

Understanding Web Sites

I haven’t a clue about setting up a web site. How does it all work?

I’ll do the patronising bit first. Always nice to get that out of the way. Don’t worry about not understanding how all this stuff works; odds are I don’t have much of a clue how your business works. Part of a web designer’s job is to teach the client just enough so they can make high quality business decisions about what they need from their web site. So, here are the basics.

First thing you’ll need is a domain name (e.g. or This allows people to find your web site by entering into their web browser. It also allows them to send email to you using an email address like I’ll work with you to find a domain name that’s available and appropriate to your business. Once we’ve found the right one I’ll purchase it on your behalf. I’ll usually be the administrative contact for any queries about it but I’ll always set you up as the owner as you need to have legal ownership of it to make sure I can’t ever ruin your internet business. The up-front purchase price of the domain is included in the web site packages I provide. There are also ongoing fees associated with owning a domain which I roll into my standard site admin package to keep the administration simple for you.

Next up is finding some web hosting. Essentially this amounts to some space on a computer somewhere on the internet. That’s where your web site will live. These machines live in large, physically secure data centres with sophisticated backup processes, fast and reliable internet connections so your customers can access your web site quickly, and all sorts of power supply backups and the like. I currently use a UK company called Zen who have excellent customer service and good hosting packages. Again, there are ongoing fees for this hosting service which are rolled into my site admin package.

You’ll also probably want some email hosting; essentially a set of mailboxes where your email lives until you decide to collect it using your email client software (e.g. Outlook or Thunderbird) onto your PC or mobile phone. This is usually hosted on the same machine as your web site with the same hosting company. The fees for this are also included in my site admin package.

That’s the basics of how web site hosting works and pretty much the limit of the technical stuff you’ll need to know unless you’re interested in running a blog or eCommerce site.

How to Choose a Web Designer

Know Your Designer’s Intentions

The most important thing a designer must know is that your customers aren’t interested in your web site. Your customers are simply using your web site to achieve a task. That task is almost never to enjoy the wonderous design spread before them. Their task is to order a product, to find their way to your office or to sign up for a newsletter. As far as you’re concerned those tasks translate into generating revenue, gaining prospects and building brand loyalty. Make sure your goals are clear and that your designer’s intention is to build support for them.

There’s a saying in the wine business,

Buy on apples, sell on cheese.

Apple shows up the weaknesses in a wine, whereas cheese boosts the flavours. The mind deceives itself quite easily. There’s a saying in the web design business too,

Designers are hired for art and fired for process.

Don’t deceive yourself by focusing too much on a designer’s flashy portfolio. In reality what matters is their fundamental flavour; will they deliver the goods for your business.

Ensure You Have Realistic Expectations

How much do you really know about what constitutes a modern online presence? Have you underestimated the variety of options for an online presence? There’s social media, e-mail campaigns, video production, apps and a host of other options in addition to the traditional web site. Have you underestimated the work involved in creating a web site (particularly if in the past you’ve just knocked up a quick and dirty template site)? Keeping up to speed with this isn’t your day-to-day job so don’t be surprised if you’re a little out of touch.

Crucially, you must not think of your web site as a cost centre. It’s an investment which needs to show a return. If you think of it as a cost your emphasis on its functionality will be all wrong. Every pound you spend on it should be gladly spent. If you’re begrudging the money then either your thinking about it wrong or you’re buying functionality that won’t return your investment.

Don’t Expect to Talk Colours

Initial discussions with your web designer should rarely, or perhaps at most tangentially, touch on fonts, colours, animation effects and the like. Once the business goals are squared away, he’ll probably move onto getting a feel for your business image with a view to producing a ‘feel’ for the web site. Traditional or contemporary? Mass market or luxury? These are questions you can answer.

Which font or colour is best used to represent your business values is, to a large extent, for your designer to decide. He’ll eventually show you some options and you can tweak things from there. Don’t make the mistake of dictating design details. If you think the design is wrong, that’s probably for one of the following reasons:

  • The designer hasn’t understood the values of your business or the goals you’re aiming for.
  • You’re bringing your personal, subjective tastes to the table, thinking you know better than your designer.

Come Prepared

There are a few things you’ll need to bring to your first meeting:

  • Existing branding materials: brochures, logos, marketing copy, slogans etc.
  • Your business goals. This includes your broad goals as well as the specific goals for the web site.
  • Some idea of your budget. This can be a one-shot deal for the entire project or a smaller sum to run a pilot.
  • A list of the things you don’t know. Do you know how domains and hosting work for example?

Always Obtain Multiple Quotes

Finding the right web developer is not like finding the right plumber. You’ll find a huge variety of service levels, and associated costs, depending on who you ask. Starting off at one end of the spectrum you may be able to get your nephew to knock something together for fifty bucks. On the other end you’ll find the top end agencies who won’t touch any number with less than five zeroes after it. Not so with a plumber. Even more reason then, to obtain more than one quote when you’re looking for a shiny new web site.

Initial Questions

A few questions that are likely to crop up during an initial chat:

  • Describe your business in 60 seconds.
  • What’s the aim of the project?
  • What’s motivating the project?
  • What are your users like?
  • How should users perceive your site?
  • Do you have existing branding that you want to use?
  • Have you seen other web sites or design that has inspired you?
  • What is your approximate budget for this project?
  • What is your schedule for this project?

A web Designer’s Manifesto


One thing at a time. Finishing one thing before moving on to the next is more efficient because

  • you avoid task switching overhead costs
  • you can allow your brain to forget things not relevant to the problem at hand
  • you make time to build a focused mental context to work in
  • you produce higher quality work

Take breaks but don’t multitask. Read my article on multitasking for more background and some practical tips on how to manage your projects and day to day tasks.

Don’t repeat yourself. Known as DRY, this idea came to prominence in the late nineties as part of the Agile Software movement.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This can be applied to denormalised databases just as well as duplicate address books. Even such everyday things as having only one place for your car keys or having everything on one central to-do list.

  • Record everything but ensure minimal maintenance.
  • Look for components and extract them for reuse in other contexts.
  • Recognise the overhead involved in DRY; sometimes copy and paste is OK.
  • Always fix a guilty, unjustified, rush copy-paste later.
  • Things which need to remain in sync won’t; especially if you have to sync manually.
  • The opposite of DRY is WET – “We Enjoy Typing”.

‘Miscellaneous’ is an Old English word meaning “I can’t be bothered to think about this.” Miscellaneous can be a good thing, an inbox is a good example, but usually it’s just a dumping ground for unfinished ideas or lazy categorisation. You must have misc but keep it as empty as possible.

Prefer deletion over organisation. There’s a tension between this and not repeating yourself. Recognise when a thing will have future value but don’t hoard for the sake of it. Keep things simple by deleting anything that has no value or whose value is exceeded by the cost of keeping it. In essence, this is an exhortation to fight against the second law of thermodynamics: “There is a tendency to move from order to disorder as time passes.”

My brain is a processor not a memory. Write it down boy! Store notes external to your head. Recognise the ease of looking things up. Have a written to do list. Keep your head clear for thinking rather than remembering.

Support ‘undo’ in everything. Ctrl-Z is your friend. Use a version control system, Git, SVN, whatever. Undoing things is made substantially easier by doing one thing at a time because it creates a linear progression without any interleaved actions.

I’m sorry this letter is so long. I didn’t have time to make it shorter. It takes a great deal of effort to strip things down to their bare essentials. Always be looking for things that can be removed. Usually the complexity of a thing remains constant but our naive, initially rapidly increasing, understanding leads us to generate more data about it. Only once the majority of the data has been collected can we begin to form a fuller understanding and this allows us to remove much of the data we generated on the way.


A web site has four audiences; the user, the client, the tool set and the maintainer. The first two are obvious, though the distinction between them is often not. The tool set has a completely different set of requirements. For example, should a WordPress post title be an <h1> tag or an <h2>? The tool set will only accept one or the other but from a user perspective, a categories page should probably be showing a different heading level than a single post page. The maintainer, of course, wants to know why you picked <h1> rather than <h2>.

The client isn’t always right. But sometimes you need to let him be wrong. You’ll often disagree with your client over matters of style. Sometimes you need to let the client’s views win out. Sometimes they’ll have business insight which overrides aesthetic concerns. Sometimes it’ll be a subjective call with no ‘right’ answer. Sometimes you’ll be right but the fight isn’t worth the damage to your relationship or reputation. Sometimes you’ll just be plain wrong. Yes, even you Mr Ego.

There are fewer psychopaths in the world than you think. There’s usually a perfectly reasonable explanation behind weird behaviour. Fear and miscommunication are the top contenders. Always take a step back. But never forget that there are some psychopaths in the world.


Rock, paper, scissors, business. Business wins. Always. A business need satisfied beats design shininess every time. The purpose of a shiny design is to satisfy the business need.

Hired for design, fired for process. Projects are almost always awarded based on a pretty portfolio and almost never on a pert PERT chart. Both are important but the usual emphasis is way, WAAAAY out of wack. The fact of the matter is that bad projects almost always go bad because of poor project management and hardly ever because of creative ineptitude.

Real trust is earned trust. If you, as a complete stranger, expect me to trust you wildly, you’re gonna have a bad time. I’ll be doing some work up front, for free, on spec. It’s part of the pre-sale process. That’s my trust investment. Your half of the bargain is that you pay me up-front for the design and development work.


Don’t gild the lily. A drop shadow should not be noticed. Engagement with a design works mainly at a subconscious level. It’s really the things not seen which the brain uses to build its map of what it thinks of your work. Good design should not distract.

Not everybody’s screen is as big as yours. With the rise and rise of mobile tech, this is becoming more and more obvious and barely needs thinking about any more. It is still tempting to stick with a nice big screen for too long during a project though. Go diddy early and make sure you look good on the small screen.

Content is under-rated. Designers have an attraction to the shiny whether it’s the latest and greatest user interface tricks or a gorgeous pixel perfect layout. But it’s information that really counts and that means content and content means words. For the most part at least.

Typography is under-rated. If content is king then he needs some finery. Typography is hard. Really, really, hard. But if you’re after showcasing your content then it has to be done well.


Right, cheap, fast: pick one. Seriously. A well honed process will allow you to choose one whilst also maximising the other two. But make no mistake, you cannot dial more than one of them up to ten. Unless you have flexible resource levels (i.e. you have a team who can be pulled off other work or you can call on outside help). In that case you can potentially pick ‘fast’ and one other. But nowhere near as often as you’d think. More people means more overhead and can really put the brakes on a project until they get up to speed.

Performance should only be optimised in response to measured metrics. A dev who knows what performance bottlenecks his code will encounter is a rare thing indeed. The vast majority of those who do, are simply making lucky guesses. The fact is, there are so many contextual variables that it’s nigh on impossible to do any kind of performance tweaking without actually running the numbers.

You can never test enough. There will always be some funky freaky corner case that you’ve missed. The more you test, the more you eliminate, but don’t ever kid yourself you’ve whacked all the moles. Try to design for resilience under failure though.

Design security in from the start. Security isn’t something you can layer on top of an existing project. It has to be baked into the heart of the thing. Plan what you need early and never lose sight of it. Even after you’ve shipped.

Code for today rather than a dreamed of tomorrow. Otherwise known as YAGNI (you ain’t gonna need it). Many, many, absolutely essential features turn out to be less essential than you first thought. Build a strong, flexible foundation and drop the features on top as and when they are required.

Comments are evil. The voice of your code must be clear and precise. I don’t get it. Never have. Why do so many experienced coders use so many comments? It’s not DRY. Every time you repeat yourself those repetitions will go out of sync. Comments on all your </div> tags to tie them to their opening tag? You’ve probably got div-itis. Simplify the markup or replace some with HTML5 semantic markup.


A backup plan without tested recovery is just a guess. There are so many things that can go wrong with a backup plan. Simply setting up an automated backup to run once a week is just not good enough. Does it actually run? How do you know if it has run? Has it generated the data (because running is no guarantee that it’s done anything)? Can you get access to the data under all circumstances (hint – no you can’t)? Can you restore from the data? How do you know the restore you just did worked?

A tidy file structure is a cognitive burden beaten into submission. There really should be a place for everything and everything should be in its place. Lots of other principles come into play here. Make sure you only keep one copy of a file. Make sure your files are named sensibly (image.png is not a good name for a file). Make sure your folder structure works for you rather than against you.

Never add a version number or name to a file. Version control is there for a reason. There’s really no excuse for not using a version control system. It’s a bit of a steep learning curve but it’s so pleasing to be confident that you can rewind history in a simple and consistent manner.

Buffering in getchar()

Buffering in getchar() doesnt always work the way you would expect.

#include <stdio.h>
#include <unistd.h>
#include <termios.h>

int main()
	char x = ' ';
	printf("Press any key to continue...\n");
	x = getch();
	printf("The key you entered is: %c \n", x);
	return 0;

int getch(void)
	int ch;
	struct termios oldt;
	struct termios newt;
	tcgetattr(STDIN_FILENO, &oldt);
	newt = oldt;
	newt.c_lflag &= ~(ICANON | ECHO); /* Turn off line buffering and echo */
	tcsetattr(STDIN_FILENO, TCSANOW, &newt);
	ch = getchar();
	tcsetattr(STDIN_FILENO, TCSANOW, &oldt);
	return ch;