As the web moves in a more fluid direction with sites being accessed on a variety of screens and in a variety of situations, the job distinction between designer and developer becomes blurred. Earlier this month, I wrote an article about developing websites with a code-first mentality (rather than a Photoshop mockup), which sparked some great conversations in the comments and other channels. Some people believe that a designers’ job is just to mock up designs, and a developers’ job is to reproduce those designs in a browser as accurately as possible. It is my belief that the old-school trend of passing PSDs back and forth is outdated, and in this article I’m going to outline a workflow between a two-person team, one who is primarily a designer, and a second who is primarily a developer.
Before I get into describing the workflow, I’ll recap what I wrote in the previous article on this subject. Sites should look great whether you’re reading them on a mobile device, a tablet, a laptop, a desktop, or projected on a screen. The traditional workflow of a designer passing a Photoshop PSD to a developer to hack up doesn’t fit with the way people currently browse the internet, and it will make less and less sense as screen sizes and resolutions become more fragmented. This means that we need a new workflow, one that is more collaborative, and one that takes into account how people actually browse the web, rather than assuming everyone is on a 13”+ display and browsing full screen.
Now for the workflow. Since we’re good designers, we want to start with the purpose of the website, and make sure the design serves that purpose, so that the user interface is natural for visitors. What this usually means is sitting down, designer, developer, and whoever is in charge of the content (a client or project manager, for instance) and determining what the purpose of the website will be. If your client starts by saying “I want a parallax website with music in the background and a community forum” then it’s time to tell them to take a step back and ask why. As a quick example, lets pretend that we’re developing a website for a beer company. The purpose will be threefold:
Inform visitors of seasonal beers.
Direct visitors to where they can purchase the beer, on tap or bottled.
Advertise the tour of the brewery, which is totally awesome and will make anyone a fan for life.
Now we’ve stepped away from design trends, and into the “why” of the website. Often the person closest to making the product will be most able to communicate the purpose better than anyone else, but as an experienced designer, developer, or consultant you may have some great ideas based on your past experience and your expertise. Once we’ve figured out the purpose of the site, it’s time for the designer and developer to sit down together and work out some wireframe mockups of how the site will look. If you like working with a computer interface, I recommend Balsamiq, but I usually do wireframing with a pen and paper myself, with a tiny notebook for mobile design and a larger one representing a larger screen. Designer and developer can both have a lot to contribute to this phase of the design process. You may go through many different ideas or one of those working on the wireframe might have a brilliant idea right away. This is arguably the most important step in the process, as layout design guides the user experience, and every design should be looked at with the question “does this interface serve the purposes of the design?”
This is a good time to get together with the client or project manager on the project and explain how this website layout will make them more money. Focusing the attention away from specifics of design, and instead on the general ideas behind user experience and product goals means that the discussion is less about them telling you how to do the specifics of your job, and more about using the combined knowledge of designer and developer roles and the customer to come up with the best solution. I’ve talked to many freelance designers who resent the fact that their customers will take their design and demand “revisions” that are counter to the real purpose of the website. By outlining all the design decisions before the design is actually created, the customer can feel more confident in your work. Asking what the customer thinks, or, worse, presenting two options is the opposite of a confidence-building move.
I asked [Paul Rand] if he would come up with a few options, and he said, “No, I will solve your problem for you and you will pay me. You don’t have to use the solution. If you want options go talk to other people.” - Steve Jobs on hiring Paul Rand for the NeXT brand identity
What a confident statement! You’re not Paul Rand, and you’re probably not going to be this blunt with your customer, but what better way to instill confidence in a potential customer?
Now we’re to the point where, in a traditional inefficient design process, Photoshop files get passed around between designer, developer, and customer. Assuming the customer is out of the picture now and your team is ready for action, the designer will take the lead. At this point it’s important for the developer side to sit in on this process and be involved in the entire process to understand exactly what the designer has in mind in terms of functionality and style. This collaboration is where a code-first web development mentality really shines. Now we have a design and development team that is doing the job that they do best, and working for the goals of the customer, rather than a game of telephone where everyone’s opinion gets mixed up, and nobody is living up to their potential.
The design/development team is now working side by side, and as the elements of the design get worked out and passed on to the developer, the developer is consulting the designer on specifics of the implementation. The more each side of the team knows about the others’ job, the better the collaboration. However, working side-by-side means that even a designer that doesn’t know the first thing about implementing even HTML and CSS code is right there with the developer who knows it inside and out. And the developer who doesn’t know the first thing about design can implement the site without making oversights in the design, because any questions can be answered immediately, while that element of the design is still in the designers’ head.
Once everything is complete, the client is ready to be shown a fully functional website. Your team will be able to describe the function of every piece, which will preempt most questions and concerns. Everyone will be happy with the end result, because everyone did their job. The client described their design problem, the design and development team engineered a solution, the designer designed, and the developer coded. I really believe this way is more efficient time-wise, makes clients happier, and lets you, the designer/developer, do your job with minimal interference.
Let me know what you think about this process in the comments or via email and I’ll get back to you.
In the next post, I’ll design and develop a fictional beer company website and post, step-by-step, my own process.