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.
