Naming research for Research Architect / Compass

Raw source preview

Raw, unprocessed file text shown below.

---
title: "Naming Research — Compass (pre-design context tool)"
date: 2026-04-15
status: open — decision not yet made
---

# Naming Research: Compass

**Question:** Is "Compass" the right name for the pre-design context and brief-planning tool? What are the alternatives, and do they require a wider naming convention change?

---

## What this tool does (the job to name)

Compass is the pre-design context layer — the missing first step in the research workflow. It:

- Takes a research brief and generates a structured checklist of context worth gathering
- Conducts some of that gathering (desk research, competitive landscape, industry analysis) automatically
- Organises brief, context materials, instruments, and stimulus in one project container
- Is platform-agnostic: supports research conducted anywhere, with results imported back afterwards
- Hands off to Research Guard (questionnaire review) and ultimately Insight Navigator (knowledge retrieval)

**Desmond's framing (from ideas log):**
> "This one helps you organise all your thoughts so that your research materials and contextual materials are sufficiently available to then design research. Research Guard makes sure that the research you design meets the spec — Compass helps you organise everything so you have enough context to design it well in the first place."

---

## Why "Compass" is weak

The existing resonant names — Research Guard, Insight Navigator — share a clear pattern:

| Name | Word 1 | Word 2 | Second word role |
|---|---|---|---|
| Research Guard | domain | protective role | stands watch, defends |
| Insight Navigator | outcome | guidance role | charts the course |
| Trust Centre | quality dimension | operational facility | where quality is managed |

Compass breaks this pattern:
- Single word, not two
- Metaphorical, not functional — doesn't describe what it does to research
- Already used extensively as a product name across many sectors
- Cannot easily follow the `<un>` brand convention

---

## Candidate names evaluated

### Two-word functional names (following current convention)

| Name | Rating | Notes |
|---|---|---|
| **Research Architect** | ⭐⭐⭐⭐⭐ | Strongest fit. Architects design from first principles before anything is built — exactly the job. "Research" as prefix is unambiguous. Pairs cleanly: Research Architect → Research Guard → Trust Centre → Insight Navigator. No obvious domain conflict found. |
| **Brief Architect** | ⭐⭐⭐⭐ | Same second word, stronger specificity on the brief. Slight risk: "brief" reads as "short" in cold read. In context, clear enough. |
| **Research Primer** | ⭐⭐⭐⭐ | "Primer" = preparation layer before the real work begins; also a foundational briefing document. Dual meaning maps cleanly. Enterprise-appropriate. |
| **Research Guide** | ⭐⭐⭐ | "Guide" is weaker than "Navigator" (already used) and weaker than "Architect." Also conflicts with the document type "a research guide." |
| **Design Guide** | ⭐⭐⭐ | On-brand with the Design → Protect → Compound pillar. But "design guide" is heavily used in brand/UI contexts. |
| **Research Scope** | ⭐⭐⭐ | Scoping is what researchers do to briefs. Enterprise-natural. But "scope" undersells the intelligence and context-gathering dimension. |
| **Research Curator** | ⭐⭐⭐ | Gathers, organises, contextualises — accurate to the function. Slight risk of blending with Insight Navigator in the user's mind. |

### `<un>` brand convention names

| Name | For tool | Notes |
|---|---|---|
| `<un>pack` | Compass | Unpacks the brief. Natural research language ("let's unpack this"). Earns the prefix honestly. Strong. |

---

## The `<un>` convention question

Introducing `<un>pack` raises a consistency question: does the rest of the tool suite need to follow?

### Full `<un>` capability layer — what it would look like

| Tool | `<un>` name | Logic |
|---|---|---|
| Compass | **`<un>pack`** | Unpacks the brief into structured context before design |
| Research Guard | **`<un>mask`** | Unmasks hidden bias, risk, and ambiguity in the questionnaire |
| Trust Centre | **`<un>real`** | Removes the "unreal" (fake, duplicate, disengaged) respondents. Residual word: *real*. Double meaning: "unreal quality." |
| Insight Navigator | **`<un>earth`** | Unearths buried knowledge from the research archive. Residual word: *earth* = grounded, solid. |

Method products (Surveys, Discussion Groups, AI Interviews, Panel) likely stay descriptive — they describe a research *method*, not a platform *capability*, and the `<un>` convention would feel forced.

**The suite story in one sentence:**
> *Design better research with `<un>pack` and `<un>mask`. Protect your data with `<un>real`. Surface everything you've learned with `<un>earth`. All inside `<un>peel`.*

**Knock-on effect on the hero animation:**
The existing animation cycles: cover → pack → tangle → earth → veil → **peel**. If `<un>pack` and `<un>earth` become product names, the animation inadvertently shows two product names among four random words. If the full `<un>` convention is adopted, the animation could be redesigned to literally cycle through the product suite:
> `<un>`[pack] → [mask] → [real] → [earth] → **peel**

This turns the animation from a brand flourish into a platform pitch.

### Honest assessment of the trade-offs

| | For | Against |
|---|---|---|
| Full `<un>` suite | Coherent brand system. Every tool name IS the product proposition. Animation becomes the platform story. | Requires renaming Research Guard (already resonating) and Trust Centre. `<un>mask` is weaker than Research Guard. Risks name blur (all starting with `<un>`). |
| Two-word names only | Research Guard and Insight Navigator are strong — don't fix what isn't broken. | `<un>pack` alongside Research Guard creates naming inconsistency. |
| Hybrid (only new tools get `<un>`) | Minimal disruption. | One `<un>` name among two-word names creates an unfinished feeling. |

---

## Decisions made

### ✅ Compass → Research Architect (confirmed 2026-04-15)
Compass is renamed to **Research Architect**. Rationale: follows the Research Guard / Insight Navigator two-word functional naming pattern exactly. "Research" is unambiguous as a domain prefix. "Architect" implies deep structural design from first principles before anything is built — accurate to the tool's function. "Brief" was considered but creates a cold-read ambiguity ("brief" = short). The workflow sequence now reads: Research Architect → Research Guard → Trust Centre → Insight Navigator.

### ⏸ One word or two? (open — see below)
Whether to style as **Research Architect** (two words) or **ResearchArchitect** (compound) is undecided. See the analysis below.

### ⏸ Full `<un>` capability layer convention (deferred)
Whether to rename Research Guard → `<un>mask`, Trust Centre → `<un>real`, Insight Navigator → `<un>earth` is not being decided now. Research Guard and Insight Navigator are already resonating well. Do not rename without a deliberate decision.

### ⏸ Research Architect UX architecture (open — tracked in product-follow-up-log.md as PROD-001)
Whether Research Architect should be a separate project type ("New Custom Project") in the new project modal, or the universal first step for all projects (brief-first, method-second), is an open product architecture decision. The current modal is method-first; Research Architect's philosophy is brief-first. These conflict and need resolution before the in-platform label is finalised.

---

## One word or two? ResearchArchitect vs Research Architect

### The case for one word (ResearchArchitect, ResearchGuard)
- Feels more branded — reads as a product name, not a job description
- Harder to mistake for a generic phrase ("a research architect" vs "ResearchArchitect the product")
- Consistent with many SaaS compound naming conventions (HubSpot, Salesforce, Typeform, GitHub)
- Works cleanly in URLs and code (`/researcharchitect`, `/researchguard`)
- "ResearchGuard" in particular signals "this is a specific thing" — "Research Guard" could be a team or a department

### The case for two words (Research Architect, Research Guard)
- These are tool names *inside* `<un>peel` — distinctiveness comes from the parent brand, not the tool name itself
- Enterprise buyers parse two-word phrases faster. "Research Architect" is immediately legible; "ResearchArchitect" requires a parse.
- Consistent with existing precedent: Trust Centre, Insight Navigator, Discussion Groups are all two words. A mix of compound and spaced names creates inconsistency.
- In sentences and copy, two words reads more naturally: "Use Research Architect to plan your study" vs "Use ResearchArchitect to plan your study"
- In the platform UI, two-word names fit standard UI conventions — buttons, nav items, and modal options all use spaced phrases
- Compound naming works best for standalone consumer/SMB brands with independent identity needs; these tools live inside a platform

### Recommendation: two words
Keep **Research Architect** and **Research Guard** as two words. The `<un>peel` platform brand provides all the identity distinctiveness needed. If any of these tools are ever productised and sold standalone, revisit compound naming at that point.

---

## In-platform naming note

Whatever the marketing name, the in-platform label for this feature will likely be "New Custom Project" or similar — a project shell created without a specific research method, for context gathering and brief work. The marketing name does not need to match the in-product label. See also: the UX question of whether this tool is better framed as the *gateway to all projects* (universal first step) rather than a separate project type. That question is open.

---

*Naming research: AI-assisted (Claude / EmpathyIQ PM workspace), 15 April 2026.*