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.
