bizspark sf lightning talk: "design patterns for designers" by stephan orme
DESCRIPTION
Presentation from November 2011 BizSparkSF Meetup entitled "Tools, Tools and More Tools!" http://www.bizsparksf.com/events/34653282/TRANSCRIPT
Design2 PatternsDesign Patterns for Product Designers
Stephan [email protected]
Document Version 0.85Nov 7, 2011
What are Design Patterns? Originally from architect, Christopher
Alexander’s, A Pattern Language. Today, a key technique in object-oriented system design
Design Patterns are general solutions to reoccurring design problems
Patterns are hypothesis Patterns: capture experience, allow for
reuse, and provide an inclusive design vocabulary
Scope of Product Design Process
Needs: Understanding of priorities and goals
Context: platform, resources, scope, limitations, environment, and budget
Agreement: The necessary buy-In, support, goodwill and consensus from stakeholders
Direction or Plan: Includes specifications, declarative statements, decision authority
Supported by Processes: For designing and building: the team, organizational tools, etc.
Scope of the Design Process
Design Process Used To: Understanding
Needs and Priorities Get Agreement
from Stakeholders Direction for
Developers Direction for
Designers
Communicating Design Ideas
Many ways to communicate design ideas…
User StoriesUse CasesWireframesVisual DesignSchema/Data Model
WorkflowsPseudo CodeSchedules/TimelineBudgetsDeclarative Tasks
The result is an understanding of your Needs and Context, you have Agreement from stakeholders and a Plan or Direction.
DISCOVERYFiguring it all out
What is the Discovery Process?
Figuring out user needs and priorities
Learning the context: resources/solutions/limitations
Earning Agreement and Buy-in for the process and the solution during stakeholder interviews
Discovery ProcessHow to Figure out what to Build
Method Problem Benefit
Think and Doodle Castles in the Sky
Original Designs
User Interviews / Customer Development
Faster Horses Learn Things, Build Support
Research Current Solutions
Me Too Build on the Shoulders of
Giants
Research Technical Foundations
Not good to tie design and tech?
Better Design / Smoother
ImplementationResult: Needs • Context • Agreement • Process • Direction
DESIGN PROCESSComing up with a Solution
Diagramming as the Design Process
Use diagrams to directly visualize the project Use for every aspect of product design
process: Needs • Context • Agreement • Direction
Advantages Directly visualize the end product Easier to get Feedback and Buy-In Clearer Direction for Developers Less Re-Work Faster Execution
Types of DiagramsKinds of Information
Audience
Wireframes
User Workflows
UI Notes
Site Structure
Data Model
System ProcessesPseudo Code / SQL
Designers
Developers
Client
Designers
Developers
Client
Designers
Developers
Designers
Developers
Developers
Developers
Developers
The Basic PiecesThe basic elements for all Software Products are…
The Model: The underlying data model and the rules for that data
Views: Presentation of Information + Visual Structure / Coherency + Controls / Affordances
Controls: Workflows and Functional Processes
But to Implement the product you also need Agreement • Processes • Direction
Wireframes
Designers
Developers
ClientAudiences
Site Structure
Designers
Developers
ClientAudiences
Workflows
Designers
Developers
ClientAudiences
UI Behavior
Designers
DevelopersAudience
s
Data Model / Schema
DevelopersAudience
s
Why? Can greatly speed
implementation
All fields shown in Views included in Schema
More consistent data model if thought through
Avoids re-work
Useful to communicate long-term design issues
Project Staffing / Budget
Why? Understand
Project phases and resource needs over time
Calendar for Iteration PlanSynchronizing Development • Marketing • Planning
Why? Agile Development
needs to be coordinated with Design and Marketing
Visual Schedule shows dependencies
Diagram Fixits instead of Use Cases
Why? Much faster than
individual use cases
Easier and more efficient for developers to fix a set of issues on one page
Allows flexible prioritization (i.e. if you’re already fixing something on this page, fix these other things too)
