Skip to Main Content

This page provides a long-form guide for authoring the definition of a feature that will be deployed on a Baseplate application. We typically generate these pages in Confluence with headers for each section. You can organize the items in each section at your discretion. This about the sub-headings as guidelines to enrich every section.

Feature Description

Five to ten well-paced paragraphs that introduce and contextualize the feature. Cover:

  1. Business Problem
    • The pain point or opportunity the feature addresses and who, among your Personas, it does that for
    • Quantify impact where possible (e.g. “Users currently spend 20 minutes manually…”).
  2. User Jobs-to-be-Done
    • Articulate what job your target personas have that is improved by the feature
    • Conceptually, here you are thinking about the job the user is hiring the software to do
    • The user has a job, they want an aspect of that job to be accomplished by software
    • So explain what that job is and how the feature addresses that
  3. Inspirational Examples
    • Point to 2–3 analogous features in other products.
    • Highlight what you like (e.g. “Salesforce’s list-view filter is intuitive because…”).

Current State

Describe how our Personas accomplish the job this feature addresses today and how our feature makes it easier or better to do this job

Role Access

For every Standard System Role and User Role you support, create a mini-section:

<Role Name>
Summarize which parts of the feature this role can view, edit, or manage. Focus on high-level capabilities without getting into stories yet.

User Stories
List up to 15 stories in the form:

As a <Role>, I want to <action> so that <business outcome>.

Pages & Screens

Enumerate every UI surface in your feature. This includes any new pages or screens it introduces or changes it makes to any current screens

<Screen Name>

A prose overview that positions this screen within the user’s workflow (what precedes and follows it).

Screen Content

Figma Link
When ready we’ll provide a link to the Figma file here.

Query & Setup

List all backend calls and preparatory logic needed before rendering each screen:

Actions

For screens that trigger actions (save, delete, export, LLM invocation), describe:

Notes

Any miscellaneous considerations that don’t fit elsewhere:

Implementation Approach

Owned by the development team. This section defines any aspects of the technical strategy that are important to document at the level of feature definition or scoping. Typical items include:

  1. Frontend
    • Any considerations or recommendations on Framework (React + Material UI) components that are relevant
    • State management considerations – Notes or considerations about maintain state across a complex set of UI components
  2. Backend
    • Any backend considerations or notes outside of the Data Model
  3. Integrations
    • Third-party APIs or LLM services that are needed to make the feature “work”
  4. Testing Strategy
    • Notes on required unit tests, integration tests or end-to-end tests

Data Model

A definition of the data model for the feature. This includes the following definition for each column:

Every field should be defined needed to persist the data, manage it’s transit and handle any states. Format the final field set as a table with any sub-tables broken out into their own tables.

NameDescriptionConstraintsNotes
featureIdUnique identifier for this feature record.Required, UUID formatPrimary key
enabledToggle to enable/disable the feature.Boolean, default false
lastRunAtTimestamp of last LLM query execution.ISO 8601 datetimeUsed for rate-limiting
…………

LLM Query

If the feature leverages generative AI:

Risks & Mitigation

Identify key risks and how you’ll address them:

RiskImpactMitigation
LLM hallucination of sensitive dataHigh (misinforming)Add fact-checking layer; display source citations.
Slow page load timesMedium (UX pain)Lazy-load non-critical components; optimize queries.

Implementation Roadmap

Present a phased rollout plan as bullet points. As an example:

LLM Query

Use the following LLM query template to generate a feature using the above format:

You are a product manager for a B2B SaaS Company. You are generating a feature for the application [Baseplate] the documentation for which is [hosted here: https://1to100.com/baseplate/] [described in the attached document].

You are going to create a feature definition for the feature named “XXXXX”. Here are some notes on the feature:

YYYYYYYYYY

# Standard System Roles

The system includes the following roles standard system roles:

##System Administrator

The System Administrator has the highest level of access in the application. This role is responsible for the overall management and configuration of the system. They can manage users and tenants, configure system-wide settings, and monitor system health. For example, a System Administrator might add a new tenant for a client, configure security settings, or troubleshoot system errors. They might also manage billing and subscriptions, create new roles and permissions, and handle support tickets.

## Customer Success

Customer Success can access assigned tenant accounts and assist with user issues. They can view user and tenant details, troubleshoot problems, and communicate with users to provide assistance. For example, a Customer Success representative might help a user reset their password, troubleshoot an error message, or guide them through a new feature. They can also manage support tickets and provide feedback to the development team.

## Customer Administrator

The Customer Administrator manages their specific tenant’s users, settings, and data. They can add, edit, and deactivate users, assign roles and permissions, and customize their tenant’s environment. For example, a Tenant Administrator might invite new team members, adjust subscription details, or monitor user activity within their tenant. They can also access reports on user engagement and feature adoption.

# User Roles

The system includes the following user roles

##Manager

Managers have access to information about their direct reports, such as profiles, activities, and performance reports. They can monitor their team’s progress, access relevant data, and communicate with team members within the platform. For example, a Manager might review a team member’s progress on a project, share resources, or provide feedback. They can also monitor project status and key metrics.

##Standard User

The Standard User can create and update their profile, access data and information relevant to their tasks, and collaborate with team members. They can use the platform’s features and tools to complete their work, receive notifications and updates, and access help and support resources. For example, a Standard User might update their profile, collaborate with team members on a project, or submit a support ticket. They can also provide feedback and suggestions to improve the platform.

#Instructions

Provide me a detailed description of the feature organized into the following areas:

# Feature Description

Five to ten well-paced paragraphs that introduce and contextualize the feature. Cover:

1. Business Problem
* The pain point or opportunity the feature addresses and who, among your Personas, it does that for
* Quantify impact where possible (e.g. “Users currently spend 20 minutes manually…”).
2. User Jobs-to-be-Done
* Articulate what job your target personas have that is improved by the feature
* Conceptually, here you are thinking about the job the user is hiring the software to do
* The user has a job, they want an aspect of that job to be accomplished by software
* So explain what that job is and how the feature addresses that
3. Inspirational Examples
* Point to 2–3 analogous features in other products.
* Highlight what you like (e.g. “Salesforce’s list-view filter is intuitive because…”).

# Current State

Describe how our Personas accomplish the job this feature addresses today and how our feature makes it easier or better to do this job

* Existing Workflow
* Overview of how each Persona currently accomplishes the job
* Gap Analysis
* List pain points associated with the existing workflow for each relevant Persona: time wasted, error rates, incomplete data, poor visibility.
* Explain how the feature addresses the pain points

# Role Access

For every Standard System Role and User Role you support, create a mini-section:
\<Role Name\>
Summarize which parts of the feature this role can view, edit, or manage. Focus on high-level capabilities without getting into stories yet.
User Stories
List up to 15 stories in the form:
As a \<Role\>, I want to \<action\> so that \<business outcome\>.

* Include any relevant data inputs or UI elements (e.g. “I click the “Approve” button on the Review screen…”).
* Capture both happy-path and edge-case scenarios (permissions, error states).

# Pages & Screens

Enumerate every UI surface in your feature. This includes any new pages or screens it introduces or changes it makes to any current screens

## \<Screen Name\>

A prose overview that positions this screen within the user’s workflow (what precedes and follows it).
Screen Content

* Static Text / Instructions – The specific text that we would like displayed on the screen inclusive of any styling information
* Illustrative Images – Any example wireframes or conceptual screen shots of the screen. Note that detailed Figma files will be made later so this is only important insofar as it helps communicate the idea behind the screen
* Data Display / Entry Fields – For each form field or interactive element:
* Name: Label shown in the UI
* Constraints: required/optional, length, format (e.g. email pattern)
* Error Checking: validation rules and error messages (e.g. “Must be a number between 1–100”)
* Field Notes: any special UI behavior (e.g. character counters, auto-complete)

Figma Link
When ready we’ll provide a link to the Figma file here.

# Query & Setup

List all backend calls and preparatory logic needed before rendering each screen:

* Data Queries
* Endpoint name or SQL query. Exact definitions aren’t required from product just a rough description. Development will update the data queries with any specifics needed
* Input parameters, paging, sorting or filtering
* Business Logic
* Any transformations, permission checks, or data-massaging steps needed
* Caching or pre-fetching recommendations

# Actions

For screens that trigger actions (save, delete, export, LLM invocation), describe:

* Action Name (e.g. “Generate Summary”)
* Trigger (button, menu item, API callback)
* Side Effects
* Data changes (what database tables are updated)
* UI feedback (loading spinners, toast messages)
* Downstream events (webhooks, analytics tracking)

# Notes

Any miscellaneous considerations that don’t fit elsewhere:

* Accessibility requirements (ARIA labels, keyboard nav)
* Internationalization (text length, date formats)
* Performance targets (screen load \< 2 s)
* Security or compliance checks

# Implementation Approach

Owned by the development team. This section defines any aspects of the technical strategy that are important to document at the level of feature definition or scoping. Typical items include:

1. Frontend
* Any considerations or recommendations on Framework (React \+ Material UI) components that are relevant
* State management considerations – Notes or considerations about maintain state across a complex set of UI components
2. Backend
* Any backend considerations or notes outside of the Data Model
3. Integrations
* Third-party APIs or LLM services that are needed to make the feature “work”
4. Testing Strategy
* Notes on required unit tests, integration tests or end-to-end tests

# Data Model

A definition of the data model for the feature. This includes the following definition for each column:

* Name – The name for the field consistent with the PostgrSQL column naming convention
* Description – A description of the data that the field models or represents
* Constraints – Any constraints associated with the field such as required, length, formatting or options if a select list
* Notes – Any additional descriptive notes for the field

Every field should be defined needed to persist the data, manage it’s transit and handle any states. Format the final field set as a table with any sub-tables broken out into their own tables.

| Name | Description | Constraints | Notes |
| :—- | :—- | :—- | :—- |
| featureId | Unique identifier for this feature record. | Required, UUID format | Primary key |
| enabled | Toggle to enable/disable the feature. | Boolean, default false | |
| lastRunAt | Timestamp of last LLM query execution. | ISO 8601 datetime | Used for rate-limiting |
| … | … | … | … |

# LLM Query

If the feature leverages generative AI:

* Prompt Templates
* Placeholders and instructions for the model (e.g. “Summarize the following text in three bullet points.”)
* Retrieval / Embedding Setup
* Vector store, context window size, prompt chaining
* Fallback Logic
* What happens if the model returns an error or hallucination?

# Risks & Mitigation

Identify key risks and how you’ll address them:

| Risk | Impact | Mitigation |
| :—- | :—- | :—- |
| LLM hallucination of sensitive data | High (misinforming) | Add fact-checking layer; display source citations. |
| Slow page load times | Medium (UX pain) | Lazy-load non-critical components; optimize queries. |

# Implementation Roadmap

Present a phased rollout plan as bullet points. As an example:

* Phase 1: Foundations
* Scaffold UI components, define data model, stub APIs
* Phase 2: Core Workflows
* Build “happy-path” screens, implement user stories for Admin and End User
* Phase 3: Permissions & Edge Cases
* Add role-based access, error-handling paths, validation
* Phase 4: LLM Integration
* Wire up prompts, handle response parsing, display results
* Phase 5: Testing & Polish
* Automated tests, performance tuning, accessibility audits
* Phase 6: Beta Rollout
* Internal release, feedback gathering, iterate on UX

Get in touch
Company Resources
Compliance
Copyright
  • © 2025 One to One Hundred. All Rights Reserved.
  • Site by Arcbound.