OSCON 2007: Open Design, Not By Committee

OSCON 2007: Open Design, Not By Committee

• 1.
  Open Design, Notby Committee Chandler Project Mimi Yin, UI Designer Ted Leung, Community / Engineering Manager Thursday, August 27, 2009
• 2.
  Agenda - What do we mean by Open Design? What do we mean by Not by Committee? - Brief history of design at OSAF - What we think we want to get out of Open Design. - Challenges to doing Open Design. - What we’ve learned. - Examples of what’s worked and what hasn’t worked and our personal theories about why. - Next steps. More questions and more challenges. Thursday, August 27, 2009
• 3.
  The Abridged Historyof Design at OSAF 0 2001-3 Mitch founds OSAF and the Chandler Project Open season on the design list. Design list was flooded with ideas. Often, it was hard to even understand what they were. Not much was done with ideas. 1 2003-4 Closed, 3x a week design sessions with Mitch, Product Mgr, UI Designer, and a Data Model Engineer 2 2004-5 Show and Tell 3.1 2005-Present Surveys and decision-making on the list 3.2 2005-Present Engaging with users 4 2006-Present Getting into the weeds 5.1 2006-Present Facilitating developer-driven design 5.2 Present Moderated collaboration Thursday, August 27, 2009
• 4.
  Our Goals, thusfar… - What we hope to gain… - What we don’t want to lose… - Brainstorming: More brains, more ideas. - End-user focus: How do we avoid - Validation: More people, more use simply listening to the loudest cases, more perspectives. person on the list. - Quality assurance: Everybody’s a - Coherence tester. - Speed in making decisions and - Feedback: Get users involved in iterating on designs. giving us feedback. - Community: More engagement, more usage! Thursday, August 27, 2009
• 5.
  The more themerrier? Not exactly… Feedback, input and ideas are fed through a moderated design process to ensure that we get the best of collaboration and avoid the pitfalls of design by committee. - Consensus is not needed to make decisions. Agreement is desired, but when disagreement persists, the decision driver is there to make the call. - Voting is used as a gauge, a way to collect input; not as a way to make decisions. - Ideas aren’t simply accepted wholesale. The are fodder, to be fed through the design process. Feature ideas are always taken back to motivating use cases. Thursday, August 27, 2009
• 6.
  Developers versus? Designers 1. Organized around functionality 1. Organized around workflows and scenarios 2. Simple to understand how it works 2. Simple to use given your daily needs 3. Consistent in terms of technical semantics 3. Consistent in terms of human semantics 4. Let people design their own way of doing things 4. Not everybody wants to build their own system 5. Used to clearly defined domains 5. Hard to modularize. Can’t run a functional test on design proposal Thursday, August 27, 2009
• 7.
  What’s so especiallyhard about Open Design? - You can modularize code, but splitting design into neat little compartments essentially impossible. It’s not about coming up with a clean API. There are no functional tests to make sure designs flow together. The functional test equivalent for design is usage, by a human…And ‘coherent’ to a human brain is less flexible and harder to define than ‘coherent’ in code. - Examples of hard problem areas: Terminology, visual syntax, visual treatment, not to mention information modeling, workflow, and interaction schemes. Basically, design is hard to compartmentalize at every level. Thursday, August 27, 2009
• 8.
  What worked, whatdidn’t work: Open Design is a lot like Open Development - Set clear goals and expectations for open design. - What kind of contributions are we looking for. - What’s helpful, what’s not helpful. - How will your contributions be evaluated, process, worked into the product… Contributing design means starting a relationship with OSAF, not a making a drive-by delivery. - Extract goals and requirements from discussions rather than fixating on the pros and cons of specific proposals. - Having a clear driver / final decision-maker. - Clearly differentiate between facilitation and opinion. Thursday, August 27, 2009
• 9.
  What worked, whatdidn’t work: How Open Design is different from Open Development • Clearly differentiate between facilitation and opinion. • Define your Design Process. Get buy-in. It's not that everybody needs to think about things the same way or go through the same...but there needs to be agreement on things like: - The importance of defining target users and what you mean by target user. - Standards and process by which you evaluate designs? Heuristics, workflow analysis, tying features back to use cases. - Do we all agree on what a 'use case' is? Create new message is not a use case. - Do we have a shared understanding of what it means to 'Keep it simple.' Thursday, August 27, 2009
• 10.
  Example 1: Whatwent right with Auto-triage in the Dashboard? 1. Development / Design mind-meld 2. Choosing the right medium of communication 3. Persistence 4. Open-ness to iteration Thursday, August 27, 2009
• 11.
  Demo: Auto-Triage inthe Dashboard Thursday, August 27, 2009
• 12.
  Example 2: Whatwent wrong with the Faceted Sidebar? 1. Not on the same page with respect to design approach 2. Confusion between development model and end-user mental model 3. Lack of clarity in process: Whoʼs driving? Who are the stakeholders? How do we resolve disagreements? Thursday, August 27, 2009
• 13.
  Demo: Faceted Sidebar Thursday,August 27, 2009
• 14.
  Example 3: Workingwith the Community • Dogfood Feedback: Andre’s Assorted Usage Notes http://lists.osafoundation.org/ pipermail/chandler-users/2007-June/000323.html • Surveys: Sidebar taxonomy, Calendar size, Tagline - Surveys are more qualitative than quantitative - Feedback on designs ask targeted questions. We never simply ask: So, what do you think of the design? Questions we ask when we get feature requests or design recommendations… - What were trying to do when you… - How often do you… - Were you able to figure out… Thursday, August 27, 2009
• 15.
  Questions and Challenges… - What do we mean by open design? (See slide #2) - What kind of a design community do we want to have? - What is the design equivalent of a committer? - What are the different levels of engagement for design contributors? - How do we make it easy for people to learn our design process? - How do we loop developers into our design process? Code contributors need to buy into our design process too. Thursday, August 27, 2009
• 16.
  Next steps: Cultivatinga community through open design. • Establish a firm foundation in design - Clear end-user information model - Clear target users and target scenarios - Clear design approach - Visual syntax, interaction heuristics • Build a ramp to engage contributors in design - Use the app. Provide feedback. Respond to surveys. - Log bugs. Fix bugs. - Participate in use case brainstorming. - Take on spec’d out designs. - Sketch out workflows. • Create room for experimentation. Design Sandbox. - Build a parcel - Iterate on design Thursday, August 27, 2009