Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

Adaptive Production

at 8:00 am

Reality is Messy

For the better part of the last decade, we've followed the same process for virtually every website we've built. As depicted by the Gannt chart above, it all looks pretty neat and tidy, doesn't it? The problem is that reality isn't neat and tidy. Far from it. Reality is messy — stretchy, bendy, overlappy, and running-out-of-timey. You get the idea. Even so, this process worked well for us for so long, that it took running into some serious problems too many times in a row to realize that the dissonance between our neat and tidy starting place and the messy reality of a normal project demanded that we change things up. So after a long run of doing things the way we've always done them, we decided to roll up our sleeves and remap our process.

But let me back up a bit. Just because reality is messy doesn't mean that we can't start with some kind of order.

The project I visualized above elapses over the course of four and a half months. On average, most of our projects tend to take longer than that, but that is not on account of the work itself taking longer than we plan for. When projects make slower progress than we anticipate, it's typically because it takes longer for decisions to be made — especially if there are many stakeholders that need to contribute to decision making. The more people, the more difficult it is to get everyone around the same "table." So, while a four month project from start to launch is completely feasible, it's pretty unlikely. Looking back over the past year, most projects required timelines of around six months. So, where we start needs to adapt along the way. This is where order — and the preservation of order — comes in. Across the company, we always have multiple projects in process simultaneously, with most individual team members involved in more than one. If one project delays, it becomes a challenge to reschedule it if another project remains on schedule. Specifically, rescheduling a phase of work may not be immediately possible. So, even a minor delay at a key benchmark could offset a project considerably.

Here's a very common example of that:

Design always takes longer than we think. Always. And that makes sense, really. It's the most subjective and personal aspect of the process, and consequently, when our clients — or anyone, really — will need the most reassurance and time to think through decisions. So, if the design approval is not met on time, the rest of the project has to adjust.

In these Gannt charts so far, you may have noticed that we've divided our production process into two distinct phases: (1) Programming and (2) Skinning. In the programming phase, the developer uses our approved prototype to begin building the site's structure, page templates, and logic. Once this is complete, everything actually works — we can train our clients in how to use the CMS and they can start entering content — but the site doesn't look done. Skinning is where the developer applies the approved design to the site. Historically, this has worked out well; since programming isn't tied directly to design approval, a delay in that approval can only slow down progress so much.

So, taken at face value, a delay as depicted in the above chart isn't great, but it's not world-ending, either. It will leave skinning and Q.A. in a strained situation, but at least the client can enter content on time.

But, as it turns out, that's not the real problem.


It Depends Upon What You Mean By "Done"

The real problem is that the line between programming and skinning is fuzzy. It's always been fuzzy, but it's become more obvious in recent years as the designs we've implemented have gotten more sophisticated. Often, functionality that requires content entry, like slideshows or something visual like that, won't be built at all until the skinning phase, so if that's delayed, so is a portion of content entry. But, the larger issue is that once the design is approved, many of the structural decisions a developer has made in the programming phase based upon the prototype have to be rebuilt due to how they've been designed. It's not that the functionality has changed, but how information is distributed on a particular page. So, even though the programming has been done, much of it might need to be redone. In fact, once you start a project like this, nothing really ever feels "done" until you're in the middle of the next thing, and even then, that's a bit of an illusion. So, in reality, things start stacking up, like in the Gannt chart above.

Or, like this:

Here is another common scenario. The design deadline has delayed, but there is pressure from the team to start skinning anyway — to ease into it with portions of the site's design that have been approved, even though the entire design has not. This is dangerous. If we don't hold the line here, and wait to begin skinning until the entire design is approved, we could end up having to redo significant aspects of design application because something global was changed in a later design decision. I've seen it happen plenty of times, so no matter how much pleading, an "ease-in" is a no-go.

But that makes the design approval milestone a really intimidating point in the process for everyone, especially the client. The prototype is the source of truth to which everyone is accountable, but that doesn't mean that there shouldn't be some latitude in terms of interpreting it for design. If the homepage in the prototype includes a slideshow and a few other sections featuring other content, like news items, blog posts, etc., and just happens to display that in the big box plus three sisters format, the design should be able to rearrange that stuff. But, if the developer has already built that structure in the programming phase, a redistribution in the design means having to re-build the structure.


A Better Way for Messy

We needed a better way — one that gave the appropriate latitude to design and preserved efficiency for production.

So we settled with this:

The first step was to consolidate production. No more programming phase followed by skinning phase. Instead, we would wait to do any production until the design is approved. The consolidation itself offers tons of efficiency gains to the developer — being able to build with a resolved design in mind saves a lot of time and prevents all of those re-dos that we'd grown so accustomed to over the years. It also affords us the opportunity to reconcile the prototype with the design before production begins, so that any reasonable changes to structure as prototyped would follow the design and not confuse the developer. So now there's a week to review the prototype, the designs, tweak the prototype, and prepare the developer for production. Time to review is pretty important, as it may have been weeks or even longer since the developer last reviewed the prototype.

This adjustment also makes Q.A. much simpler. You may have noticed that before, we scheduled Q.A. as a long, ongoing phase that kicked in after the programming was complete. We typically would put an un-skinned site through Q.A., which was honestly a large waste of time since much of the items that would come up during Q.A. were issues that were simply a result of the site being un-skinned. Then, we'd skin the site and put it through Q.A. again. Now we only had to do it once. Additionally, this Q.A. phase after production could happen before we expose the site to the client and got them going on content entry. This makes the next step, which are implementing any tweaks that came out of Q.A. and client integration much more manageable. Before, it was just a huge stack of work that we'd manage ad hoc, or in other words, barely keep up with.

So far, this has been working pretty well. We've yet to see a big gap between prototyping and production due to a significant delay in design, but I'm sure that will happen at some point. And that will be the big "con" to weigh against all the "pros" that come with this new process. But I'm confident it won't outweigh them. We're already seeing shorter and more manageable tweaks lists, too.

So that's where we are. Any input you have is welcome!


Jessy | February 12, 2014 7:12 AM
newfangled a really organized company. great tactics for better production process. Once again well done to the whole team of the company. good luck! I hope in time to share the latest tactics for clients
Leban Hyde | October 8, 2012 10:00 AM

I've been looking forward to a write-up about your process since last we spoke. Bravo to you and your team for having the perspective to spot the flaws in process and the courage to change them. A change in process is never easy. (No easy button for that one).

I'm with Mike, that we use a similar pattern. Our designs are often accomplished upstream from development and we pretty much try to have everything nailed down by production time. We have (or try to have) all parties present every step of the way so that there are no sudden changes and that has seemed to help quite a bit.

I'd be curious to know if your developers work modularly. We have adopted this approach in both front-end and back-end and have noticed a significant decrease in production time. See also: SMACSS, OOCSS, OOP.

Thanks for sharing your process.

Christopher Butler | October 8, 2012 9:04 AM
Mike: We generally follow a two-stage process for design — when we are providing it to our client, as apposed to partnering with an agency that provides the design — that first deals with the language the design will follow in the form of mood boards, and then applies that language to the structure of the site in page layouts. Ideally, we'll present 2-3 moldboards with fairly distinct visual directions and, after securing approval on a direction (that might require a second mood board), move right into page layouts. This has worked out well for us since the mood boards isolate the stylistic elements of design (typically called "look and feel" stuff) like the color palette, typography, imagery, textures, etc. This helps with the distinctions we try to make between our prototyping process — which focuses on information architecture and design apart from aesthetics — and the "traditional" design process, which marries aesthetics, branding, and user experience. (I am sure I'm opening all sorts of worm cans with this treatment of the process, but so be it.)

As for Q.A., we've been tweaking that process quite a bit lately. Because of the process changes I talked about in this post, Q.A. has been adjusted. Before we consolidated production, we would do a round of Q.A. after the programming was complete, which addressed mostly functional issues, and then another round after skinning (design application) was complete. This seemed fine on paper, but in reality it often was redundant and not a great use of time. Many functional elements would have loose threads until skinning, so they'd show up in the first round of Q.A. as bugs and then in the second round if tweaking was needed. With this shift, we're now focusing Q.A. at the end of production, and ideally, scheduled with ample time to address issues raised there before the client is exposed to and trained to use the new site. We're hoping this change will reduce the volume of issues raised in Q.A. (and tweaks lists in general) and allow the integration (content entry) process to proceed with ad hoc adjustments as needed. The vulnerability with this approach is in volume. An ad hoc approach to tweaks pre-launch is fine provided that the team has the bandwidth to deal with them that way. But if the team has too many projects in this phase simultaneously, ad hoc can make for a nightmare.

Lisa: Our sites are programmed in PHP and built around our proprietary CMS (for the most part — we occasionally do WordPress or Drupal if necessary). Each project team consists of two project managers, who directly lead our clients through the prototyping process (both consulting our clients on IA decisions as well as building the prototype itself), then lead the rest of the team — designer (who provides mood boards and layouts), developer (who does the programming), client — through the remainder of the process.

Though some changes have been made since I wrote them, you both may be interested in reading the two-part series on How a Website is Built (Part 1, Part 2), as well as this article on Prototyping for Designers, which gets into detail on the differences between prototyping and visual design.

Thanks for reading and commenting!
Lisa Pignetti | October 5, 2012 11:15 AM
What do you usually build your sites in? Custom HTML? Wordpress themes? And who do you have working on the project, in terms of roles? (for example, do you have an interaction designer/IA doing your prototyping, a visual designer doing the graphic design work, etc.)

Trying to figure out how to leverage what you've learned into our design process. :)
Mike Anderson | October 5, 2012 10:33 AM
We use a very similar pattern to the new one you're using. I would love to hear about how you present the design to the client in a way that allows them to understand what the final product will be.

A second question that I'd love to hear your answer is - what does the QA process look like for you?


↑ top