[Design] [Sum] Chandler System Target User Group

[Sheila Mooney]

Philippe,

I we have also received similar feedback from John T and Priscilla  
about giving the personas a bit more a human identity so I will work  
with Mimi and Priscilla on this.

Mapping back to the personas when we talk about features is a great  
idea. I think we need to map back to the usage scenarios as well. I  
did this a bit of this in the presentation last Thurs for the desktop  
specs. I have actually been thinking about adding some sections to  
the specs around the personas and usage scenarios we are targeting  
but just haven't gotten around to it yet :-).

Sheila


On Jul 25, 2006, at 11:52 PM, Philippe Bossut wrote:

> Hi,
>
> I think it's good we have personas defined for our 1.0 products. It  
> limits the scope of potential users. For each feature proposed, we  
> should be able to map to how it serves the various personas. A  
> couple of things to make the use of them more efficient:
> - Give a nickname to those personas: we did that in another place I  
> worked in and pretty soon everybody referred to "Brian", "Alice"  
> and other personas when discussion user scenarios. We are human  
> beings so it's easier to think about this with human being  
> attributes attached.
> - When proposing a new feature or feature change, refer to a  
> scenario that involves one of the identified personas
> - In specs, stress out which personas the spec/feature is primarily  
> serving
>
> Cheers,
> - Philippe
>
> Mimi Yin wrote:
>> Here is a summary of internal discussions we have been having in  
>> our efforts to narrow the scope of OSAF's projects by defining a  
>> Target User group.
>> *Some background:*
>> OSAF's 3 projects: Chandler, Scooby and Cosmo are being bundled  
>> into a single product/service effort called the Chandler System.
>>
>> + Chandler is now known as Chandler Desktop
>> + Scooby is now known as Scooby Web App
>> + Cosmo is still Cosmo Server
>>
>> These 3 projects will be designed to support each other and play  
>> well together in order to provide our target user group with a  
>> compete lightweight collaborative task management and calendaring  
>> solution.
>>
>> In the coming months, as we nail down specs for our product Beta,  
>> we will ground product decisions and features prioritizations on  
>> the target users defined here and their particular needs and usage  
>> scenarios.
>> A slightly different way to look at this exercise is that we are  
>> *defining our problem space*: *What is the Chandler System's value  
>> proposition?*
>>
>> This summary will be followed shortly by a list of usage scenarios  
>> and workflows derived from our user interviews.
>>
>> ===== (All the stuff below is from the previous write-up)
>>
>> *Target User Group for the Chandler System*
>> Supporting materials can be found here: http:// 
>> wiki.osafoundation.org/bin/view/Journal/OneDotZeroTargetUser,  
>> including:
>> + Spreadsheet summary of Persona research
>> + More detailed list of questions that the Target User exercise  
>> will help to answer
>> + Links to user interviews
>> *Assumptions*
>> 1. All USERS are NOT created EQUAL. Different people will use the  
>> same tool in different ways. In other words, even within a single  
>> domain (e.g. PIM for Knowledgeworkers) there are different classes  
>> of users (aka Personas) with different usage patterns. If we can  
>> all agree on that...
>>
>> 2. It is also true that we can tailor our design to target a  
>> particular kind of user with a particular set of usage patterns.
>>
>> 3. In order to do this, we need to identify:
>> + what these Personas are;
>> + how they do or don't interact with each other;
>> + how many of them there are in the world of knowledge workers;
>> + how heavily they use and depend on PIMs or hand-crafted PIM  
>> systems;
>> + how dissatisfied they are with existing options.
>>
>> *Why do we need Personas at all?*
>> So that we can be strategic about the functionality we develop and  
>> optimize development effort to capture the right keystone user.
>>
>> *What constitutes the right Keystone User?*
>> Someone who is likely to adopt Chandler.
>> Someone who will help attract other users to adopt Chandler and/or  
>> various parts of the Chandler eco-system.
>> *
>> *
>> More specifically:
>> + Someone who will use and rely on Chandler heavily + Someone who  
>> works intensely with a wide range of people such that they end up  
>> drawing others into the Chandler Ecosystem as well.
>> + Someone who is actively seeking a better solution to what they  
>> have today. (e.g. They have tried several solutions already. They  
>> find it hard to stick to one system for very long. They have  
>> trouble keeping their system up-to-date. They still keep track of  
>> somethings, just in their head.)
>>
>> =====
>> *Proposal for Personas*
>> *
>> *
>> *These do not describe people. Personas describe roles people take  
>> on in any collaborative working situation. A single person might  
>> take on different personas in different contexts: Work, Home,  
>> School, Book club, Chorus*
>> *
>> *
>> *For each Persona, the 5 axes we're interested in are:*
>> 1. *Depth versus Breadth* How deep into issues does this Persona  
>> need to dig in order to do their job? Conversely, how thinly does  
>> this Persona spread themselves?
>> 2. *Responsible for others versus Responsible for themselves* Does  
>> this Persona DO anything per se? Or are they mostly responsible  
>> for enabling others to DO?
>> 3. *Quality of Collaboration* Lightweight collaboration with  
>> dozens of people? Heavyweight collaboration with a few people? One- 
>> way collaboration? Bi-directional collaboration? Multi-lateral  
>> collaboration?
>> 4. *Amorphous versus Concrete *Does this Persona take on mostly  
>> Amorphous tasks? Or is their role more about executing well on  
>> previously defined Procedures.
>> 5. *Complexity in Scheduling* How demanding is this Persona's  
>> scheduling needs? Are they extremely busy? Do they meet regularly  
>> with other extremely people? Are they trying to coordinate lots of  
>> people all the time?
>>
>> *Hub (Primary Keystone User)*
>> + Responsible for driving multiple projects at the same time
>> + Conduit for *many - to - many *communications *within *a working  
>> group
>> + Works intensely with a relatively small group of people within a  
>> working group
>> + Facilitates discussions, airing of issues and conflicts and  
>> resolutions;
>> + As a result, lots of working meetings as well as 1-on-1s
>> + Needs to get enough into the weeds in order to root out problems  
>> and come up with viable solutions that address people's concerns;  
>> however
>> + Also needs to have a broad understanding of how all the pieces  
>> fit together in order to:
>> + Synthesize inputs from the group into summaries and proposals
>> + Typically found in organizations that are trying to innovate. As  
>> a result, more often than not, taking on tasks and projects that  
>> are not clearly defined which they have not done before.
>>
>> *Busy Body / Coordinator (Secondary Keystone User; Primarily a  
>> close collaborator of Keystone User)*
>> + Responsible for coordinating or doing multiple Projects at the  
>> same time
>> + Communication hub for *one* (Coordinator) - *to* - *many*  
>> (Coordinated) across many different working groups/organizations/ 
>> contexts
>> + Works casually with a wide range of people across many different  
>> groups/organizations/contexts
>> + Coordinates schedule-related issues (e.g. events, due dates,  
>> milestone dates etc)
>> + Doesn't necessarily have a lot of meetings, but needs to keep  
>> track of event dates and Project dates: due dates, milestone dates
>> + For Projects they coordinate, they don't need to have deep  
>> understanding of the pieces they're coordinating
>> + For personal projects, they generally have pretty deep domain- 
>> specific knowledge
>> + Synthesizes inputs from various unrelated sources into summaries  
>> and perspectives
>> + Primarily takes on Projects they have done before. More often  
>> than not, takes on tasks/Projects that are well-defined.
>>
>> *Apex (Secondary Keystone User; Primarily a consumer of Hub  
>> Keystone User's organizational efforts using Chandler)*
>> + Responsible for the ultimate success of an organization or  
>> several organizations
>> + Advisor to many more organizations
>> + Juggling dozens of personal projects across many different  
>> organizations/contexts at any given time
>> + Packed schedule: lots of back to back meetings, + Lots of 1-on-1  
>> meetings with people
>> + Scheduling time is a complex exercise in setting priorities
>> + Does not get deep into most projects + Depends heavily on a  
>> small group of trusted people to keep abreast of Project details
>> + Always doing new things: building new relationships, starting  
>> new ventures, looking for ways to innovate. As a result, more  
>> often than not, takes on tasks/projects that are not well-defined.
>>
>> *Assistant (Secondary Keystone User)*
>> + Responsible for the execution of Apex's logistical projects
>> + Often acts as a Proxy for the Apex when scheduling meetings and  
>> coordinating across many groups, organizations and contexts
>> + Communicates with and coordinates a wide range of people across  
>> many groups, organizations and contexts
>> + Coordinates multiple projects at once across many groups,  
>> organizations and contexts
>> + Doesn't necessarily have a lot of their own meetings, but keeps  
>> track of event dates and project dates: due dates, milestone dates
>> + Manages Apex's schedule
>> + Works intensely with Apex, in constant communication
>> + Primarily on the receiving end of task requests and reviews and  
>> on the giving end of status updates and progress reports
>>
>> *Individual Contributor (Drive-by user being Facilitated/ 
>> Coordinated by Keystone User)*
>> + Responsible for execution of a narrowly defined area within a  
>> Project
>> + May collaborate intensely with others within the working group,  
>> however, is not responsible for driving or facilitating that  
>> collaboration
>> + Meets with manager weekly
>> + Gets roped into meetings that have to do with their narrowly  
>> defined Project area
>> + Does not do a lot of intensive task and information management
>> + Feels like the combination of their email client + memory is  
>> pretty good
>> + Depends on manager or Project hubs/coordinators to keep track of  
>> their tasks/meetings via email, in person or an instituted task/ 
>> Project management system (e.g. MS Project, bugzilla, etc)
>> + Gets very deep into their domain and maintains sole ownership of  
>> their area
>> + Does not necessarily keep abreast of what's happening across the  
>> working group/Project
>>
>> *Hangers-on/Passersby (Drive-by user)*
>> + Could be any of these Personas, but in a separate context; in  
>> other words
>> + Is not a part of the Keystone User's working group; as a result
>> + Uses a different system of suite of tools to collaborate with  
>> their own working group; however
>> + Interacts with the Keystone User and as a result, comes into  
>> contact with the Chandler Ecosystem via Scooby and Cosmo
>>
>> =====
>> *Why are these the right Personas?*
>> We started out with the idea that we would target knowledge  
>> workers who worked in the context of small work groups (3-30 people).
>> + Someone who not only consumes a large amount of information; but  
>> also
>> + Someone who processes, deconstructs and synthesizes that  
>> information to produce more information.
>> For more, see:
>>
>> We interviewed 2 dozen users (most of whom were not OSAF  
>> employees), either individually or in groups. As a result of the  
>> interviews, we recognized some usage patterns that corresponded  
>> nicely with the different roles people played in particular  
>> contexts (e.g. work, book club, home).
>>
>> Based on interviews and other people's user research, we  
>> identified some basic "symptoms" of knowledge workers and  
>> summarized how each symptom manifests itself differently in each  
>> Persona.
>>
>> *You know you're a knowledge worker if:*
>> + You currently maintain task lists (spreadsheets, pda, paper)
>> + You currently maintain calendar(s) (digital, pda or paper)
>> + You go broad across a lot of projects, but you don't lack depth  
>> either
>> + You are responsible for coordinating and/or driving multiple  
>> projects at the same time
>> + You consistently tackle amorphous, black box tasks that have  
>> never been done before
>>
>> *Knowledge workers that are likely to adopt Chandler in the Beta  
>> and 1.0 timeframe*
>> + Relatively deskbound (due to lack of solution for pda sync)
>> + Works within a small working group: 3-30 people (due to  
>> scalability issues and not wanting to compete with entrenched  
>> enterprise systems)
>> + Geeks
>> + People into Open Source software
>>
>> =====
>> *What is Chandler going to do / not going to do for each of these  
>> Personas?*
>> *
>> *
>> *Keystone Users: Rich desktop experience*
>> *Drive-by Users: Web access to participate in collaboration  
>> workflows, without having to adopt a big heavy desktop client.*
>> *
>> *
>> *Hub*
>> Do
>> + *Triage/GTD:* A better framework for iterating on and keeping  
>> track of amorphous tasks and projects progressing in parallel.
>> + *Clusters: *A better framework for deconstructing amorphous,  
>> black-box projects.
>> + *Faceted Sidebar: *A better way of keeping Runway reality in  
>> sync with Project planning.
>> + *Sharing and Stamping Storyboards:* Provides increased  
>> transparency to facilitate group collaboration. A better way to  
>> keep track of the Group's tasks. A better way to FOCUS the Group's  
>> attention, to Prioritize what the Group's works on. A better way  
>> to collaborate with Busy Body helpers.
>> *
>> *
>> Not-do
>> + High-level Project planning (e.g. Stickie planning)
>> *
>> *
>> *Busy Body / Coordinator*
>> Do
>> + *Triage/GTD:* A better framework for iterating on and keeping  
>> track of projects progressing in parallel.
>> + *Faceted Sidebar: *A better way of keeping Runway reality in  
>> sync with Project planning.
>> + *Sharing and Lightweight Notifications:* Provides increased  
>> transparency to facilitate project and group coordination.
>>
>> Not-do
>> + First class, explicit support for delegation of Tasks and  
>> Scheduling
>> + First class support for making crowded calendars really readable
>> a. Callouts;
>> b. Fish-eye views
>> + Funky, custom calendar views for doing complex scheduling;
>> a. overlaying calendars with different timezones;
>> b. non-linear calendar views (e.g. March 24, April 30, Jan 6)
>> *
>> *
>> *Apex*
>> Do
>> + *Triage/GTD: *A better framework for iterating on and keeping  
>> track of amorphous tasks and projects progressing in parallel.
>> + *Clusters:* A better framework for deconstructing amorphous,  
>> black-box projects.
>> + *Sharing and Stamping Storyboards:*
>> a. A better way to delegate and provide input on delegated Tasks
>> b. A better way to keep close track of progress on Tasks delegated  
>> to their Assistant and Direct Reports.
>> c. A better way to collaborate with Assistant on scheduling and  
>> coordinating logistics
>>
>> Not-do
>> + First class support for making crowded calendars really readable.
>> a. Callouts;
>> b. Fish-eye views
>> + Ability to automatically extract a high-level summary from  
>> shared collections. e.g. Graphical views of data:
>> a. Stickie plan;
>> b. Visualization/Summary of discussion threads
>> *
>> *
>> *Assistant
>> *
>> Do
>> + *Triage/GTD: *A better framework for iterating on and keeping  
>> track of projects progressing in parallel.
>> + *Faceted Sidebar:* A better way of keeping Runway reality in  
>> sync with Project planning.
>> + *Sharing and Stamping Storyboards:*
>> a. A better way to keep the Apex abreast of progress on tasks and  
>> progress;
>> b. A better way to both receive task requests and to ask for input  
>> and review;
>> c. A better way to collaborate with Apex on scheduling and  
>> coordinating logistics
>> *
>> *
>> Not-do
>> + First class, explicit support for delegation of Tasks and  
>> Scheduling
>> + First class support for making crowded calendars really  
>> readable, e.g.
>> a. Callouts;
>> b. Fish-eye views
>> c. Allowing users to define what attributes display in the event  
>> lozenges
>> + Funky, custom calendar views for doing complex scheduling, e.g.:
>> a. Overlaying calendars with different timezones;
>> b. non-linear calendar views (e.g. March 24, April 30, Jan 6)
>> *
>> *
>> *Individual Contributor*
>> Do
>> + *Sharing*: A better way to keep the Hub updated on status and to  
>> bring issues to the Hub's attention.
>> + *Sharing + Triage/GTD:* A better way to stay abreast of group  
>> priorities what's happening elsewhere in the group.
>> *
>> *
>> Not-do
>> + Replace their
>> a. Email Client;
>> b. RSS Reader;
>> c. Institutional Project and Task Tracker with a single,  
>> integrated information management solution.
>> *
>> *
>> *Hangers-on and Passers-by*
>> Do
>> + Make it easy for Chandler users to work with 'Outside- of-the- 
>> Working-Group' individuals, without having to 'switch' tools.  
>> Instead the experience of coordinating 'Inside-of-the-Working- 
>> Group' people with 'Outside-of-the-Working-Group' people is  
>> integrated into a single workflow, thereby increasing the odds  
>> that the Keystone User will actually stick with the Chandler System.
>> *
>> *
>> Not-do
>> Make it possible for 'Outside-of-the-Working-Group' people  
>> collaborate at the same level as people 'Inside-of-the-Working- 
>> Group' as Hubs, Coordinators, Apexes or Assistants.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design