Designers & Developers

I wonder if being a Designer or Developer is a bit like a game of Dungeons and Dragons. We have our guilds, our loyalties, our secret powers and the narratives we tell each other to get to the goal that we want. Now, we could be on the same team, working in the same company, trying to reach the same goals. But sometimes, it hardly feels like that. Marketing asks me to design something, I hand it off to the developers and in the end it looks nothing like the photoshop file I handed off to them. They didn’t meet my goals of a clear navigation, visual hierarchy, color theory, rounded corners, stunning typography, etc. And to them, my design seemed too complicated, too simplistic (or redundant). They wanted fast, lean code, and coded the web page to match their standards and goals.

But why would I expect their code match my photoshop file to begin with?

Photoshop is a static reality, made for static end results. We send finished (flattened usually) files to printers, or flat jpgs of our kids birthday party to the web. Even if we could, I’m not sure we’d share our layered image files on the web.

The web is this dynamic, changing reality. From July 2011-July 2012, 10% of our college website visits came from mobile devices, that’s a 380% jump from the year before. I expect next year that at least 25% of our visits will be from mobile devices. You can’t design for static realities anymore (unless you’re working in print only).

I live in this really interesting in-between world. I’ve spent a large majority of my professional life in print marketing. But, I’ve always been that one person on the team that was asked to make a web page, or to talk to the Developer team, because I understood the web. I got into design via the web in college, but quickly made the jump to print. And, I think I ‘get’ geeks. I think about how to communicate Marketing’s goals to IT departments, how to communicate IT limitations, ideas, and goals back to Marketing, and have worked as a translater between the two.

On twitter this morning, @Brad_Frost tweeted a link to @StephenHay ‘s talk on Responsive Design Workflow. And it is fantastic. I think it could be called, more generically, “Web Team Workflow” as it’s not just about Responsive design, but how Designers & Developers can work together. The talk seemed to be aimed mostly at designers who aren’t in a one-man-shop, but there’s still great stuff for the entire team in the talk.

The two big things I walked away from in the talk were:

1) People who design for the web, should create prototypes in HTML/CSS, not as static photoshop files.

2) Design from content out.

Photoshop and web prototypes

Stephen Hay suggests that in print design there are tons technicals specs that designers have to know.. we have to understand trapping, dot gain, paper differences, and why a one-color job is printed differently than a four-color job. We don’t have to know how to run the printing press, but we do have to know how to set up our deliverables differently, based on the end result.

Hay then compares this to a designer designing for the web… When we hand off a project to a developer, we should understand how it’s going to work in a browser, what the limitations and opportunities are.. and we should set up our projects in a similar way that we do for print. That is, using the right tools/deliverables for the right medium. He suggests that if designers can understand the print specs… they should be able to learn basic html and css.

(An aside… personally, I’m not sure if every designer can do this, or should do this. But if you’re a web designer (front-end), it makes sense that you should stop using photoshop. Photoshop can be a great place for experimentation, and thinking through how things might be visually set up, but what I hand to a developer (or even show a client) should begin to be HTML based. He gives a few tools and links to things that will help with this process, and I’ll include them below.)

Content Out

Hay’s Workflow is summed up in ten steps

  1. Content inventory
  2. Content reference wireframes
  3. Design in text (structured content)
  4. Linear design
  5. Breakpoint graph
  6. Design for various breakpoints
  7. HTML design prototype
  8. Present prototype screenshots
  9. Present prototype after revision
  10. Document for production

There is no real design aspects to this workflow until step four at the earliest (which is where most web designers want to start). Unless you work on a large team, most web designers are also responsible for site-maps, prototypes, design, and making sure the developer executes what we want.

Hay quotes Bryan Reiger

essentially what is the message that needs to be communicated if I was ONLY able to provide the user with unstyled HTML?

This should our starting point for our web design projects (and the beginning of content strategy as well). And, Hay goes onto suggest that this is the first step in design. Organizing the content, establishing hierarchies, and allowing the client to understand the priority of good content are the first steps to web design. Anything we add beyond this point could have a negative impact on how that content is understood, received, or responded to.

This isn’t to say that design has gone to the wayside on the web. I think it’s simply saying that designing for the web is more than just creating graphics and adding colors. Web designers have to be artists (creating something that is visually appealing to look at, while supporting a company’s brand), psychologists (understanding how people think), and manipulators (providing environments where users will have experiences, or make certain choices to meet a certain end-goal).

So what’s next?

I could go on and on about this topic. Living in this in-between world is challenging sometimes, and it’s great to hear a similar perspective from someone who is there with me. And, the wheel I’ve been inventing for myself, isn’t that re-invented. Just yesterday I drew some wireframe sketches showing the order of content groups for mobile vs desktop… I just drew boxes, numbered their order, and identified the groups.. who knew that process had a name, “Content Reference Wireframes”.

Personally, I need to start working on prototypes in HTML, and creating style guides in HTML showing how web content is stylized. Hay listed a few tools that help with that, none of these I’ve tried, so I just list them below as a starting point.

Oh, and about that D&D game I referenced earlier… it really does help when we’re on the same team, to have a similar goal in mind. I can learn from developers about version control, html, css, and test suites, and developers can learn from me about human psychology, the importance of design, and how form can really influence function.

And in the end, the users will win.

New tools for a new trade

Stephen Hay’s talk on Responsive Work Flow –
Watch it. Make it a team event. Seriously. Go watch it now, the links will still be here when you get back.

Dexy –
Flexible Documentation Tool

Knyle Style Sheets –
Documentation for any flavor of CSS that you’ll love to write. Human readable, machine parsable, and easy to remember.

Bringing a Knife to a Gunfight –
Andy Clarke’s talk about designers on the web from An Event Apart, Austin 2012

Style Tiles –
(He didn’t mention these, but I’ve already been looking at this idea for awhile)

And you?

What tools are you using? How do you, as designers and developers, work together on your teams?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: