Meta-life-ing

weeknotes

Jan 23

Where do I start? Work was spread thin between UX, service design and research this week. Since kicking off our new workstream (as a gateway to other services), my brain has mostly been occupied with wrapping itself around workshop findings and translating them into giant blueprints (currently at V3 and going).

What's up?

Final iterations to a mock up of an internal service (before they enter sandbox, the mockups aren't actually being tested past the first round of UR)
Observed a really positive external UR session (ft my GDS dilemma from last week)
Got my hands dirty with some serious service design, observing and capturing workshop drama
Putting systems thinking in practice, in determining and scaling user types
Learning to harness metadata to organise my note files (aka Personal Knowledge System)

Service brain-printing

With UR taking up most of the week, I've been supporting our service design lead in developing the initial blueprint for our new service (name, TBC). As 1 of 421 government agencies, like many of our public counterparts, people come to us for a suite of things to do, and these things take time to get done (years), during which relationships are fostered, requiring sub-service tasks like providing information, filling out applications, submitting requests, getting approvals, etc.

There are about 10-15 types of services that people depend on us for, and as far as research stands, most of our users (>90%) know exactly what they need from us. For this majority of external users, we've scaled them by:

Knowledge: whether they know who we are, our existence
Intervention: whether they've previously interacted with us
Experience: whether they've used our service (or are still using) in the past

As for the <10% minority, we've assumed that they have none of the above. How they scale will present different ways of best entry: i.e. some requiring more effort to enter, but less time to wait.

Experienced and knowledgeable users are the tricky part. The idea of this new service is 'one-gateway-to-serve-all', leaving little chance for service shortcuts, in case we decide to change how we intervene with them (ambiguous, but it does happen). As far as the blueprint has taken us (in all onion shapes and forms), most of our time has been spent on relationship logic and identifying patterns, themes, threads. And honestly the more time, the better.

Knowledge overhaul in progress

I've been reading a lot on Second Brains and Personal Knowledge Management lately, to which I've started implementing on my Obsidian. As someone that's always resonated as thinker of systems — it usually starts with a garden of seemingly unrelated ideas — but after 25 years of thinking, I'm deciding no more. I have a lot to experiment, but here's what I've found that's working for me so far:

Organising folders in a PARA structure (i.e. Projects, Areas, Resources, Archive)
- Advantage: flexibility of moving around, findability by priority (I have a lot of thoughts on folders here)
- Disadvantage: a messy archive
Hierarchical tagging via categories, types and status (i.e. # life/career, # personal/list, # list/draft )
- Advantage: categories are flexible, and I can relate the same note to multiple categories (i.e. a list of roles I want to apply for can be tagged against all of the above)
- Disadvantage: requires a lot of passive intuition that I can already predict as a pain to manage in the future
Ontological linking via relationships (i.e. parent, child, sibling, cousin)
- Advantage (gamechanger): instead of isolated links, I’m now able to apply context to different relationships, like
  - ‘Masters’ = parent of ‘Thesis’ and ‘Assignments’, and therefore…
  - ‘Thesis’ and ‘Assignments’ = siblings
  - ‘Masters’ and ‘Bachelors’ = cousins
- Disadvantage: still fleshing out my context (is a cousin a friend, or a friend a cousin?!)