What Pathfinding is
Pathfinding is how a project starts at Animikii. Before anything is built, we spend a series of sessions with an Indigenous organization working out what they actually need, and whether building it is the right idea at all.
Often what they need is a community archive: somewhere to hold photographs, recordings, documents, and the stories attached to them.
It ends in a report the partner owns outright, and that ending shapes everything before it.
Where I come in
The sessions are collaborative, and most of what comes out of them on the design side is mine. I work out the roles, write the user stories, draw the flows and the site map, and build the prototype the partner clicks through at the end.
Working out the roles
Before it is a screen, a community archive is a question about access.
So that is where the sessions go first: how many kinds of user there are, and what each one is allowed to see. It sounds like a technical question and it isn’t. The answer is almost never the admin, editor, viewer hierarchy that software hands you by default.
Access can follow family. It can rest on consent given by one particular person. It can sit with Elders. Some material is open to a community and closed to everyone outside it, some is closed to nearly everyone, and the rule deciding which is not ours to invent. It belongs to the community, and the job is to find out what it already is.
Getting that right means asking questions in a session that software never asks, and then writing the answers down in a form someone can build from.
User stories
Once the roles are clear, the stories follow from them. I write most of them: what each kind of user needs to do, and what should happen when they try to do something they shouldn’t.
Written this way, a story carries the governance decision inside it. A requirements list would have recorded the feature and lost the reason.
Flows, site map, prototype
From the stories come the user flows, then the site map, then a prototype the partner can click through.
The prototype is not a deliverable at the end of a process. It is a decision artifact in the middle of one, because seeing a thing changes what people think they want, and it is far cheaper to find that out now.
The report
Everything lands in a Pathfinding report: the roles, the stories, the flows, the site map, the prototype. The partner owns it.
They may not build straight away. Budget tends to come later, and when it does they can bring the report to Animikii, or take it to another company entirely, or use it to raise the money in the first place. That is the point of handing it over rather than holding onto it.
Which changes what the work has to be. Design documentation usually goes to a team you can talk to, in a building you can walk into. This goes into a document that has to stand on its own, be legible to developers I will never meet, possibly years from now, and be persuasive to someone deciding whether to fund it at all.