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
- Content Inventory - establish and describe the content. This gives you your raw materials
- Content reference wireframes - establish rough responsive wireframes in HTML. Allows for really fast iterations.
- Design in text (structured content) - establishes content hierarchy and structure. Easily revisable.
- Linear Design - Test out the plain jane structured content in HTML in the browser.
- Breakpoint graph - display visually where the breakpoints happen
- Design for various breakpoints - Start with the small screen first, then expand until it looks like shit. TIME FOR A BREAKPOINT!
- 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
- 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.
- Present prototype after revisions - Once revisions have been made, you can show the design in action
- Document for production - Deliver a style guide along with the production code.
