BizSpark SF Lightning Talk: "Design Patterns for Designers" by Stephan Orme

400 views
326 views

Published on

Presentation from November 2011 BizSparkSF Meetup entitled "Tools, Tools and More Tools!" http://www.bizsparksf.com/events/34653282/

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
400
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

BizSpark SF Lightning Talk: "Design Patterns for Designers" by Stephan Orme

  1. 1. Design2 PatternsDesign Patterns for Product Designers Stephan Orme stephan@worklogistics.com
510-847-8537 Document Version 0.85 Nov 7, 2011
  2. 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. 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. 4. Scope of the Design ProcessClient/  Design Process Used To: Develop User ment  Understanding NeedsNeeds and Priorities Product Development Management  Get Agreement from Stakeholders  Direction for Developers Graphic  Direction for Designers Design
  5. 5. Communicating Design IdeasMany ways to communicate design ideas… User Stories  Workflows Use Cases  Pseudo Code Wireframes  Schedules/Timeline Visual Design  Budgets Schema/Data Model  Declarative TasksThe result is an understanding of your Needs andContext, you have Agreement from stakeholdersand a Plan or Direction.
  6. 6. Figuring it all outDISCOVERY
  7. 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. 8. Discovery Process How to Figure out what to BuildMethod Problem BenefitThink and Doodle Castles in the Original Designs SkyUser Interviews / Faster Horses Learn Things,Customer Development Build SupportResearch Current Me Too Build on theSolutions Shoulders of GiantsResearch Technical Not good to tie Better Design /Foundations design and tech? Smoother ImplementationResult: Needs • Context • Agreement • Process • Direction
  9. 9. Coming up with a SolutionDESIGN PROCESS
  10. 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. 11. Types of DiagramsKinds of Information AudienceWireframes Designers Developers ClientUser Workflows Designers Developers ClientUI Notes Designers DevelopersSite Structure Designers DevelopersData Model DevelopersSystem Processes DevelopersPseudo Code / DevelopersSQL
  12. 12. 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 ProcessesBut to Implement the product you also needAgreement • Processes • Direction
  13. 13. WireframesAudiences Designers Developers Client
  14. 14. Site StructureAudiences Designers Developers Client
  15. 15. WorkflowsAudiences Designers Developers Client
  16. 16. UI Behavior Audiences Designers Developers
  17. 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. 18. Project Staffing / Budget Why?  Understand Project phases and resource needs over time
  19. 19. Calendar for Iteration PlanSynchronizing Development • Marketing • Planning Why?  Agile Development needs to be coordinated with Design and Marketing  Visual Schedule shows dependencies
  20. 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. 21. Worklogistics.ComOffshore / Onshore Solutions Analysis • Design • BuildStephan@Worklogistics.com

×