I have designed quite a few websites in my time and some of them I have even built and coded. The biggest trouble with being a designer working on web projects is undoubtedly working with developers. Good ones are hard to come by, and often you are working to completely different schedules – in my experience, they work nights and mornings to have their weekends off, while I need a little more sleep than that. Couple that with a designers need for perfection and a developers need for function and you have the potential for some sleepless nights and heavy frustration.
In my experience, as with all things, it really comes down to good, open and honest communication. Similarly to briefing in a client, I’ve got some simple tips for briefing in a project to your dev team:
1. Always start with a face to face meeting.
As a small and local business owner myself, I believe it’s incredibly important to support those Aussies who are working on their dream, so I strictly work with Australian developers. I have worked with a number of them over the past few years and the most successful projects have worked out when there was a face to face meeting, earlier in the design phase – once you’ve gotten an overall concept signed off by the client. Sit down, have a coffee and talk about what you expect from them; what you will do, where you go from here. Then take the time to explain how you think it will function, then get their expert input. If you don’t know about CMS’s or development languages because you’re newer to the game, that’s fine – but lean on your developer to make these recommendations so you don’t over promise to the client.
2. Project manage.
At the end of the day, this is your client and it’s absolutely your ass if you can’t deliver. So work out a schedule (Gantt Chart for those in marketing), allow a buffer of time and start riding your developer a little. Anyone working on a far off freelance project is going to need a nudge, so drive the beast.
3. Content.
Ultimately in website development nothing can be done by your developer without content. Text, images, graphic assets, the whole
works. Get it together in web optimised .jpegs, sort it into page folders in your Dropbox, name everything using a simple system (my fave is client name >page name>item) and let them at it.
Most importantly in the content side is your copy deck or content schedule. I make mine in Microsoft Excel (and I will happily send you one to use as a template!), with headings for everything – page name or section of parallax site, heading, links, sub headings, images, spacing between, image dimensions, everything. This helps your developers immensely because it is then a case of plug this section to this bit and its just connecting the wires in between. It also helps you and your client work out what the structure of the website is and how this whole thing is going to come together. Part of managing this process well is pushing back on your client to write the sections of their website. Some clients can deal with the copy deck; others can’t. One client, I had to break my copy deck down into individual tasks, and email each of them to him numbered. Doesn’t matter how it gets done, you have to have that content, and YOU have to manage it.
4. Testing.
This is both the hardest and most vital part of the whole project. Check everything, including seemingly obvious links, one page at a time, open it all up in new tabs and check EVERYTHING. Check every space. Do it on your Desktop, Tablet and Mobile just to be sure.
Then feedback IN your copy document, in a column alongside the row where you wrote the initial copy or image specifications. Label your column round one, and create another column along side it called revision checks. By keeping it all together, you can check off that each change is made as you request it, and make sure your development time is being used appropriately. Most developers charge by the project, so lets not undervalue their work by pushing the limits of their time on a project; we hate that as designers, so lets not do it to our figurative cousins.
5. The Client.
After one or two rounds of changes, when I think the website is 75% of where I want it to be, that’s when I bring in the client. There will always be things in a site that don’t work the way they thought it would, and they need to have the opportunity to raise that concern before you get into pixel perfect detail. It is their site after all. Now is also the time to put to work the knowledge of code and CMS imparted by your developer. If they are worrying about tiny spelling or wording changes, but they have a WordPress back end, they are thinking too granular and you need to teach them that. If they want big changes that weren’t accounted for in the original quote, you need to tell them that too. Again, manage your client and if in doubt, ask your developer before promising anything.
6. Deployment.
The reality is no website is 100% perfect when you go live, and you’ve got to be ok with that – and so does your client. It’s also not a bad idea to allow a little time after deployment in your quote for initial changes. I’m not going to talk to you here about hosting and servers and URLS, because I’m not qualified. I use the guys at Host Geek in Melbourne to help me and my team out with that, so if you want more specific information on hosting, head to their website or blog and tell them I sent you!
7. Using the back end.
This is the most crucial step, and it falls back to the three of you; developer, designer and client. If you don’t know how to use the back end CMS of the website your just created, you had better learn. That’s why I build all of my websites on WordPress, because it’s easy to use and I’ve done it so many times now. But this is a whole new world for your client in most cases. I think all websites should have an easy to edit CMS, because websites were MADE to be updated, and no client wants to pay for someone else to do it for them. So account for a couple of extra hours to teach your client how to update their own website and make changes to the major areas; images, text and their blog.
Working on websites is very much the norm for most graphic designers right now, as websites form the basis of most businesses online and offline presence. As designers, we want to create beautiful websites, but we don’t have the skills. And we need to accept that we are experts in what we do, and rope in those who are experts in code and development to do their share of the heavy lifting. But ultimately, if you don’t have a strong level of communication with your web developer and a keen understanding of the process through which a website comes into existence, you are only causing heartache for yourself and your developer. So if you have never built a website before, I hope this post helped you to understand a structure for how to get it done, and if you have built them before I hope some of my tips will help you do it better in website 2.0 (nerd joke!).
Comments