[Design] [Sum] Chandler System Target User Group

[Mimi Yin]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060626/56fc9467/attachment.html