Coping With Change
A couple years ago, Matt Griffin wrote an excellent article for A List Apart detailing how his firm handles design comps for the responsive web. Our process at MDM developed along a similar path, though informed by our own experience and resources. We’ve made some adjustments over time based on the feedback we received and our internal reviews of completed projects. Today we’d like to share that process, and start thinking about how it might change in the future.
Our initial meetings with a client are all about the big picture. We call this “discovery” and it lays the foundation for the rest of the project. What is the site or application meant to accomplish, who is it for, what are the big features we want to focus on, and what are we aiming for in terms of look and feel? The answers to these questions help us on the engineering side to choose a platform and on the creative side to establish an initial design direction.
We don’t make sitemaps for visitors anymore, but they became an integral part of how we think about a site’s structure and flow – as Matt wrote, “Hierarchy, Hierarchy, Hierarchy”. The list of pages becomes an framework that we build on, filling out details about the content and function of each page. By the time we’re finished we have a map detailing every piece of content and every software feature, where it belongs, how users interact with it, and how it all interconnects.
The catch is that today’s responsive, highly dynamic sites and applications are straining the limits of this kind of thinking. A piece of content may appear on more than one page; functionality may change based on application state; content might be loaded, altered, and replaced during run-time; it may come from 3rd-party sources (think social network widgets, e-commerce tie-ins). Whether an item is displayed on a given device might depend on screen width, OS, browser capabilities, or user preferences. The more dynamic the site, the less this looks like an outline and the more it looks like programming – complete with if/then statements and exception handling!
We don’t want to hand a flow chart back to the client for approval – a serious case of TMI – so we keep a lot of these details internal and deliver an abridged version.
Design, Build, Implementation, and Testing
As a company, we were used to showing a comp and saying, with confidence, “this is what you’ll see when it’s done.”
Not so many years ago, these were separate, sequential steps. Once we had a sitemap our designers would go to work building a comp of each unique page layout for the site, we’d present it to the client, then rinse, repeat until we had a stamp of approval. As a company, we were used to showing a comp and saying, with confidence, “this is what you’ll see when it’s done.”
Next came the “flat” build – our frontend developers put together a static HTML site with placeholder content. Finally the backend folks would integrate that with server-side software, then we’d test (and test, and test) and launch the project. Each role had a specific place in the process that ended before the next team began work.
These steps have woven together into a fluid conversation between designers, developers, clients and management. A Photoshop comp doesn’t really capture a site’s dynamic behaviors or specify how to handle content changes, different screens display the site in different ways, and user interaction or communication with the site’s backend changes how content is presented. We find you can’t really understand a site till you see at least some of it in action.
Matt’s article suggests using a service like Heroku to show development in-progress. We have our own servers and infrastructure, but a lot of the broad strokes are the same – deploy a version with a design draft and some prototypes of functionality (including drafts of the various breakpoints), solicit feedback, and refine. We use a version control system (Git!) to track changes. The big implication here is that all hands are on deck during each project.
This is something we really struggled to adapt to, and in some ways we’re still finding our footing, but it has yielded unexpected benefits as well. Moving this prototype-deploy-refine approach meant that developers had input much earlier in the process and clients got to provide substantive feedback much later, leading to a more polished and better engineered result. Fewer bugs, less development time spent working around our often-challenging designs, and clients who had a better idea of what the site would look like in action before it launched. Everyone is happy, right? Well, almost.
This Isn’t What I Paid For!
That’s a phrase we all dread and try to minimize in the web world. Removing that fixed, finalized, approved comp does lead to more questions for and surprises from clients. Furthermore, many clients don’t want the hands-on experience – they’re paying us to handle all that. Managing expectations and educating clients is a bigger job, and so is staying on top of milestones, keeping on top of deliverables, and all the other things that create long hours at the office and keep us up at night. It would be nice to wrap this up with a silver bullet that fixes all that, but the truth is that a responsive web requires a flexible team.
the truth is that a responsive web requires a flexible team
If we can leave you with one piece of advice it’s this – don’t mistake “flexible” for “infinitely expanding”. Set parameters at the beginning of the whole process. When is the client responsible for delivering content and design materials? When does a design element or feature become set in stone? How many platforms will you fully support, which are worth delivering a simplified but reliable experience to, and which will not be addressed? Are there aspects of the project that can be delivered after the initial launch (or in startup lingo, what is your minimum viable product)?
Your time is not infinite, your budgets are not infinite, and your deadlines are not indefinitely postponable. Being fluid and flexible is not mutually exclusive with maintaining control of the project!
In part 1, we gave a brief overview of design in the early days of the web. In the third part, we’ll look at some emerging technologies and how they may further change how we approach design.
Categorised in: Blog
This post was written by Mad Dancer