Client Deliverables that Work in the Real World

Rob brings his pragmatism to our Sparkboxing match, contending that we need to be realistic about what we're able to deliver to clients.

I am a realist. Playing with new methods and technologies is a hobby of mine, but I have enough scars to give me reason to be pragmatic. I am also a firm believer in an iterative development process, and I like to do things only once if at all possible.

Given that I'm Sparkbox's Technical Director, it is sort of funny to me that I have such a strong opinion about deliverables for design, but here we are.

Involving The Client

During scheduled reviews with clients, I like to share everything that we have produced since our last review while explaining our process. Putting as much as possible in front of the client allows me an opportunity to educate them and get feedback early. Getting work in front of them early allows for the least amount of rework if something needs to be changed. This is important for content, design, code, process documents, and anything else the team has found necessary to achieve the project goals.

I don't like to waste effort. Our clients trust us to spend their budgets wisely. They came to us for our expertise, so if something does not add value, it shouldn't be done. When it comes to design—layout, typography, etc.—in the web development world, flat and static layouts produced in Photoshop are king. But should they be? Some question if they add appropriate value to the design process.

My Take: It's About Value.

We have all agreed that the web is a dynamic medium which is generally hard to communicate through static images. This has become more challenging as we've begun developing responsive websites; however, unless we are going to start designing directly in the browser (which we currently are very limited in doing), we will need to continue designing with fairly static media. The photoshop layouts still work. Though far from perfect, they are still our best option.

Since we'll be designing with static layouts (not in a browser), and given that we don't want to waste the client's time and money, we should want to have approval of the design before moving into the browser. The further we get into our process without client feedback, the more time and effort it takes to make changes. Showing the client static layouts before HTML/CSS is valuable. Simple as that.

Doing Your Best With the Tools You Have

In responsive web design, we've experimented with designing a mobile layout first (320px), then creating an accompanying layout for a common desktop resolution (960px). This demonstrates how elements respond to differing viewports. We felt it had value to see these common "bookend" layouts and the accommodations that were made for the same content in very different environments.

Now, don't get me wrong. I don't believe that you should design a layout for every possible resolution; however, any that you have found useful to create should be shared with the client. This ensures that you get the most benefit from the work that you've done. If they ask about other resolutions, simply explain that they will guided by the design in front of them. You're good at what you do, right?

Educating our clients is not only a good idea, it is necessary if we want to build a long-term relationship. If your clients are involved in more of the process, they feel more invested and trusting of your work and opinion.

As a side note, I also believe that you should share the responsive HTML/CSS templates (created from your static design layouts) with a client before completing the rest of the development. Again, this is just an effort to get approval before moving forward.

Being Realistic

If our deliverables need to change, then so be it. With an ever-changing medium like the web, we will always need to adapt our processes. But those processes need to use the most effective tools available, and we should always try to get feedback as early as possible. After all, no one likes to start over deep into a project.

Who's with me?