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.

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.

6. Figuring it all out
DISCOVERY

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

9. Coming up with a Solution
DESIGN PROCESS

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

13. Wireframes
Audiences Designers Developers Client

14. Site Structure
Audiences Designers Developers Client

15. Workflows
Audiences Designers Developers Client

16. UI Behavior
Audiences Designers Developers

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)

21. Worklogistics.Com
Offshore / Onshore Solutions
Analysis • Design • Build
Stephan@Worklogistics.com