Core rule:

Build consistent, accessible, and user-friendly interfaces. Every page, form, and component must follow the same standards — the user should never feel like different parts of the product were built by different teams.

Contents

1. UI Consistency Standard

Similar pages must follow the same UI and behavior.

Add/Edit Form Rule

If Add and Edit pages are for the same entity, they must use the same:

Example

Bad:

Add Project has phone validation.
Edit Project allows any text.

Good:

Both Add and Edit Project use the same ProjectForm component and validation schema.

2. Reusability Standard

Avoid duplicate code and duplicate UI.

Reuse When

Good Reusable Structure

components/
  forms/
    ProjectForm.tsx
  modals/
    DeleteConfirmationModal.tsx
  ui/
    Button.tsx
    Input.tsx
    Tooltip.tsx

validations/
  project.schema.ts

services/
  project.service.ts

utils/
  api-error-handler.ts

Anti-Pattern

Copy-pasting the same form into Add and Edit pages. This causes bugs because one page gets updated and the other does not.

3. Form Standards

Every form must have proper validation, loading, error, and success behavior.

Mandatory Form Standards

Required Field Standard

Good:

Project Name *
[ Enter project name ]

Bad — using only placeholder text with no label:

[ Enter name ]

4. Required Star Standard

Use star only for required fields.

Name *
Email *
Phone Number *

Optional fields can use:

Description (optional)

Do not put stars randomly. Do not forget stars on required fields.

5. Password & Security Validation Standard

For signup, reset password, change password, and admin user creation.

Password Rules

Password Error Example

Password must contain at least 8 characters, one uppercase letter, one lowercase letter, and one number.

Security Rules

6. Phone Field Standard

Phone fields must not be simple text fields.

Required Standard

UI Standard

Phone Number *
[ 🇮🇳 +91 ] [ 9876543210 ]

Error

Enter a valid phone number.

7. Disabled / Enabled Field Standard

Disabled fields must be visually clear.

Disabled Field UI

Example Tooltip

This field cannot be edited after project creation.

Bad

A disabled field that looks like a normal editable field.

Good

A disabled field that visually communicates it is locked, and why.

8. Tooltip Standard

Tooltips should be used only where they add clarity.

Use Tooltip For

Do Not Use Tooltip For

• Obvious fields like Name or Email.
• Replacing proper labels.
• Long documentation.
• Critical errors.

Tooltip Text Standard

Good:

Only workspace owners can change this setting.

Bad:

Info.

9. Error Handling Standard

Frontend must show errors to the user properly. The user will not open the browser console.

Mandatory Error Handling

Error Color Standard

Error Message Examples

Bad:

Something went wrong.

Better:

We could not save the project. Please check the required fields and try again.

Bad:

Error 500.

Better:

Server error occurred while saving. Please try again in a moment.

10. Notification Standard

Use consistent notifications.

Notification Types

Examples

Success:

Project created successfully.

Error:

Project could not be created. Please try again.

Warning:

You have unsaved changes.

Info:

Changes are being processed.

11. Draft Save & Session Recovery Standard

For long forms, important forms, or multi-step forms, draft recovery should be considered.

Use Draft Saving For

Draft Standards

Example UI

Draft saved 2 minutes ago.

You have unsaved changes. Are you sure you want to leave?

12. Loading State Standard

Every async action must show a loading state.

Required Loading States

Button Example

Normal:

Save Project

Loading:

Saving...

Success:

Saved

Delete loading:

Deleting...

13. Delete Confirmation Standard

Any destructive action must have confirmation.

Low-Risk Delete

Are you sure you want to delete this item?
This action cannot be undone.

[Cancel] [Delete]

High-Risk Delete

Type DELETE to confirm.

Very High-Risk Delete (workspace/account/data)

Type the workspace name to confirm deletion.

Also consider password or 2FA confirmation.

14. Testing Your Own Work

Every member must test their own work before marking complete. QA should not find basic issues that the developer could easily check.

Self-Testing Checklist

Completion Comment Must Mention Testing

Example:

Testing Done:
- Created project successfully.
- Checked required field validation.
- Checked API failure handling.
- Verified Add/Edit UI consistency.
- Checked mobile layout.

15. Design System Standard

Every project should follow a consistent design system.

Required Design System Areas

Rule

Do not create a new design style for every page. Similar pages must feel like they belong to the same product.

16. Backend + Frontend Error Contract

Frontend and backend must agree on error format before building.

Backend Should Return

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Please fix the highlighted fields.",
    "fields": {
      "email": "Enter a valid email address."
    }
  }
}

Frontend Should Handle

Bad Frontend Behavior

console.log(error);

without showing anything to the user.