[Design] [Sum] Chandler System Target User Group

[Sheila Mooney]

Just to correct myself, I have the wrong terminology here. I should  
have said usage patterns.

And excuse the grammatical errors, I am clearly up too late :-).

On Jul 26, 2006, at 12:03 AM, Sheila Mooney wrote:

> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design