You can start some things straight away, but when there are multiple things you could do, prioritising and working out what the things are is crucial to avoid too much context switching. For those of us used to agile, PIDs (Product Initiation Documents) feel like things from the "waterfall past", but I think they're still relevant if they're made to reflect user needs that is at the core of any agile methodology.

I've spent some time this week thinking about how to do this. In some ways, it feels like a luxury to start by developing a document format, but it feels foundational and worth the effort to get a format that captures the right information.

I started with some desk research, looking at a lot of different existing templates for things to reuse. The format I liked the best came from this blog post by Robert Drury. It has the right level of detail, not too little, not too much. However, I felt it didn't really include much information about the users and their needs. So I looked at how we used to frame some of this in the work I did in the charity sector with CAST.

Problem statements

The first tool that I love to use is a problem statement. These are framed from the perspective of a user and really help to understand what is trying to be solved/fixed/improved.

When {who are the people affected}
Are {what is the situation}
Then {what problem arises}
This means {what are the effects of the problem}

For example:

When people or tools
Are trying to compare two MHC structures from species/loci with insertions/deletions
Then they cannot easily see which residue number is comparable
This means that comparison is hard, or scripts/tools are brittle

This is quite a clumsy example in some ways, but it serves to show the problem reasonably well.

Knowledgeboards

Knowledgeboards are a great way of both organising information and thinking through what is known and what needs to be researched. There are three categories in a knowledgeboard:

What we know Things you know for certain, and why

What we think we know Things you need more evidence for

What we don’t know Things you need to find out

The aim of all user research is to move things from uncertainty to certainty. Only things which have evidence should be in "what we know", ideally with a link to that evidence.

Quadrants

Since working with Matt McAlister, I've always loved using quadrant charts to look at problems. I sketched out how you might map the risks of a project on a quadrant and it works nicely I think.

Testing the prototype template

Finally, since it's always good to "design with data", I filled in a couple of PIDs for potential projects/tasks/features to see how it worked and then made a few tweaks to the template where I felt information didn't have a home or was in the wrong place.

Now to write more PIDs and to look at which things make the most sense to do first, thinking both about user needs and other things which depend upon them.

p.s. once I feel confident with the template, I'll share it