Who is the audience for time?

[iteles]

who is the audience for time? We need to define who hypothesise this will be at MVP and first launch as well as longer term.

[nelsonic]

@iteles great question thanks for opening the discussion. 💬
(we have previously discussed this verbally but not captured it on GitHub for reason.some()...)

Time is for "people who need an effortless way of keeping track of the activities/tasks in their lives".
That may sound like a "vague" answer (on the surface)
hopefully it's more of a "guide" so that we don't make the focus too narrow
given that we think that timing things is quite general purpose.

Our initial user is us i.e. people working @dwyl.
We need an accurate but low-friction way of timing our work
so we can communicate with our team members and stakeholders.
Right now we are estimating our stories/issues but most people are not tracking how long they spend on each task because it's tedious.

The problem we need to solve is:
How long is this creative/coding project going to take?
Can each feature be estimated (with reasonable confidence)
so that the product owner/client can know when to expect delivery?
are people tracking the time they spend so everyone in the team is looped in
(without a "PM" having/needing to ask "what's the status of YXZ feature...?")

We don't think any of the exiting Timer Tracking or Task/Project tools
give the product/project owner a clear picture so they can plan and respond to specific overruns;
this is why the IT industry is notoriously bad at delivering "on time/budget".

See: https://www.google.co.uk/#q=nhs+it+project+over+budget

Everyone suffers from "Optimism Bias" https://en.wikipedia.org/wiki/Planning_fallacy
We need to get better at estimating our tasks/activities and the only way to do that is to have a "feedback loop" for the work we do:
Describe |> Estimate |> Prioritise |> Measure the Work (Time) |> Learn (if our estimates were good)

[nelsonic]

Focus on a small niche then expand from there. https://youtu.be/egJeFaIXZLo

[Cleop]

@nelsonic

• Do you think we should build some user personas to bring life to this audience?
• Have we / do we want to conduct any user research into what our most important feature is to build first? How people work etc.?

[nelsonic]

@Cleop absolutely we need Personas. (we can drop the "User" from "User Personas" it's implied)
Please open the Personas Issue as per #212 (comment) and add as much relevant detail as you feel is warranted to help both our "core" team and the wider community understand the people using the App.

We are conducting our own UX Research in dwyl/product-ux-research#34 and we will be analysing all the existing Time Tracking apps before doing any further qualitative research.
As soon as we have our MVP https://github.com/nelsonic/time-mvp
ported to Phoenix dwyl/mvp#1 (using CIDs and the "Append-only Stack" ...)
we will need to dive into both dwyl/learn-wireframing#1 and dwyl/learn-user-experience-testing#2

[Cleop]

From dwyl/hq#212

users "dwylers" are "people who want to proactively track their time/progress on important tasks so that they can (a) stay focussed on their highest priority, (b) see where their time is being spent and (c) never be "stuck" for what work on next."

[iteles]

Superseded by dwyl/hq#213