The document discusses design patterns for product design. It explains that design patterns originate from Christopher Alexander's work and capture solutions to common design problems. The document then outlines the key components of the product design process, including understanding needs, agreeing with stakeholders, and providing direction. It describes discovery and design processes that involve user research, diagramming solutions, and developing models, views, and controls. The goal is to understand needs, get stakeholder agreement, and provide clear direction for developers.
How to Troubleshoot Apps for the Modern Connected Worker
BizSpark SF Lightning Talk: "Design Patterns for Designers" by Stephan Orme
1. Design2 Patterns
Design Patterns for Product Designers
Stephan Orme
stephan@worklogistics.com 510-847-8537
Document Version 0.85
Nov 7, 2011
2. 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
3. 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.
4. Scope of the Design Process
Client/
Design Process Used To:
Develop
User
ment
Understanding Needs
Needs and Priorities
Product
Development
Management Get Agreement from
Stakeholders
Direction for Developers
Graphic Direction for Designers
Design
5. Communicating Design Ideas
Many ways to communicate design ideas…
User Stories Workflows
Use Cases Pseudo Code
Wireframes Schedules/Timeline
Visual Design Budgets
Schema/Data Model Declarative Tasks
The result is an understanding of your Needs and
Context, you have Agreement from stakeholders
and a Plan or Direction.
7. 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
8. Discovery Process
How to Figure out what to Build
Method Problem Benefit
Think and Doodle Castles in the Original Designs
Sky
User Interviews / Faster Horses Learn Things,
Customer Development Build Support
Research Current Me Too Build on the
Solutions Shoulders of Giants
Research Technical Not good to tie Better Design /
Foundations design and tech? Smoother Implementation
Result: Needs • Context • Agreement • Process • Direction
10. 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
11. Types of Diagrams
Kinds of Information Audience
Wireframes Designers Developers Client
User Workflows Designers Developers Client
UI Notes Designers Developers
Site Structure Designers Developers
Data Model Developers
System Processes Developers
Pseudo Code /
Developers
SQL
12. The Basic Pieces
The 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
17. Data Model / Schema
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
Audiences Developers
18. Project Staffing / Budget
Why?
Understand
Project phases
and resource
needs over time
19. Calendar for Iteration Plan
Synchronizing Development • Marketing • Planning
Why?
Agile Development needs
to be coordinated with
Design and Marketing
Visual Schedule shows
dependencies
20. 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)