A Focus On The Web Design Process

If you are anything like me you often find yourself pondering the best way to get something done. That something could be how to grow the nicest lawn, ride the perfect line down a rocky trail, pour the perfect pint or write the most semantically sound HTML and CSS. Ok, so maybe they are just me, but certainly one of the things that commands my attention more often than not is the web design process.

Recently (let's say the past 12 months) my view on web design has changed in several ways. Firstly, I've strongly moved away from thinking that you must know certain tools to be good a making websites. The very idea that knowing how to use Photoshop™ exceptionally well or that you know every PHP function under the sun makes you a good designer/developer is something I've come to firmly disagree with. Secondly, and perhaps most importantly, I've come to realise that your process and being able to accurately explain or document it is hugely important. Understanding the process inherently gives you a foot up in understanding what you are doing when solving problems - which is, after all, what we are here to do!

Solving your own problems

As designers and developers we are problem solvers. We take our brief from clients and put our grey matter to work to find the most elegant and effective solution. When it comes to solving our own problems though, we are often not so great.

Finding your perfect process is a great exercise in problem solving and it is certainly something that we should all dedicate time to on a regular basis. It has all the hallmarks of a juicy brief; internal goals, external goals, internal constraints, external constraints, technology limits, etc. so it is amazing that so many people still don't have a properly thought out process (or a process full-stop!)

Identifying the goals of a web design process

Quite simply the main goal of the web design process is to produce a visually rich, engaging, usable website that allows both user and business to achieve their goals as identified in the project's research phase. (Did I just say simply?!)

Building on this statement, the over-arching goal for a web design process is:

Have a documented and repeatable set of actions that allows clients and web designers to work together to produce a web site that fulfills business and user goals.

To be more fine-grained our process needs to:

• Identify the business and user goals
• Research competitors and identify their strengths and weaknesses
• Create a content strategy that is effective for both users and SEO
• Produce a site architecture that contains the content in a structured, logical and usable way (also known as Information Architecture)
• Include wireframe layouts for the most important use cases (more and more this includes understanding how the content will be displayed on tablets and mobile devices)
• Create semantically correct, HTML and CSS
• Apply a graphical sheen / creative layer to make the site visually stunning
• Build a performant and maintainable back-end system (using the most appropriate language and technology stack for the project)
• Test both the technical and usable nature of the web site
• Review and appraise the effectiveness of the project
• Provide a mechanism for identifying and implementing future improvements to the website

These elements do not necessarily need to happen in this particular order, however, this is my preferred method of working as it places the greatest emphasis on identifying and designing for users' goals.

A side-step into the realm of pitching

It is my belief that pitching is one of the biggest reasons that web design projects fail. More often than not, the team producing work for the pitch is trying to solve a problem in isolation and it sets up the project in completely the wrong way.

I'm sure we've all experienced this scenario, the tender document comes in and the list of deliverables specifies at least one homepage design, potentially with an inner page thrown in for good measure.

This is totally wrong.

By entering into this tendering scenario you remove the most critical steps from your process (the research, content strategy, IA and prototyping) and instead jump straight into window dressing content that you have no background knowledge of. You may be able to scrape some time together to do a bit of research but ultimately this beauty contest is focused on the client and not their end users.

In this situation I would strongly urge that you kick back and explain that you will provide case studies and pitch the client your process, as it is only by following the steps outlined above that you can come to an effective solution.

This is, of course, an idealistic stance to take (and not always possible) but truth be told if a business is more focused on getting something for them than their users then the project is going to be very hard work. If they don't understand or don't want to pay for the "thinking part" of the project then I'd suggest that the whole thing is not going to end well for either party. Remember, you are there to produce solutions to problems, not simply create a pretty picture in Photoshop.

Managing Your Process

We are all human, we are all liable to forget things or make a mistake (what do you mean it's just me?!) so it is necessary to have a system in place to help us manage our ideas, tasks and feedback. This system could be anything, post-it notes, a diary, a Filofax, a calendar on your computer, a Kanban board or some web-based software - there are a million different options, all of which have their pros and cons (and all of which have a strong body of advocates).

Through the years I've favoured a computer based solution using web-based and desktop software solutions. Most recently I've used Basecamp (works for some, not for me), Omnifocus, Notable, Chiliproject (a fork of Redmine) and latterly Trello from Fog Creek.

Using all these various systems has lead me to the following understandings, which I hope will be of use to others in their quest to get a solid workflow.

• Any tool is only useful when it is kept up-to-date
• More features doesn't necessarily equate to more productive
• Version control integration is important
• Email notifications and responding via email is not
• Work as if you are in a big team, even if it is just you
• Time tracking is useful for business goals but rarely used to inform planning/proposals*
• A tool may be clever, feature the best tech and have the nicest interface but if your client doesn't want to use it, it's going to be hard work keeping it current if it requires more than five minutes to update.

Be pragmatic

It might appear that the management of web projects is a lot of effort, strewn with problems and pitfalls but in reality it isn't, as long as you keep things simple.

Here are some tips based on what I've learned from developing my own web design process. (Note that I am pretty much using Trello in isolation now so these tips are biased towards that style of tool).

Start with a high level overview and add detail only when necessary

Don't immediately start hammering out the most fine-grained tasks, instead make sure you have a good overview of everything that is going on with your work first. Ideally, you can get an instant overview of all your projects in one place, and then view individual projects in more detail elsewhere if you need to.

Plan for collaboration

You shouldn't expect your clients to use your project management system (though if they do that's a bonus) but you should expect any team members to be fully up to speed with any software that you use.

Let the client communicate in their preferred way

If they email you with assets and thoughts, that's fine. If they feedback via powerpoint presentations, that's fine. If you are sent print-outs with scribbles on followed by a phone call, that's fine. Fit to their preferred way of communicating.

This isn't to say that you shouldn't try and improve communication flow if you can, but typically people have a fairly set way of working so you should make sure that you can accomodate it. The key thing is that you document their feedback and assign appropriate actions / store assets etc. so the project is in the state you want it in.

Buy a good scanner

Scribbles on paper are still hugely effective for thinking a problem through, and notes from client meetings or impromptu chats with people in the team are extremely valuable to a project so don't chance losing them! Buy a good scanner and get paper notes into electronic form for tagging and archiving (and by good I mean high resolution and fast!).

Create your own branded templates

You may think that your scribbles are too scruffy to present to a client but more often than not they are perfectly fine if done on nicely branded paper. It's one of the reasons I created my own wireframing template. A quick (and often dirty) sketch with highlights courtesy of some lovely Copic markers has often saved hours in Omnigraffle.

Produce electronic document templates

Having identified the different phases in your design process you'll know what deliverables are expected to be sent to a client. Make life easy by creating template versions that can be grabbed from a central resource hub. This reduces time spent setting everything up and gives all your client facing documents a consistant look and feel. N.B. Consistent design and branding is important, but not as important as the content held in the documents, often simple and neat is better than spending too long dressing up client documents.

Keep everyone up-to-date with the project

Depending on the nature of a project you may find that certain parts of the process can last for several weeks so it's important that stakeholders and team members are given updates regularly. It helps keep everyone involved, motivated and most importantly helps show your client how their money is being spent.

If a communication contains assets or documents, check them as soon as they arrive.

That next phase of the project may only take a few hours, but if the deadline is looming and you find the assets aren't usable you're going to look a bit silly. Check everything you are sent as soon as you can and make sure they are safely stored ready for use later.

Keep all project files together in version control

Someone should be able to download the project and have everything available to them without needing to go hunting elsewhere. This includes any basic database fixtures, .ini files, login details etc. etc.

Version control provides the best place to store this as it means that you can record who has made changes and roll-back if something goes horribly wrong. All team members should be comfortable with creating, updating and deleting files and repositories; even if it's just a very basic usage, it's better than nothing.

I highly recommend git, though I would suggest that if you are creating large binary files (such as Photoshop™ documents) you investigate the best way to push and pull these without compression as they require lots of RAM!

Keep passwords secure to external parties, but available internally

This applies even if you are a one man band, in fact, it's even more important.

Back up absolutely everything

You've got a deadline and your computer breaks. It's not a problem though because you can just download the Photoshop™ trial and the repository again can't you? If you can't, then your work isn't properly backed up and you need to do something about that right now.

Spend time reviewing a project after it has completed

You've completed the work and (hopefully) the client loves it, congratulations! Now schedule a meeting and review exactly what went well, what could have been better and what can be extracted from the project and put into your resource hub for use in other projects.

This is a crucial step in the project lifecycle as it affords you the chance to refine your process and make sure that all future projects are even better than before.

The missing bit(s)

One aspect that I have left out is prototyping and that's mainly because, sadly, there is normally neither the time or budget to effectively prototype an idea.

I personally spend time playing with tools and ideas outside of work (sometimes inside work but don't tell my boss) and it's these 'spikes' that help me find new techniques or decipher exactly how the Facebook API works this week.

Another thing that isn't mentioned is the concept of designing in the browser. While I haven't talked about specific deliverables or techniques needed to complete each phase of the process (e.g. mental models, personas, mobile first design techniques, progressive enhancement, etc.) in-browser design is very much a part of the process but ultimately something that I've not quite figured out yet.

Ultimately, I would like to see web projects designed outside of static mockup tools (such as Photoshop™) so they are built up and thought out in their native environment. Of course, graphics editors will still play an important part in creating the images needed to make a design look fantastic, however, they will not be the start, middle and end of the 'design' phase as they so often are now.

What web design process works for you?

This is just my take on what is needed to make a successful process for designing and developing websites and it won't suit everyone. What's important is that time has been spent planning and testing a process and tools that make getting from nothing to something efficient and effective.

If you have any tips or techniques (or software recommendations) that are worth checking out then please let me know!

*We like to think that we will review what we've done to make our quoting more accurate, and to some extent this does happen. However, this neglects to acknowledge that each time we complete the process we gain a new insight or do something a slightly different way and on the back of that we quote based on a new idea of how to complete a project. If it were simply the case of repeating the exact same actions over and over again we wouldn't need to quote, a website would simply have a description and a price tag. Technology, our knowledge and users needs are constantly changing and so our estimates look set to remain just that, rough guides.