Fieldwork.
Better decisions start
closer to the customer.
A connected brand, product, and launch concept for a customer-research workspace. Designed to turn scattered conversations into decisions a team can explain.
Independent studio concept · Fictional product · No client resultsCloser to people.
Clearer on
what’s next.
A product and brand, built around better questions.Good questions.
Grounded decisions.
The signal in your customer conversations.
Every insight links back to the conversation behind it.
The problem
behind the brief.
Customer knowledge often lives in interview recordings, support threads, sales notes, and someone’s memory. Product teams can collect plenty of feedback and still struggle to explain why one problem deserves attention now.
Fieldwork explores a smaller, more useful promise: keep customer evidence connected to the next product decision. AI can help organize the material; a person decides what the evidence supports.
The starting audience is a founder or product lead running a small B2B software team. That audience, the problem frequency, and willingness to pay are assumptions to test—not research findings.
A clear promise.
A recognizable presence.
“Bring the evidence to every product decision.” The positioning focuses on the job to be done, with a calm, grounded identity that gives the evidence room to lead.
Listen closely.
Move clearly.
From a conversation
to a considered next step.
Ideation: test the expensive assumptions.
Before building, interview six to eight founder-led product teams. Ask them to walk through their last roadmap decision, show where the evidence lived, and explain the cost of getting it wrong. This is a proposed research plan; those interviews have not occurred.
Run a concierge test using a small set of consented, de-identified research notes. Measure whether participants can find the source, correct a misleading theme, and create a useful decision brief without assistance.
- Artifacts: research guide, assumption map, audience definition, and opportunity brief.
- Decision gate: proceed only if teams show a recurring problem and a credible adoption path.
Product design: show the source, keep the judgment.
The core journey starts in the research inbox. A user reviews a suggested theme, opens its source excerpts, edits the interpretation, and adds it to a decision brief. Every summary keeps its source nearby.
The concept includes empty workspaces, failed imports, duplicate sources, redacted material, contradictory feedback, low-confidence suggestions, and revoked access. A useful happy path needs these boundaries.
- Artifacts: journey map, wireframes, interface system, and interactive prototype specification.
- AI labels remain suggestions until a person reviews them. No unsupported certainty or invisible auto-publishing.
Engineering: a narrow release with a clear boundary.
A proposed first build uses a web application, authenticated workspaces, role-based access, a relational data store, and asynchronous import jobs. Source text is separated from derived AI outputs; each suggestion records its source, model version, and review status.
The first release supports text notes and CSV import. Recording ingestion, CRM sync, billing, SSO, and full-text semantic search are follow-on decisions. Vendor choice, data retention, model processing permissions, and hosting region must be agreed before implementation.
- Artifacts: architecture note, data model, access matrix, evaluation fixtures, and release runbook.
- Acceptance tests: citation integrity, tenant access, import retry, deletion, correction, export, and a manual fallback.
Go to market: teach the workflow before selling the tool.
The proposed entry offer is a guided research-to-decision session for a small team. A landing page leads with the problem, shows one complete workflow, and invites a design-partner conversation.
A four-week launch sequence develops a product walkthrough, a source-to-decision article, a practical research template, onboarding messages, and founder-led conversations. Outreach begins only after audience, consent, and messaging review.
- Activation hypothesis: a team imports five useful sources and creates its first reviewed decision brief.
- Proposed measures: time to first reviewed brief, successful source retrieval, weekly reuse, and correction rate. These are targets to establish, not achieved results.
Beyond launch: keep the learning loop open.
Use a shared issue queue to separate defects, research gaps, and feature requests. Review critical failures first, then assess friction in the core workflow. Keep a written decision log so feedback does not become an unprioritized feature list.
At handoff, the client would receive the repository, environment and vendor map, source design files, test and evaluation instructions, analytics definitions, support routes, and the next experiment backlog.
- 30-day scoped defect window after acceptance; separate monthly plan for ongoing improvements.
- Monthly review: what users tried, where the workflow broke, what changed, and what to test next.
What this case study demonstrates.
This is an original Purna design study and delivery blueprint. The website contains brand and interface compositions, a proposed user journey, architectural considerations, and a launch approach. It is not a released SaaS product.
No customer interviews, production implementation, paying customers, revenue, conversion improvements, or third-party endorsements are represented as completed. The next meaningful step is to validate the problem and build the smallest testable workflow.