• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
A Developers Take on Cooper
 

A Developers Take on Cooper

on

  • 315 views

I recently attended the Interaction Design training at Cooper (http://www.cooper.com/#training:interaction_design). ...

I recently attended the Interaction Design training at Cooper (http://www.cooper.com/#training:interaction_design).

This presentation is a brief overview of the training and Cooper process from the perspective of a software developer.

Statistics

Views

Total Views
315
Views on SlideShare
314
Embed Views
1

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 1

http://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    A Developers Take on Cooper A Developers Take on Cooper Presentation Transcript

    • A Developers Take on Cooper Adam Jordens @ajordens
    • My Background Technical Lead GenoLogics Life Sciences Founder AppiityTypically work with teams of It has been rare to have a3 or 4 Developers, a QA dedicated design resource onrepresentative, and a Product the teams Ive been a part of.Manager. Oh yeah, I cant draw.
    • ● In software, features cost almost nothing. ● In hardware, features almost always increase costs. FEATURE-ITISMost people developing software products dont know preciselywhat constitutes a good product, or the processes that canhelp get them there. "Goal Directed Design"
    • Goal Directed DesignDesign first; As developers, we prideprogram second ourselves on an ability to deliver against all odds.Think about what should be Often, to our own detrimentbuilt before starting to build and the detriment of ourit. product. Lean thinking is relativelyGoals are stable and persist new to product teams.across time.Contexts, tasks, needs andtools change over time.
    • Goal Directed DesignWhen was the last time you Separate responsibility forread the persona involved in design from responsibilityyour feature? for programmingDo you understand theunderlying goal or scenario Optimal designs are notyour feature is addressing? necessarily easy to implement.Scenarios provide the gluebetween user stories and arecritically important. Programmers want the product to be easy to code, designers desire to make the product easy to use.
    • Goal Directed DesignHold designers responsible Thinking Pointfor product quality anduser satisfaction Who is responsible for product quality and user satisfaction right now?Designers need to have thenecessary authority foreverything coming in contactwith the user.The design spec is not Including any installers,merely a suggestion but a documentation, etc.plan to be followed.
    • Goal Directed DesignUntil a persona is defined, a Define one specific user fordeveloper will think of your product; then invent athemselves as the user. persona - give that user a name and an environment and derive his or her goals Avoid talking about specific users, talk about their persona and goals. Powerful design tool, foundation for everything.Tasks are transient. Goal != Task
    • Goal Directed DesignWork in teams of two: Were already doing it, this isdesigner and design just a formalization of it withcommunicator outcomes (design spec).Generators and Synthesizersin Cooper terminology.Improves product quality and Developers often arent thedesign documentation. best at coming up with ad hoc designs.
    • Goal Directed DesignResearch ● Understanding business and user needsModelling ● Share with the entire product teamRequirements Definition ● Decide what the product should doFramework Definition ● Come up with a good conceptDetailed Design ● Design it in detail and make sure it is feasibleImplementation Support ● Ensure that the design is built as expected
    • Goal Directed DesignResearch Modelling & RequirementsObservation, Interviews and Personas, Scenarios, UsageCreative Exercises Patterns, Work Environments ● Stakeholders Scenarios are the glue ● Customers between user ● End users stories, everyone needs to ● Subject matter experts read and understand them. ● Competitors Extract personas from actual research.Not everyone is a stakeholder. Personas should have goals.
    • Goal Directed DesignFramework Definition Detailed DesignDefine the big picture; mast Iterate at greater and greaterheads, nav bars, content detail, screen by screen.areas, etc.Dont sweat little details, Collaborate with developers,widgets, field names, data. figure out the limitations.Scenarios provide guidance. Create challenging designs.Avoid painting the walls Optimize for intermediates:before creating a blue print. no one stays a beginner. "Key Interactions"
    • Goal Directed DesignImplementation Support Done Done Done: Both visually and functionally.The design doesnt stopwhen its been passed to thedevelopment team.Designers need to ensurethat the finished productsatisfies the original intent.Work with developers toensure consistencythroughoutthe entire application.
    • Takeaways ● Create / update our Cooper is a formalized personas process covering everything upstream of development. ● Establish written scenarios It eases communication ● Ecosystem and Workflow amongst remote teams. maps Involve others to break a ● 15 minute rule stalemate.20min * 3 shots better than 60m * 1 shot All too often we build designs ● Design in pairs (at least) and define interactions ourselves.