Mar 06 2013

On Incorporating the Aqueous Production Process of a Unicorn

On the aqueous production process of a unicorn

The web design industry approaches people like me wide-eyed and with a grand hesitation. I am a mythical beast that can’t be trusted; I am, both, a designer and a developer. I can make it rain PSDs and then splash puddles in the code. It’s too good to be true…right now.

Over the last few years, the industry has been rapidly changing. Once rigid and agreed-upon, the approach for producing websites is now crumbling under the weight of new technology. The recent explosion of different devices and browsers that will display our industry’s work shows no signs of slowing down, while the rise of new tools and techniques, like robust frameworks and CSS-driven animations, are speeding up the pace of production and exploration. With our newfound velocity, we certainly have the potential to accomplish more, but we’re overlooking one of the most obvious points of failure and potential refinement: the production process itself.

More specifically, as the line between designer and developer tasks continues to blur, the classic paradigm of separating design and development starts to look bloated and slow and requires extra rounds of revision. Good communication between the designers and developers certainly helps, but there will come a point where the cleanest solution is somebody who understands both design and development. It’s not a huge leap to wonder whether more unicorns, ones who design and develop, will be sought out to help bridge the gaps and ease this tension. As a matter of fact, I might even wager that us unicorns are on the cusp of a population boom.

Blessing of unicorns

From a design perspective, it’s becoming less and less practical to prepare pixel-perfect PSDs. Given the myriad of screen sizes and resolutions for which a designer is now held accountable, the work required at each phase of production is quickly amplifying. And PSDs are kind of a lie, anyway. A PSD pretends development isn’t a factor – it’s a painting of a false reality where every screen is the same width and every computer and browser can faithfully recreate every pixel. At its very core, PSD-driven design is a one-size-fits-all approach that is ballooning out of control.

Conversely, while the sun may seem to be shining on the developers’ side of the street, it’s really not much brighter for a developer-only approach. As web standards grow up and frameworks become more prolific, the barrier to entry for web development is constantly lowering. More and more web designers are learning the basics of development, leaving developers to tidy up after them and provide fixes for IE. Ironically, the things for which developers have historically fought (standards, automation, etc…) could ultimately usher the web developers to the dodos’ playground.

Realistically, we’re far from the day where PSDs aren’t handed from designers to developers, but it is important for us to recognize the industry’s current trajectory so we can best prepare ourselves for the future regardless of the camp in which we currently reside.

In my ideal world, we wouldn’t be designers or developers. Instead of crafting pixel-perfect PSDs, we would design systems of visual communication. We would let content be our guide and develop while designing. Areas that require knowledge from both fields would expose themselves and we could adjust our focus as necessary. As a result, challenges would be better understood and solutions more robust.

Blessings of full-fledged unicorns may not be realistic in today’s web design climate, but there is an ever-expanding middle ground where designers and developers can stand together. While it doesn’t happen overnight, it’s never too early for current designers and developers to start learning about the other craft. It, not only, reveals a path to future-proofing work responsibilities, but also boosts creative output immediately.

Over the last few months, I’ve observed with great excitement as the designers and developers here at dt have flirted with (and crossed) the line that currently distinguishes their roles. Here are some things I’ve seen:

Curiosity for the opposite workflow

The Designer – Last week, one of our designers was overheard saying, “I wouldn’t mind learning some code.” Quickly echoed by some other designers, they began their journey. By catching a glimpse of the tools on the developers’ workbench, their designs will undoubtedly get better as they explore new ways to use those tools. They can still push design boundaries, but they will understand the limitations and the reasoning behind them.

The Developer – Before development at dt, we do a design handoff where the designer and the developer sit down together to go over the design. The designers will give special instructions and point out interactions, while the developers will flag areas of concern…and, generally, crush dreams. Lately, however, the handoff has become more of a conversation where the developers ask questions to try to understand the chain of thoughts that resulted in the design file. The idea is that, by understanding where the designers are coming from, the developers can better advise resolution for the problem areas and also carry the designer’s concerns into the hierarchy of their own workflow.

Tackling tasks for the other's workflow

The Designer – A few weeks ago, a page on one of our sites needed a round of design-driven content updates. It didn’t require code revisions, but the changes were considerably more involved than simple copy edits. It was the level of update that would normally be handled by a designer and then implemented by a developer. Being strapped for development hours, the task was given exclusively to a designer. After a quick overview of the page’s update process, the designer was off and running. He had a few questions along the way, but he is now equipped with a deeper understanding of how some pieces of the site fit together and more than capable of managing similar updates in the future.

The Developer – On the flip side, around the same time a new page needed to be developed for one of our projects but there wasn’t a design file. It was based on an existing template where the visual language had already been established. A designer would have spent just as much or more time setting up the file and tracking down assets as actually designing the page. Without a PSD to bank on, the developer ended up having to create a handful of assets and do a little designing in the code. Following a quick review from some design eyes, the page was approved and pushed to the live site. Like the designer, he did some hands-on work that he wouldn’t have done normally and is more confident in his design-eye for handling similar updates.

An aqueous production process

The Designer – A client of ours needed a single special-case landing page where they could put visitors in a holding pattern during heavy traffic. The designer who picked up the task (a fellow unicorn) finished the design portion in about half the time he was given. With the extra time, he proceeded to build the page. As the designer, he was already familiar with the quirks and the areas that had the most potential to fall over in development, so he was able to efficiently fine-tune things, like the speed of his CSS transitions, as he was building.

The Developer – One of the beauties of internal projects is the flexibility of the approval process. I am the first to admit: I take advantage of this all the time. When I have a task that has both design and development aspects to it, frequently I will approach it with little more than the equivalent of a sketch on a napkin. I create assets as they are needed. By designing and developing at the same time, a living design file is created. It’s not a picture of how I would like it to look; it’s a picture of what it is. After approval, any development time becomes much more about refactoring and integrating. And the inside-out knowledge of how things are put together make follow-up design or development edits a snap.

Again, we may be far from the day when an aqueous production process is used on a large scale, but it’s absolutely something we can move towards today. What are other ways we can incorporate elements of aqueous production into our everyday work?

Finally, if this is a topic that is of particular interest to you, there are lots of great folks writing about similar things. A few articles I’ve run into that are certainly worth a read:

About the Author:

Bradley is a developer and designer at dt (the UX house that makes stuff like SlideDeck and Hello Bar). He loves typography. Oh, and he's on Google+