A case study showing how we replaced wirefaming with a framework led prototype to better deliver a responsive web design. by Ben Scammels, Designer at http://www.makemedia.com
1. Design processes, prototypes
& responsive web design
(AKA: Designing For the Internet in 2012 and
sharing our experiences)
Ben Scammels - Graphic & Web Designer
2. Design Processes, Prototypes & RWD
MY BACKGROUND:
Graphic and web designer who works across UX, design and front end.
I’ve worked with many design processes over the years
THE CHALLENGE:
As we make websites responsive, old design processes become
unsuitable and inefficient
WHAT DO I WANT YOU TO GET OUT OF THIS:
To see how to replace wireframing with prototypes (using others
research/techniques) and why its a better process for responsive design
4. Responsive Web Design (Ethan Marcotte, 2010)
• RWD allows you to tailor a site’s layout and
interfaces to suit various devices
• SIngle codebase (unlike app/m.sites)
• futureproofs site
8. When the wireframe process goes responsive
KEY PROBLEMS WITH WIREFRAMES:
• RWD could increase wireframing x 3
• Wireframes struggle to show interaction
• They’re not usable - one must imagine a user journey
CONCLUSION: We need a better design process to
approach a responsive project - A PROTOTYPE
9. Our thoughts on Prototypes
• Functionality & interaction can be discussed/defined in a more
‘realistic’ way.
• Layouts work responsively
• quick/easy to produce and amend
• Minimally styled
• It’s a place to propose a solution.
Not for perfect coding.
10. A new project requires a new approach
• Small budget required an efficient process
• Client wanted to improve the mobile experience
• We got the contract based on it being RWD
• Great opportunity to test run a new process
11. Steps to making a Prototype
1. UI sketching, mobile first
2. Research ‘Accelerators’ for building prototype
3. Build the prototype based on appropriate frameworks
4. Usability test & iterate
5. Apply style layer
12. Steps to making a Prototype: UI sketching
• Helps client understand RWD
• Sketching allows discussion and
instant iteration
• ‘Mobile-first’ layouts helped the
client focus on the essential
content
“smaller screens force designers to
focus on what’s truly necessary to
a service/product” - Luke W
13. Steps to making a Prototype: research tools for UI sketches
http://sneakpeekit.com/
14. Steps to making a Prototype: research tools for UI sketches
http://sneakpeekit.com/
15. Steps to making a Prototype: Responsive UI sketching
• Sense check & Improve workshop
sketches
• Mobile then desktop versions
sketched out and discussed between
teams = iteration
• Desktop versions very light on content
NB.Tablet layouts handled in the browser
18. Steps to making a Prototype: Research accelerators (Frameworks & Tools)
FRONT-END FRAMEWORKS:
• Are a set of commonly used start-up code that can help you quickly
build a site
• They contain ‘best-practice’ coding from leading developers
(MIT, Twitter, etc...)
• Documentation = better collaboration
• HTML/CSS/JS - easy for developers
19. Steps to making a Prototype: Research accelerators (Frameworks & Tools)
FRONT-END FRAMEWORKS:
They contain MODULAR pre-coded
elements to drop in:
• User interfaces
(navigation, buttons, forms, tabs...)
• Essential styles
(fonts, colour systems, icons...
helps indicate usability)
• Page structures
(grids, layouts, templates)
20. Steps to making a Prototype: Research accelerators (Frameworks & Tools)
CONS:
• you need to learn their system (couple of days)
• the codebase is HEAVY. potentially not wise for production
• Hard to customise some elements so...
• ...can lead to ‘homogenisation’ of designs/layouts unless tailored
22. Reviewing Frameworks & Prototyping tools
• Aimed at the UX market
• WYSIWYG tool for making
prototypes
• Outputs html/css/js so can be
integrated into other prototypes
• Quirky to learn (a bit like flash)
• Expensive
• Isn’t responsive
• Not ideal for all team members but great for UX
http://www.axure.com/
23. Reviewing Frameworks & Prototyping tools
• similar to bootstrap
• Responsive
• More UI elements & common
layouts included
• ‘dumbed down’ - easier for
designers with code knowledge
• ‘Stencils’ for Illustrator/omnigraffle
(if you have to do wireframes)
http://foundation.zurb.com/
24. Reviewing Frameworks & Prototyping tools
PROS
• Resource of current
responsive layout, navigation
& UI patterns
• Provides analysis
• lighter code =
easier to customise
• could be used for production
http://bradfrost.github.com/this-is-responsive/patterns.html
http://bradfrostweb.com/blog/web/responsive-nav-patterns/#toggle
25. Reviewing Frameworks & Prototyping tools
CONS - Not intended for reuse so:
• No documentation
• not styled so extra work required
• not as ‘modular’ as framework
(requires coding knowledge to be
able to drop elements in)
http://bradfrost.github.com/this-is-responsive/patterns.html
http://bradfrostweb.com/blog/web/responsive-nav-patterns/#toggle
26. The Prototype
• existing content = understandable
• Usability test (‘early and often’)
way before production code is
available
• character counts for copywriters
• helps spot missed functionality
early in timeline
27. Conclusion
• Responsive web design is a pragmatic and economical approach to modern
web design.
• Traditional design methods become unmanageable when going responsive.
• Mobile first helps us refocus on users and what they really need and want.
• ‘The pen is faster than the mouse’ - sketching is a quick way to iterate layout
and design decisions (and facilitate conversation)
• Prototyping (using frameworks) quickly brings a design closer to its final form
and helps assess interactions, functionality and responsive layout.
• Prototyping helped raise flaws, issues and unconsidered aspects early on in
the project timeline
28. Thank you for your time.
Any Questions?
FURTHER READING:
http://coding.smashingmagazine.com/2011/10/25/rapid-prototyping-for-any-
device-with-foundation/
http://www.alistapart.com/articles/dive-into-responsive-prototyping-with-
foundation/
29. Responsive Design Layer
• Avoids the same issues
of multiplying design
documents
• Can be part of a handover
doc to front end devs