The Real Responsive Process?

Posted bydaniel

The web is not a fixed width. So if the medium is fluid, should the process be fixed? Fireworks and Photoshop are not flexible enough to demonstrate media queries, button and menu states, HTML5 and JavaScript behaviors, dynamic resizing of elements and navigation flow.

Diving into responsive design projects can be daunting. Old design practices are cumbersome when thinking in terms of web systems that will span a wide variety of devices and dimensions. Four industry leaders will delve into how they handle the responsive process or how they don’t. A fluid process to match the fluidity of responsive design. Bam! We’ll also explore some of recent successes and failures while establishing why a responsive process is a responsible process.

One web to rule them all?

Presenters

Resources

Notes

We assume a lot about what users want, so we need congruent web experiences.

Responsive is often more cost effective than native app for the mobile space (in most cases)

Process: Take One

The big waterfall here is a great foundation but isn’t meant to be followed directly.

  • Kickoff/charter (set a baseline)
  • Analyze (who/what’s involved, user stories, context of the project, discovery)
  • Content strategy (planning) GatherContent
  • Strategic direction (where does this project need to take us?)
  • Design (ux sketches, page tables/hierarchy, interaction design/prototypes, visual design/language/brand, style guides/interface harmony)
  • Develop (cms build, test …)
  • Deployment (content migration, user acceptance testing/understanding, doc/train/test user stories against QA)
  • Launch/Release (introduction to “the world”, start of the operational plan/the birth)

Process: Take Two

Let’s take a more real-world approach to this.

Deliverables
Going heavy on discovery phase will save you cost and pain later.
But an idea is to get to some sort of development quickly, but still requires an overall site strategy with basic user tasks, the story/arc we want to lead users through. Wireframes/prototypes for the key/important pages/tasks to give an idea of the experience. But after that, what are the technical pieces to meet these key things. Frameworks like Foundation and Bootstrap help us get there quickly, but can be over-used in production.
We’ve moved beyond showing the mockup (a picture of what the website looks like). You might show one view (the base view), but quickly pair that with a prototype to show more of the interactive experience. Imagination fills in the gaps (much like language) if you give them the first “word” (mockup) and the last word (graybox prototypes). The key is learning what the expectations are in a discovery process instead of doing the same model each time. And constantly checking in with the client (continuous dev/continuous UAT). Warning: bound this with the strategy, always present with that in short-term memory.
Client expectations
Bring the client to understand the system (modules instead of pages). Start describing how the system is enabling your users accomplish tasks and how the experience will vary throughout the system. “It doesn’t need to be the same experience, it just needs to provide the same opportunities to accomplish tasks (egalitarianism).” Constantly nudge expectations back to the central vision of “opportunities to accomplish tasks”.
The team
interdisciplinary because the work occurs within the interactions between team members, not a contract hand-off type situation; it’s a partnership
each team is built for the project, and the entire team is part of the entire project from the beginning

Follow-up

Is responsive design boring right now? The “stack the content on top of itself” pattern is a cop-out. Need to re-think the entire process around the continuum of screen size, a “continuum of experience.” Each breakpoint is an opportunity to have fun with your design, especially if you start with the smallest site first. Instead of designing pages, RWD is about designing systems.

Be careful of getting stuck in patterns, but there is value there. They are “tested” interaction patterns. Mitigate pattern use with style guides / pattern libraries that explain and inform the pattern use. Use of those or “style tiles” or mood boards help to abstract the theme of a site (for quick verification alongside graybox wireframes) for testing the interactions of the site once you have verified it’s going to work. You also need to test the way things work with each other (in the system) as well as how the patterns themselves work.

Let clients in to the daily status so fast shifts can be made TOGETHER; discovery isn’t bounded or limited in time, only by strategy. Constant education and communication. Go heavy on discovery and document a style guide or toolkit or pattern library helps to keep the long term value of a project. Empowering the client. AND the developer! Instead of feeling like you have no control as an art director, produce a pattern lib and style guide and you’ll see your design grow the way you hoped it would.

Budgeting: Fixed bid vs. time/materials: ballparks for the pitch, but solidified after strategy/discovery. So plan cost vs build cost. If a project has a reusable component, discount or Zero time log. Estimate time at triple (for buffer) but only bill actual time materials.