← Back to Starchart Case Study
Service Design · Case Study

Starchart
Service Design Framework

A deliverables map for the end-to-end service design of Starchart — a specialized report-writing tool built to support a professional astrology practice offering relocation and astrocartography readings.

DesignerZen
ServiceAstrology Relocation Practice
Tool ScopePractitioner-facing SaaS
StatusActive Design & Build
01 — Service Context
What is the service?

Starchart supports a two-sided professional service: the practitioner synthesizes astrological chart data, astrocartography maps, and location intelligence into a narrative report delivered to the client. The tool lives entirely in the practitioner's backstage — it is the production environment, not the customer-facing channel.

Service in one sentence

A relocation astrology reading is a structured, personalized narrative that synthesizes an individual's natal chart with place-based astrological data (astrocartography lines, paran latitudes, city intelligence) to advise on where in the world they might live, work, or travel most aligned with their life goals.

Service Type
Knowledge Service
A highly customized professional interpretation — not a product, not a subscription, but a bespoke reading produced by an expert practitioner for a specific individual.
Primary Artifact
The Report
A long-form written document organized geographically, synthesizing chart data with narrative interpretation. The report is both the deliverable and the service itself — the practitioner's craft is in the writing.
Design Challenge
Reducing friction in synthesis
The practitioner must hold chart data, map context, and narrative voice simultaneously. Starchart exists to reduce the cognitive overhead of that synthesis — not to automate interpretation, but to make the writing environment deeply intelligent.
02 — Service Actors
Who is involved?

Two human actors, one primary support system, and the service artifact that bridges them.

Primary Actor · Tool User
The Practitioner (Zen)
  • Receives client intake and birth data
  • Generates natal chart via Swiss Ephemeris
  • Interprets astrocartography lines and paran latitudes
  • Researches notable cities near key lines
  • Writes synthesized, geography-organized report
  • Delivers report and handles follow-up
The Report
Secondary Actor · Service Recipient
The Client
  • Submits inquiry and books reading
  • Provides birth data (date, time, location)
  • Shares relocation goals and questions
  • Receives and reads the completed report
  • Returns for follow-up or related readings
  • May share or refer to the report long-term
Support Systems (Backstage Infrastructure)
Swiss EphemerisChart calculation
MapboxAstrocartography maps
PostGIS + GeoNamesCity intelligence
TipTap / ProseMirrorReport editor
Macro LibraryInterpretation templates
03 — Deliverables Map
Four-phase framework

Organized across Discover → Define → Design → Deliver. Each phase produces specific artifacts that build on one another. The Service Blueprint (Design phase) is the anchoring deliverable; all others support or extend it.

01
Phase One
Discover
Document the current-state experience for both actors before the tool existed. Surface inefficiencies, moments of craft, and the emotional texture of the service.
Practitioner Research
Current-State Practitioner Journey Map
A swim-lane diagram tracing the practitioner's full workflow from receiving a booking to delivering the final report — before Starchart exists. Captures actions, tools used, pain points, and moments of craft.
Starchart-specific content
  • The toggle between Astro Gold, external maps, and a writing tool
  • The friction of manually cross-referencing chart data while writing
  • The cognitive load of holding planetary line context across a long document
  • Moments where the practitioner's voice and synthesis are strongest
Client Research
Client Experience Journey Map
Documents the client's experience from initial discovery through to reading and acting on the report over time. Highlights emotional highs/lows, touchpoints, and unmet needs on the recipient side of the service.
Starchart-specific content
  • The moment a client receives and opens the report for the first time
  • Navigating a long geography-organized document without guidance
  • Returning to the report months later as a reference artifact
  • The gap between delivery format (PDF, doc) and readability on mobile
Context Mapping
Stakeholder Map
A visual map of everyone who touches or is affected by the service — direct, indirect, and peripheral. Includes practitioner, clients, referral network, platform providers, and the astrology community that shapes interpretive norms.
Starchart-specific content
  • Swiss Ephemeris maintainers (critical infrastructure dependency)
  • Mapbox as a commercial partner with usage-based pricing implications
  • The astrology community as a source of interpretive legitimacy
  • Repeat clients vs. one-time clients (different relationship shapes)
Needs Analysis
Jobs-to-be-Done Framework
Reframes practitioner and client goals as functional, emotional, and social "jobs." Separates what both actors are trying to accomplish from the solutions they currently use, revealing design space that features alone don't surface.
Starchart-specific content
  • Practitioner JTBD: "Help me write with authority without losing my voice to admin"
  • Practitioner JTBD: "Let me find the right interpretation springboard without starting cold"
  • Client JTBD: "Help me understand where in the world I should be right now"
  • Client JTBD: "Give me something I can return to and trust over time"
02
Phase Two
Define
Synthesize discovery findings into design principles, opportunity frames, and a shared model of what the service should become. Establish the north star before moving into design.
Core Artifact
Experience Principles
Six design principles that govern all Starchart experience decisions — for both the practitioner tool and the report as a client-facing artifact. These are derived from synthesis of both journey maps and the JTBD framework.
01
Voice-forward, data-assisted
The practitioner's interpretive voice drives every interaction. Data and context surface as support, never as substitute. The tool should feel like a studio, not a form.
02
Geography as organizing logic
Both the tool and the report are organized by place, not by planet or technique. The client thinks in terms of "Paris, not Venus conjunct IC." The design follows the client's mental model.
03
Synthesis over enumeration
Starchart actively resists producing mechanical lists. Related lines cluster. Context co-locates with content. The design favors paragraph-level thinking, not bullet-level assembly.
04
The report is a lasting artifact
Clients return to their reports for years. Every design decision about the report's structure, readability, and navigation should account for re-reading over time, not just first-pass consumption.
05
Invisible infrastructure
Ephemeris calculations, map generation, and city intelligence should surface naturally in context — not require the practitioner to consciously switch modes or mental frames.
06
Macro as springboard, not template
Stored interpretations are starting points that the practitioner rewrites and adapts. The library lowers the cost of starting; it does not reduce writing to retrieval.
Systems Thinking
Service Ecosystem Map
A visual overview of every system, touchpoint, and handoff in the end-to-end service — from client inquiry to long-term report access. Distinguishes between what the practitioner controls, what Starchart manages, and what is external dependency.
Starchart-specific content
  • The boundary between Starchart and the practitioner's booking/payment flow
  • Swiss Ephemeris as a separately-hosted calculation service (Digital Ocean)
  • The handoff between report creation (in Starchart) and report delivery (email/link)
  • Mapbox map rendering as a hybrid static/interactive artifact in shared reports
Opportunity Framing
How Might We Statements
A synthesized set of HMW questions derived from pain points in both journey maps. Reframes problems as design invitations without prescribing solutions. Serves as the bridge between research findings and design decisions.
Starchart-specific content
  • HMW: surface relevant city context without interrupting the writing flow?
  • HMW: help the practitioner enter a new report without starting from blank?
  • HMW: make the delivered report navigable to a client with no astrology background?
  • HMW: preserve the practitioner's voice even when using stored macros?
Value Design
Value Proposition Canvas
Maps practitioner gains, pains, and jobs against what Starchart's features deliver — ensuring the tool's design rationale is anchored to actual practitioner needs rather than technical feasibility alone.
Starchart-specific content
  • Pain reliever: eliminates the multi-app context-switching loop
  • Gain creator: macro library reduces time-to-first-draft significantly
  • Pain reliever: /place command brings geography-based context inline
  • Gain creator: astrocartography map embedded in report, not attached separately
Scope Definition
V1 / V2 Scope Document
A documented decision log of what is built in V1 versus deferred to V2, with rationale for each call. Ensures data foundations are built in V1 even when the features that consume them are deferred.
Starchart-specific content
  • V1: natal chart + astrocartography maps, macro library, /place slash command
  • V1: PostGIS city intelligence with spiritual/pilgrimage site data (foundation)
  • V2: solar return charts, synastry, contextual macro surfacing by planetary line
  • V2: client-facing report portal with account and access management
03
Phase Three
Design
Translate defined opportunities into the architecture of the service and the tool. The Service Blueprint is the anchor deliverable — all other design artifacts extend or detail specific sections of it.
Core Artifact · Anchoring Deliverable
Service Blueprint
Maps the full end-to-end service across five swim-lanes: client actions, line of interaction, practitioner frontstage actions, line of visibility, backstage tool actions, and supporting systems. The blueprint makes visible what happens before, during, and after the client receives the report — and reveals where Starchart's design most directly reduces backstage friction.
Swim Lane Intake & Setup Chart Generation Map & Intelligence Report Writing Delivery & Follow-up
Client Actions Books reading, submits birth data and relocation goals via intake form Waits; no visibility into production process Waits Waits Receives report link or file; reads, references, returns over time
— Line of Interaction (client ↔ practitioner boundary) —
Frontstage (Practitioner) Acknowledges booking; may conduct brief intake call — — — Sends completed report; available for follow-up questions
— Line of Visibility (client-visible ↔ invisible work) —
Backstage (Practitioner in Starchart) Creates new Report in Starchart; enters client name, birth data, report type, location fields Triggers Swiss Ephemeris calculation from Starchart; reviews natal chart in-app Opens Mapbox MapBlock; reviews astrocartography lines; uses /place to surface city intelligence along key lines and parans Writes geography-organized report in TipTap editor; inserts and adapts macros from library; embeds map blocks as section anchors; adds interpretation per city cluster Exports or shares report; archives in Starchart; notes follow-up flags
— Line of Internal Interaction (Starchart ↔ supporting systems) —
Support Systems Vercel / Next.js hosting; auth layer Swiss Ephemeris service on Digital Ocean droplet returns chart data via API Mapbox renders astrocartography overlay; PostGIS + GeoNames city intelligence returns notable cities near lines within configurable radius TipTap / ProseMirror editor; macro library (deep copy on insert); SlashCommand extension for /place Report export / share layer; optional client-facing view (V2)
Tool Design
Practitioner User Flows
Detailed task-level flows for the practitioner's primary workflows within Starchart: creating a new report, generating a chart, inserting a macro, using /place, and saving a selection as a new macro.
Starchart-specific content
  • New report creation flow with ReportType field and location input
  • /place slash command flow: city input → PostGIS query → inline context panel
  • "Save Selection as Macro" bubble menu → category → name → library
  • Macro insertion flow: browse/search → insert as deep copy → edit freely
Content Architecture
Information Architecture & Content Model
Defines the taxonomy and data model underpinning both the report document and the macro library. Establishes how content is organized, typed, and related — including macro categories, report types, and the location data model.
Starchart-specific content
  • Macro categories: planetary lines, parans, bridge (narrative framing), angles
  • Report model: client, ReportType, location fields, birth data, chart reference
  • City intelligence model: notable cities, spiritual/pilgrimage sites, paran latitudes
  • Document structure: geography-organized sections as TipTap headings
Design System
UI Component Inventory & Theming Spec
Documents the 19 UI surface components in Starchart's design system, including the neobrutalist visual language (zero border-radius, 4px borders, hard-offset shadows, #FFE500 accent) and the Space Grotesk / Inter typography pairing.
Starchart-specific content
  • Editor surface vs. sidebar surface vs. map surface theming distinctions
  • Macro library panel component states: browse, preview, inserted
  • Bubble menu component for in-editor context actions
  • MapBlock world/regional variants and embed states
Report Experience
Client Report Experience Design
Designs the report as an artifact from the client's perspective — considering navigation, readability for a non-astrologer, the role of embedded maps, and long-term reference usability. A distinct design problem from the practitioner's writing experience.
Starchart-specific content
  • Geography-as-heading structure and how it guides a first-time reader
  • Hybrid static/interactive Mapbox map behavior in a shared report link
  • Place name anchoring as a navigation aid across a long document
  • V2 consideration: client-facing portal with persistent report access
04
Phase Four
Deliver
Validate the design against real production use, instrument the service with appropriate measures, and establish a feedback loop that improves both the tool and the service over time.
Service KPIs & Success Metrics
Practitioner Efficiency
  • Time from new report creation to first paragraph written
  • Time from chart generation to report delivery
  • Macro usage rate per report (springboard uptake)
  • Number of city intelligence queries per report (/place usage)
Report Quality
  • Average report word count and section depth
  • Geographic coverage (number of distinct cities addressed)
  • Client re-read rate (report link re-opens over 90 days)
  • Client referral rate (new clients citing a previous client)
Service Health
  • Time between booking and report delivery
  • Repeat booking rate (same client, different reading type)
  • Macro library growth rate (new macros saved per month)
  • Swiss Ephemeris API reliability and latency (SLA)
Build Roadmap
Phased Implementation Plan
A sequenced build plan that maps deliverables to implementation phases, distinguishing V1 production features from V2-deferred features while ensuring that data foundations (PostGIS schema, ReportType model, location fields) are built in V1 even when their consuming features are deferred.
Starchart-specific content
  • V1 core: editor + chart + maps + macro library + city intelligence + /place
  • V2 deferred: solar return, synastry, contextual macro surfacing, client portal
  • Data foundations built in V1 regardless of V2 feature readiness
  • Claude Code + Cursor as primary build toolchain
Validation
Pilot & Iteration Plan
Defines how the practitioner will use Starchart on real client reports as a pilot, what feedback signals to capture from both practitioner experience (writing flow, macro utility) and client response (report readability, follow-up questions), and how findings will feed back into design iteration.
Starchart-specific content
  • Pilot on 3–5 real client reports with explicit retrospective note-taking
  • Track: which macros get edited heavily (signals poor fit or over-templating)
  • Track: which city intelligence results are used vs. ignored
  • Client feedback on report navigability and the embedded map experience
04 — Deliverables at a Glance
Full deliverables register

All fifteen deliverables mapped by phase, type, and V1/V2 status.

Phase Deliverable Type Scope
DiscoverCurrent-State Practitioner Journey MapJourney MapV1
DiscoverClient Experience Journey MapJourney MapV1
DiscoverStakeholder MapContext MapV1
DiscoverJobs-to-be-Done FrameworkNeeds AnalysisV1
DefineExperience PrinciplesDesign PrinciplesV1
DefineService Ecosystem MapSystems MapV1
DefineHow Might We StatementsOpportunity FrameV1
DefineValue Proposition CanvasValue DesignV1
DefineV1 / V2 Scope DocumentScope DefinitionV1
DesignService BlueprintBlueprintV1
DesignPractitioner User FlowsUser FlowV1
DesignInformation Architecture & Content ModelIA / ContentV1
DesignUI Component Inventory & Theming SpecDesign SystemV1
DesignClient Report Experience DesignExperience DesignV1 / V2 extended
DeliverService KPIs & Success MetricsMeasurementV1
DeliverPhased Implementation PlanRoadmapV1
DeliverPilot & Iteration PlanValidationV1