BDConf: Stephen Hay presents Responsive Design Workflow

In Responsive Design Workflow, Stephen Hay (@stephenhay) talks how we have to adapt our workflow as well as we adapt our experiences.

  • The landscape has changed, but our workflows have not. We need to change that.
  • Updating Photoshop documents for web designs is immensely inefficient, especially for responsive designs.
  • Design from the content out. Content and form are lovers, their love-child is design. Design is simply not a sauce you put on top.
  • A great exercise is asking “what is the message that needs to be communicated if I was ONLY able to provide them with unstyled HTML?” This forces us to prioritize.
  • We refer to anything that isn’t desktop as “mobile”. See also Desknots.
  • Interaction Designer – main wireframe. Every decision that gets made throughout the chain influences the interaction design. Interaction design isn’t wireframes. Wireframes reduce visual design to decoration, simply a coloring book exercise. It reduces everyone’s work.
  • There’s no such thing as a perfect process. Pragmatism is essential for evolving process for responsive design.
  • We’re not designing pages. We’re designing systems of components.
  • Plain HTML works on your phone. JOB’S DONE!
  • The device landscape is constantly changing. Properly structured content is portable to future platforms.
  • Zero interface thinking: everything we introduce has the potential to ruin everything. Ask: Is this absolutely necessary?
  • Version control, preprocessors, frameworks, templates, etc can make responsive process more effecient, but be careful when you introduce them into your workflow.

Stephen’s Responsive Workflow

  1. Content Inventory – establish and describe the content. This gives you your raw materials
  2. Content reference wireframes – establish rough responsive wireframes in HTML. Allows for really fast iterations.
  3. Design in text (structured content) – establishes content hierarchy and structure. Easily revisable.
  4. Linear Design – Test out the plain jane structured content in HTML in the browser.
  5. Breakpoint graph – display visually where the breakpoints happen
  6. Design for various breakpoints – Start with the small screen first, then expand until it looks like shit. TIME FOR A BREAKPOINT!
  7. HTML design prototype – If w’ere not delivering designs in PS, what do we deliver? Clients wants PS because they’re used to it. Create HTML CSS, and maybe a bit of JS
  8. Present prototype screenshots – It’s part of a presentation psychology – Presenting static “impressions” of the design across the different breakpoints allows you to stay ahead of your client.
  9. Present prototype after revisions – Once revisions have been made, you can show the design in action
  10. Document for production – Deliver a style guide along with the production code.

6 Comments

  1. andyetzel

    Brad, every conference you attend ends up on my twitter feed… I love it! What does your “new” workflow look like?

  2. Sebastien Gignoux

    Hi Brad, thanks for sharing this notes.

    I have been thinking a lot about the “Present prototype screenshots” and “Present prototype after revisions” steps. It can become easily a mess for the designer and its clients with so many screenshots to share and get some feedback on. Even if you present face-to-face, you want to give something for your clients to refer to when he wants to review the design or show the work to somebody else.

    Any thoughts on you could solve that? I guess some online tool might help, but I haven’t found anything that have some secure access for my client, show an accurate preview of the mockups and don’t get a mess with all the files.

  3. gray ghost visuals

    Yeshhhh I agree @andyetzel. Brad’s next blog post should discusss his workflow or something similiar to how he approaches dynamic wireframes besides just the mobile first approach. Maybe an inside look at what RGA does for their approach?

  4. gray ghost visuals

    @sebastien
    I think having a hosting account purely for testing purposes to show clients can be extremely beneficial. This way they see exactly how it behaves on the actual server it interacts with.

  5. Jonathan Stark

    This post should be required reading for every web professional. It’s spot on perfect. The idea of presenting screenshots of HTML prototypes is a stroke of genius.

  6. James Young | @welcomebrand

    I have to admit I am starting to wonder a little about some of these conference presentations being quite a way behind the curve of how designers are actually doing their jobs day to day even though I massively respect people like Stephen.

    This May (25th) will represent 3 years since Ethan’s article was posted on ALA and which changed the way we all thought about the web and did our work in this crazy-ass multi-device environment but when I see a lot of conference feeds and slide summaries, I’m still seeing things like

    * We must abandon full visual mockups
    * “Our” workflows haven’t changed
    * Design content first

    It’s a bit scary to think that someone who’s entered the industry in the last 3 years will have done so in the context of responsive design being something that’s “always been around” and those who have been doing the job more than 3 years will have (I hope & assume!) long since known that they need to modify their processes and how they work on projects.

    Naturally without the larger context of the talk itself my comments may seem harsh or unfounded etc but just wanted to put those thoughts out there.

    @welcomebrand

Comments are closed for this post. If you've got something to add, feel free to reach out on Twitter.