For Responsive Designs, wireframes take on a whole new level of complexity. Is it better to create static wireframes for each screen width or to create an HTML prototype that demonstrates the responsive behaviors? Slide 2: The overall Design Process really doesn’t change for Responsive Design. Each phase has new considerations though: - During Design Discovery, you want to confirm device compatibility with the stakeholders and begin discussing content prioritization for smaller screens - In User Research, you may want to consider how user needs may differ when accessing the site from various devices - Content Prioritization becomes even more important for Responsive - The IA phase is where the rubber meets the road for Responsive since your wireframes need to account for various screen sizes - Same goes for Visual Design and of course, Implementation changes quite a bit! Slide 3: Example of traditional, desktop design process. Research-based wireframe is created, then designed, then implemented. Slide 4: The work multiplies for Responsive sites Slide 5: Example of static wireframes designed for a Responsive site. This is a homepage where the IA created 4 distinct wireframes to represent each breakpoint. Slide 6: Example of an HTML wireframe prototype designed for a Responsive site. This is a homepage where the IA created 1 wireframe in HTML using the Foundation responsive framework. Slide 7: Creating wireframes in HTML has some pros and cons Biggest pros = timesaver and ability to experience the site in-context (for clients, developers and usability test participants) Biggest cons = using a framework doesn’t work well for a mobile-first approach to design and creativity can be stifled Slide 8: Some lessons learned in responsive wireframing, for both static and HTML wireframes.

1. 9/12/2013 Footer 1
RESPONSIVE DESIGN ROUNDTABLE
WIREFRAMES VS. PROTOTYPES

2. 9/12/2013 Footer 2
1. Design Discovery
2. User Research
3. Content Strategy
4. Information Architecture Wireframes
5. Visual Design
6. Implementation
DESIGN PROCESS

4. 9/12/2013 Footer 4
• To implement a responsive site, developers need to know how the page
should look at 5 different breakpoints:
1. Desktop (960px or larger)
2. Tablet Landscape
(960px - typically use same layout
as Desktop)
3. Tablet Portrait (768px)
4. Phone Landscape (480px)
5. Phone Portrait (320px)
DESIGNING FOR RESPONSIVE BREAKPOINTS

7. 9/12/2013 Footer 7
PROTOTYPE PROS
• Shows how the site will work
• Less hours required for someone
with good HTML skills
• Code could technically be picked
up by WebDev
• Default behaviors for smaller
screens are built-in to the code but
are also easy to change/override
• Iterations are super fast since you
can just FTP new code
• Learning curve for HTML coding
• Doesn’t lend itself to a mobile-first
approach
• Limitations in how to do something
in code may limit creativity
• Having default behaviors for
smaller screens built-in to the code
may limit creativity
AND CONS

8. 9/12/2013 Footer 8
RESPONSIVE WIREFRAME GOTCHAS
• For large feature images/carousels, always plan for what happens on
smaller screens, especially with text overlays and calls-to-action
• For sites that include a login feature, always plan for:
- logged out state (aka. initial page load)
- how a person will log in (go to a new page or how form fields should display)
- logged in state (aka. Welcome XXX)
- logged in actions (My fundraiser/events/other, Edit my Profile, Log Out)
• Account for how Social Sharing will adapt at different breakpoints
• Design any section navigation needed beyond the first level
• Plan an alternative for any tappable maps or other interactive features