Skip to content

Designing the Human Signal Layer #242

@mouxdesign

Description

@mouxdesign

> "The capability of the system is only as good as the quality of the customer signal feeding it." - Quote from blog post

The future company is described as a "company built as an intelligence" a mini-AGI. Much has been spoken about the two layers that make this work: the intelligence layer and the world model. What I propose is the layer underneath both of those, the human signal layer.

Having worked in the Bitcoin ecosystem for the past few years I see the accumulation of data as a gap in the ecosystem of open source Bitcoin wallets. It is also a gap in the Nostr ecosystem, there is no central database collecting data and putting humans first.

What I imagine is an intelligent system that collects data which the team can then query, so that users guide the product decisions even more. This is what is referred to as "customer reality generating the backlog directly." - quote from blog post

Input sources

We essentially have 2 input sources:

Internal

  • User interviews
  • Customer support tickets
  • User data such as drop-off points

External

  • GitHub issues filed by users on open source repos (only relevant to open source wallets)
  • App store reviews
  • Reddit conversations about the product

The model will receive this data and sort it. Since my experience is primarily in researching Bitcoin and Lightning wallets I am proposing the structure based on that however the framework can be applied to any product.


Step 0: Quality of data

The queryable data structure is only as smart as its input. Before any signal enters the system we need to ensure:

  1. Input sources follow a specific methodology when collected. User testing toolkits and resources are built into the system. Here is an example of a UX research toolkit we built for the Bitcoin open source ecosystem.
  2. Data sources can be ranked by the team. Some sources may be deemed higher quality and weighted accordingly. Or the team can decide all data is treated equally.

Step 1: Inputs are labelled

At its most fundamental level every source input is one of two things:

  1. Positive
  2. Negative

Step 2: Map to journey stage

After labelling, each signal is mapped to which part of the user journey it belongs to. Importantly we also want to capture why users fall off even before they start using the product.

  1. Fall off: before first use
  2. First use: pushes and pulls under the Jobs to be Done framework
  3. Onboarding
  4. Sending bitcoin
  5. Receiving bitcoin
  6. Backup and recovery

Step 3: Summary view

Positive and negative signals are split across each journey stage, giving a summary under each heading.

Example:

Fall off: "According to a summary of public and internal data, users are failing to use the app due to xyz."

First use: "Over the last 6 months we have had x positive sentiments about the onboarding flow."

This continues across all stages: onboarding, sending, receiving, backup and recovery.


Step 4: Historical query

The product team can look at this data historically by chatting to Sprout directly:

  • "Over the last 3 months how many times was this feature requested?"
  • "What are the common patterns we are seeing in the onboarding flow?"
  • "What are the main reasons users are choosing to stay with us?" ,push signals under the Jobs to be Done framework
  • "How is public sentiment trending over the last 6 months?"

Image

Related project: Between Us

I am currently working on a project collecting stories of why people use Bitcoin and why people use AI, this is already kicked off and running through 2026. These stories, once the project is further along, can neatly fit into this AI brain as a rich source of human signal from real people around the world.


I would love to open this as a discussion here on the Sprout repo and hear the team's thoughts. I am also part of the Bitcoin Design Community, feel free to reach out if you would like to jam further on this. More than happy to contribute!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions