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+

Leave a Response

17 Responses

  1. Mar 06 2013
    Sara Rodesch

    Excellent Article!

    I’m a one “woman” designer who also (both fortunately and unfortunately) gets to also “try” to be a developer. With my skills being more on the HTML/CSS side of things I end up heavily relying on pre-built JS Libraries to create interactions. I can modify certain elements in there which look like something I see in CSS, but anything else is beyond my scope. I can see where having both is an asset and a hold-back. I know very little about the limitations that can hold back a design, so when a challenge comes up I end up either tackling finding code which can mimic the desired interactions or I’m not afraid to state the facts – That interaction is simply not going to work or happen.

    Thanks for reminding me that we can do more than what our job descriptions state.

    ~Sara Rodesch

  2. Mar 06 2013
    Harmony

    Loved this article. Due to the size of my agency (a one man show for many years) I was forced to be a designer/developer in order to meet the demands of my clients. As business grew I had the good fortune to work with a variety of freelance designers. Some did beautiful work but struggled with understanding how it had to fit with my business model (I prefer to use WordPress and I use a standardized theme development process). The designer I work with now has been totally receptive to understanding the development process and has, thereby, been able to help me see the vision with her designs and how the UX is as important as the functionality. She is a true Unicorn and I really appreciate it!

  3. Mar 06 2013
    Leban Hyde

    Fellow Unicorn. Some also use the term “hybrid”. Both work just fine. I have found that taking the time to learn how to code has made my designs much more solid. I’m in total agreement with you that approaching a project in terms of designing a _system_ is a far more effective approach. I have all but abandoned Photoshop, using Fireworks instead for polished wireframes (for presenting to stake holders) and leaving the majority of the design process in the browser (and, as you said, creating graphic assets as needed).

    It was nice to read an article by someone in a similar position. Just one question: Do you also know JavaScript (beyond implementing frameworks)?

    Cheers!

  4. Mar 06 2013
    Raymond

    Ahhh yes! This article just made my day!

  5. Mar 06 2013
    Chau

    Unicorns are mythical for a reason…but I’m optimistic :)

    • Mar 07 2013
      aaron

      we do exist!

  6. Mar 07 2013
    Jamie Hamel-Smith

    Brilliant write-up Bradley. I think that the measured approaches that you describe are definitely the right way to start this transition. As a developer myself, I am pretty envious of the eye for design that unicorns have. Cross-training is key. I’d love to become more skilled at creating assets for a quick page build. Ideally I’d like the other team members to trust me to create assets when needed.

  7. Apr 02 2013
    Soh

    I’m on the same page w you here. But the tough part is how do you avoid becoming the jack of all trade master of none. Achieving a master level of design while still maintaining top notch deving skills, that is a tough one to come by.

  8. Jun 07 2013
    related site

    Do you mind if I quote a couple of your articles as long as I provide credit
    and sources back to your website? My blog site is in the very same area of interest as yours and my visitors would genuinely benefit from a lot of the information you provide here.
    Please let me know if this alright with you. Thanks!

    • Jun 07 2013
      Nathan Weller

      It’s not a problem if you only quote a section of the article and attribute it with a link back. As long as you’re doing that then fire away! If you’re wanting to copy the whole post though then we’d rather you not.

  9. Jun 11 2013
    Marko

    Actually no matter if someone doesn’t be aware of after that its up to other users that they will assist, so here it happens.