Solution

• Please note that for a more extendable version we would use a completely different database design. Most of the freetext columns would be extracted and normalized into its own table.

Schema

// the SaaS customer
Table tenant {
  id integer [primary key, not null, unique]
  // in this case we are using guids as public IDs as this is a multi-tenancy application
  guid uuid [primary key, not null, unique]
  name char(128) [not null]
}

// a project inside a customer's environment
Table project {
  id integer [primary key, not null, unique]
  // in this case we are using guids as public IDs as this is a multi-tenancy application
  guid uuid [primary key, not null, unique]
  name char(128) [not null]
  tenant_id integer [not null, ref: > tenant.id]
}

// a project has one business canvas
Table business_canvas {
  id integer [primary key, not null, unique]
  // no need for guid as the business canvas can not be directly edited as it is tied to the project
  problems_needs text [null]
  existing_solutions text [null]
  users text [null]
  early_adopters text [null]
  user_fears text [null]
  user_goals text [null]
  solution text [null]
  value_proposition text [null]
  acquisition_channels text [null]
  revenue_sources text [null]
  metrics text [null]
  project_id integer [not null, ref: > project.id]
}

// a project has multiple personas
Table persona {
  id integer [primary key, not null, unique]
  guid uuid [primary key, not null, unique]
  name char(255) [not null]
  age integer [not null]
  job_title char(255) [not null]
  location char(255) [not null]
  // let's use json for storing metadata. In this context it is probably not so important to find similarities over different personas which would justify dedicated tables for brands and tags
  tags json [not null]
  favorite_brands json [not null]
  about text [not null]
  goal text [not null]
  pain_points text [not null]
  needs text [not null]
  // we keep the scaling easy
  personality_introvert_extrovert integer [not null]
  personality_analytical_creative integer [not null]
  personality_busy_time_rich integer [not null]
  personality_messy_organized integer [not null]
  personality_independent_team_player integer [not null]
  project_id integer [not null, ref: > project.id]
}

Table user_story_category {
  id integer [primary key, not null, unique]
  guid uuid [primary key, not null, unique]
  name char(255) [not null]
  project_id integer [not null, ref: > project.id]
}

Table user_story_role {
  id integer [primary key, not null, unique]
  guid uuid [primary key, not null, unique]
  name char(255) [not null]
  project_id integer [not null, ref: > project.id]
}

Table user_story {
  id integer [primary key, not null, unique]
  guid uuid [primary key, not null, unique]
  goal text [not null]
  // optional free text
  reason text [not null]
  details text [null]
  notes_questions text [null]
  todos text [null]
  // per screenshot, all user stories belongs to one category and one role
  user_story_category_id integer [not null, ref: > user_story_category.id]
  user_story_role_id integer [not null, ref: > user_story_role.id]
  project_id integer [not null, ref: > project.id]
}

Table user_empathy_map {
  id integer [primary key, not null, unique]
  // no guid as the empathy map is directly bound to a persona and won't be edited on its own
  think_feel text [null]
  hear text [null]
  see text [null]
  say_do text [null]
  gains text [null]
  // explicitly *no* pains columns as this is already present on the persona itself
  persona_id integer [not null, ref: > persona.id]
}