My Design Process — Design and Development (Prototypes as Deliverables)

Posted: 28 Oct 2013 05:30 AM PDT

Static design comps don’t deliver a complete picture of what’s happening on a website. While many still present comps as a design deliverable, others including myself, have moved to showing working prototypes to clients. This change is the most significant way my design process has changed.

A series of prototype bottle caps leading to the final design

Last week I mentioned the different phases in my design process and talked in more detail about the first two (problem definition and solution planning). Today I want to continue and talk about the next two phases (design and development). As a quick reminder here are the 5 phases my process goes through.

Problem definition
Solution planning
Design
Development
Deployment

I left off in the solution planning phase having turned a collection of notes across several text files into an html and css style guide/tile that I present to clients. I create it to show clients possible options for the design of their site. It’s mostly contains options for type, color, and some aesthetic details that they can view in a browser as opposed to an image.

If you haven’t read the previous post you may want to have a look before reading further. If you have, read on.

Design

Somewhere between making notes in text files and creating the html and css style guide/tile as a deliverable for clients, I enter the design phase of the project.

What used to be two very distinct phases with clear beginning and end has become one longer phase with fuzzier edges

In the past this would have meant a highly detailed Photoshop comp, but they don’t give a good picture of a responsive design and I often found clients would be more focused on working through details before getting the big picture set.

That’s where prototypes come in. They start with the style guide/tile which, in my case, might be little more than a few color swatches and some font pairings. While hardly a prototype at that point, it does lead to feedback and gets the client involved in the process.

At first my ideas for layout probably aren’t there, but little by little I build them in. If I’m going to present several typeface options, there’s no reason why I can’t use real content and there’s no reason why I can’t place that real content in a layout that could become the real layout for the site.

Where I wanted early conversations to be focused on the layout, my clients focused on the details. The layout and structure of a site are the more time consuming changes later in the project so I want to get a handle on them early.

However, I’d often find my clients didn’t have as much input about layout as I thought they would, at least without the details of what would be inside. Now I don’t ask for that input. The clients who do have specific thoughts about layout will tell me as soon as they see real content in any layout and those that don’t are fine leaving it to me, offering an occasional suggestion here and there.

As feedback comes in about type, color, imagery, and other aesthetic details I remove the options my clients reject and place the options they like inside what I think we should use for a layout. With each round of feedback the prototype looks a little more like what will become the finished design.

One thing I’ve gotten better with this past year is using Sass to organize my code. Type, layout, and color code now go in their own separate files which get included into the whole.

Color files might include a series of variables that can be changed quickly to try different color schemes. It’s similar for type files that contain fonts and font-sizes, etc. These files are easy to start as they require little more than copying notes from my text files and pasting them into .scss files.

If a client wants to see a different color scheme, I open the color module and change the values of the variables. If a client wants to try something different in the type it’s the same.

I don’t blindly make changes based on the feedback. For example on a recent site I presented a client with several type pairings. They liked a display face from one pair and a type face from another. I didn’t think the two would work well together so I created new pairings for each of the faces they liked and had them choose one pairing.

The process helps keep the client involved and focused and gets me feedback before I spend too much time going down a wrong path. I’ll create as many prototypes as needed, usually one for each representative page type and each will go through several rounds of iteration between myself and the client. By holding some things constant in each iteration we can more quickly work through the options for one aspect of the design at a time.

Development

One benefit of the design phase above is that by the time the design is approved a significant part of development is already finished. The design phase leaves me with developed page templates for each representative page type.

If we were only building a static html and css site, it might even be done outside of creating the pages and adding the specific content for each.

That’s typically not the case. (I can’t even remember the last time I built such a simple static site). More likely the site is going to end up on WordPress and the templates will need to be converted into a WordPress theme. Not always, but close to always.

There are usually a few things to do first, though. As Windows and thus IE isn’t installed on my primary laptop, the prototypes will need some testing. I typically have both Safari and Firefox open while working and I find my clients are predominantly using Chrome so odds are things are working well in those 3 browsers. I’ll test in different versions of IE and Opera at this point.

While I know it’s best to design and develop mobile first, my clients tend to be more focused on widescreen browsers. It depends on the client, but there’s probably some responsive work to do, though I’m likely much further along in the responsive process than I used to be.

With working responsive page templates I start converting everything to the files for a WordPress theme. The basic files don’t take long at all as it’s mostly copying and pasting the right parts of the prototypes into the right theme files.

I’ll then work to convert a few html things into WordPress things, such as changing an html list for the navigation into a WordPress template tag. That’s followed by working on the parts of the theme that require more functionality beyond the basic pages. It probably means incorporating a few plugins, which might also need some customization to fit the design.

At some point I’ll have done all I can locally. I’ll install and configure WordPress on my client’s server and push what I’ve done locally to their server. That brings us to the deployment phase which is where I’ll continue next week.

Summary

More than any other parts of my process, design and development have been undergoing the greatest change the last couple of years. Mostly this is due to moving from fixed-width sites to responsive ones, but a desire to keep clients focused and get them more involved has also contributed to the changes.

The change that’s leading all others is that I no longer deliver static Photoshop comps to clients and now show all deliverables in a browser. At first these are simple pages that present type and color options.

Over several rounds of feedback and iteration these style guides become working prototypes for representative pages on the site, which makes development a quicker phase in the process than it used to be. What used to be two very distinct phases with clear beginning and end has become one longer phase with fuzzier edges.

Next week I’ll walk you through the last phase in my process, deployment, before offering some observations about the overall process and thoughts about how I can improve it.

If you liked this post, consider buying my book Design Fundamentals

The post My Design Process — Design and Development (Prototypes as Deliverables) appeared first on Vanseo Design.