The Design Phase
Following on from my last article for on writing the brief, which explored the subject of writing a design brief for a website from the customer’s perspective, I was interested in taking on the same challenge for the design phase.
Working as a designer and developer for almost a decade, I’d be confident in saying I’m fluent in my approach of designing for the web, and the nuances of each stage within that. What I’m guilty of sometimes (as I’m sure lots of designers/developers are) is assuming that our customers know what to expect going into the design phase of a project, what’s required from them, and therefore what exactly they’ll be looking at along the way. In this latest article I’ll be going through some common stages of a web design project in order to better equip business and website owners as to what’s involved.
Before we start, I want to caveat this whole piece with the following. While I’ll be discussing the end-to-end process, all designers and agencies work in a different way, with different milestones, and varying touch-points with the clients. All different approaches have their merits, and because of the almost unlimited number of variants to a project specification and client, there isn’t a one size fits all. The approach I take at Alloneword is mainly around ecommerce, for small to medium businesses (and from time to time large brands), where I often work on the design and development where stages are a bit more fluid. I’ll therefor be using parts of my own approach in order to highlight the rough order I consider valuable when taking on a web project.
More than likely once you’ve commissioned a web design from an agency, freelancer or studio, they’ll want to chat to you about your initial brief to them, and prod and explore some elements within. These meetings can happen over the phone, but I’d always push for face-to-face if possible, as building a strong working relationship with the people working on such a valuable part of your business is a must. Too often I’ve seen client / supplier relationships go sour over rounds and rounds of email tennis, especially during the later stages of a project. You should all think of yourselves as one project team, all bringing a strength to the table. Go into that meeting with a mindset of what you’ll bring: knowledge of your client base, company objectives, and ways to measure the success of a project. Also be open minded and ready to learn. Get to know their process, what gets them fired up, and ways in which you can help the project run smoothly.
Goals and scenarios
As part of this meeting you should be discussing the goals of the project and some sample user types. Referring back to my earlier caveat, I’m not saying if this doesn’t happen then the project won’t be successful, but essentially design is art within parameters, and we should think of web design more like product design than graphic design. While we’re wanting to create something eye catching and memorable, the website needs to serve the people who visit it and achieve what we want it to as a business. Ahead of the kick-off meeting make some mental notes about what you want the new website to achieve that the current one does, what your long term business goals are, in addition to thinking about some typical customers and the different ways they might interact with your website and brand. Make an effort to bring these up in the meeting, but odds are they will come up naturally in conversation or feature as part of the agenda.
While not technically (see what I did there) part of the design phase, a technical specification is more a development document which stipulates all the requirements of the project from a technical point of view e.g. what platform the site will run on, what custom extensions or developments there will be, and any third party integrations that may need to be featured. This information is salient from a design point of view too, and you should check that any mock-ups that are produced match up with the technical specification as best you can. If there is a newsletter sign up requirement, or if you’re using a plugin or app to show your reviews from previous customers can you see this in the page designs?
Before any layout or design rationale is to be employed, we should always take into account that content should sit at the heart of the website. What we should be doing first is working out exactly all the content we want on the website and in what structure. From this we’re then in a good place to start to create designs around this content, rather than creating layouts for text or data that will never exist or be of any use. Again, ahead of your kick-off meeting try and come armed with some sort of insight as to what content and what types of content you want on the site. Will you have news pages as well as more static such as ‘About Us’? Do you have services and if so will it be of benefit having different pages for each? Do you have any case studies which really sell what you do? This isn’t saying it needs to be locked down at this stage, as projects evolve and grow as we research and learn, but giving the designers a good overall idea will have the benefit of seeing initial designs that will better wrap around your business and brand, rather than the other way around.
“Content precedes design. Design in the absence of content is not design, it’s decoration.” – Jeffrey Zeldman
Before you get stuck into the mock-ups or visual treatment, where you see JPG visuals of a website (or even coded up and sent as a link), it’s far more efficient to do a set of wireframes, which are basically line drawings of the new website, which can show full pages or just different components, and at varying screen sizes. You might not be doing this, as they do still add an extra layer of time which wasn’t available within your budget, but the main appeal of wireframes is that if something isn’t right or you’re not happy with, turning around an amended version is a lot quicker than carefully editing a set of visual mock-ups in Photoshop. Ask if wireframing features as part of your project process or even if there’s a chance of simply doing some ideas as part of the kick-off meeting. I’ve had experiences where a large piece of paper, felt pen, and 20 minutes time allocated has led to an idea which has then led to a unique way of designing the whole website.
At some point you’re going to start to want to see visuals of how the site will look, and this could be anything from a moodboard or style tile, to a Photoshop mockup or coded HTML versions of key pages. In previous roles I’ve managed teams of designers, and what I realised early on is that a designer working within their own process is a happy one, and therefore more open to creativity and drive to get the job done well. While I would normally push them to following the above sections, when it came to applying a visual treatment I often let them do it in whatever way or medium they found most beneficial. Some designers can write code, and HTML mockups have many benefits. To counter, a Photoshop file removes the element of code so it’s quicker to experiment. Ultimately you may encounter a certain way of presenting the visual treatment of your new site and, as long as you’ve kept confidence in your designer up to this point, go with it. That isn’t to say don’t question, challenge, discuss and feedback on areas, but be mindful of the fact that most good designers will invest themselves into each design they produce, so be sure to mention the good and bad. What can be written as a list of changes can be read as a rant of all the ways their hard work is wrong. Lastly, remember that websites have interactions, so look at areas of the design and if it gives you the whole picture. Does it show what a menu looks like when open or how a pop out window shows?
While in my own process I have various touch points with the client, from informal calls along the way or popping in if we’re feeling we need to spend more time on a stage, I more often than not book in a creative review meeting to happen near the time where sign-off is due at the end of the design stage. What I’m really looking at getting out of this meeting is that everyone is still fired up, focussed on their tasks within the project, and that the work so far has stayed true to the original objectives and sample user personas. From start to finish a design phase can be anything from a few weeks to six months, and it’s easy to meander. Capturing anything that’s awry at this point is a lot cheaper than when developers have started to code and integrate, and something that can seem like a simple change may mean a complete rebuild of that component. Set aside some time for a wrap up meeting like this, as it will give you and everyone else the confidence that all team members are focussed on the task at hand ahead of development.