KEMBAR78
Design System - Input | PDF | Software | Computing
0% found this document useful (0 votes)
33 views13 pages

Design System - Input

The document outlines a request for a unified design system to standardize elements like buttons, colors, and typography across an app for improved user experience. It details specific design requirements for various screens, including login, client management, and settings, ensuring consistency and accessibility. Additionally, it emphasizes the need for responsive design and provides guidelines for color and typography choices.

Uploaded by

ganeshthorat2209
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views13 pages

Design System - Input

The document outlines a request for a unified design system to standardize elements like buttons, colors, and typography across an app for improved user experience. It details specific design requirements for various screens, including login, client management, and settings, ensuring consistency and accessibility. Additionally, it emphasizes the need for responsive design and provides guidelines for color and typography choices.

Uploaded by

ganeshthorat2209
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Introduction

We are requesting the creation of a unified design system to ensure consistency and usability
across our app. This design system will standardize elements such as buttons, colors,
typography, and interactive states (e.g., loading, disabled, hover) to provide a cohesive and
professional user experience.

Specifically, we aim to:

● Use a consistent style for buttons, clearly distinguishing between primary actions (CTAs)
and secondary actions.
● Maintain uniformity in the app’s color palette, ensuring accessibility and alignment with
our brand identity.
● Define and document the various states for interactive elements (e.g., loading, disabled,
hover).

Although the attached screenshots showcase the current state of the app, please note that the
platform is fully responsive and must work seamlessly on mobile devices. Any design decisions
should consider adaptability for different screen sizes and orientations.

Screenshots and Annotations

Below, we will provide screenshots of key screens in the app. Each screenshot will include
descriptions of its functionality and specific design elements that require attention. These
examples are meant to guide the design system’s development and showcase its application in
practical scenarios.

Access Screens

1. Login
○ Functionality: Allows users to securely access the platform by entering their
credentials.
○ Design Requirements:
■ Clear distinction between "Login" (primary action) and any secondary
actions (e.g., "Forgot Password").
■ States for buttons and fields (e.g., hover, focus, disabled).
■ Consistent use of colors and typography matching the brand guidelines.
2. Recover Password
○ Functionality: Enables users to reset their password by providing their registered
email.
○ Design Requirements:
■ Intuitive flow for entering an email and receiving reset instructions.
■ Visual feedback for errors (e.g., invalid email) and success (e.g., reset link
sent).
■ Loading and disabled states for the "Submit" button.
Since the platform is a closed one, there is no public registration page.

Main Dashboard

3. Clients List
○ Functionality: Displays a list of clients along with their statuses and related
information.
○ Design Requirements:
■ Clearly differentiate statuses (e.g., complete, pending, error, expired)
using distinct colors or icons.
■ Consistent formatting for client identifiers, whether displaying CPF only or
name plus CPF.
■ Highlight "Score" for completed clients in its own column, ensuring
visibility and consistency.
■ A tagging system that allows tags to be added, edited, or removed for
each client.
■ Filter options with clear input styles for CPF, status, date, and tags.
Ensure these filters are intuitive and responsive.
■ Actions for importing a list of CPFs and loading a new client should be
clearly distinguishable, with primary action styling for importance.
■ States for interactive elements such as buttons, filters, and the tagging
system (e.g., hover, disabled, loading).
New Client Screen

4. Add New Client


○ Functionality: Allows users to add a new client by entering a CPF and specifying
how to send information to the client.
○ Design Requirements:
■ A simple input field for typing the CPF with appropriate validation (e.g.,
format, length).
■ Options for selecting a communication channel (e.g., email, WhatsApp).
Design should accommodate the potential addition of new channels in the
future.
■ A text area for writing the message to be sent to the client through the
selected channel, including the ability to insert a link.
■ Clear visual feedback for errors (e.g., invalid CPF, missing message) and
success states.
■ Consistent button styling for "Submit" and secondary actions, with hover,
loading, and disabled states.
Import Clients Screen

5. Import Clients
○ Functionality: Allows users to bulk import clients using a file upload.
○ Design Requirements:
■ A drag-and-drop area for uploading files, with clear visual feedback when
a file is dragged over or uploaded.
■ A link to download a sample file that illustrates the required formatting.
■ A prominent button to initiate the import process, with states for hover,
loading, and disabled.
■ Ensure the design clearly communicates any errors (e.g., invalid file
format) or success messages during the upload process.
Client Details Screen

6. Client Details
○ Functionality: Displays detailed information about a client, including various
attributes derived from their bank account.
○ Design Requirements:
■ Use a table-like format to present attributes such as average income,
expenses, and other financial data clearly and concisely.
■ Include a gauge or indicator that visualizes an overall score or key metric
for the client.
■ Ensure that the table and gauge are responsive and adapt well to
different screen sizes.
■ Provide consistent styling for headers, rows, and data points in the table.
■ Visual feedback for hover or selection states on table rows if interactivity
is involved.
■ The gauge should have clear labeling and appropriate color coding to
indicate different ranges (e.g., good, average, poor).
Tags Management Screen

7. Tags Management
○ Functionality: Provides a CRUD interface for managing tags, allowing users to
view, edit, or delete existing tags, as well as add new ones.
○ Design Requirements:
■ A table layout displaying existing tags and their descriptions.
■ Action buttons for editing and deleting tags, with clear feedback for hover,
confirmation dialogs for deletion, and disabled states where appropriate.
■ A separate input area or modal for adding new tags, including fields for
the tag name and description.
■ Ensure responsive design for managing tags across different screen
sizes.
■ Consistent styling for buttons, inputs, and table rows, with clear
differentiation of primary actions (e.g., "Add Tag") and secondary actions
(e.g., "Cancel").
New Tag Screen

8. Add New Tag


○ Functionality: Allows users to create a new tag by providing a slug and a label.
○ Design Requirements:
■ A simple form with two input fields: one for the slug and another for the
label.
■ Appropriate validation for the slug (e.g., unique, formatted correctly) and
the label (e.g., non-empty, appropriate length).
■ Clear visual feedback for errors in either field.
■ A primary action button (e.g., "Create Tag") and a secondary action button
(e.g., "Cancel") with consistent states for hover, loading, and disabled.
■ Ensure the form design is responsive and works seamlessly on all screen
sizes.
Edit Tag Screen

9. Edit Tag
○ Functionality: Allows users to update an existing tag’s slug and label.
○ Design Requirements:
■ A form similar to the "Add New Tag" screen, pre-filled with the current slug
and label.
■ Validation for the updated fields (e.g., unique slug, proper format,
non-empty label).
■ A primary action button (e.g., "Save Changes") and a secondary action
button (e.g., "Cancel") with appropriate states for hover, loading, and
disabled.
Delete Tag Confirmation Screen

10. Delete Tag Confirmation


● Functionality: Confirms the user’s intention to delete a tag and warns about potential
impacts.
● Design Requirements:
○ A prompt with clear and concise messaging about the consequences of deleting
the tag.
○ A primary action button (e.g., "Confirm Delete") and a secondary action button
(e.g., "Cancel").
○ Use visual cues (e.g., warning icon, red color) to emphasize the seriousness of
the action.
Settings Screen

11. Settings
● Functionality: Provides configuration options for notifications and calibration.
● Design Requirements:
○ A form with checkboxes or toggles for enabling/disabling notifications via email or
webhook.
○ Input fields for specifying the email address and webhook URL when notifications
are enabled.
○ A multi-select or checkbox list to choose which notifications to send (e.g., client
created, client connected, client error, client expired, report ready).
○ A "Save" button for applying changes, with hover, loading, and disabled states.
Calibration Screen

12. Calibration
● Functionality: Allows users to adjust the weights of various parameters affecting scores.
● Design Requirements:
○ Range sliders or similar inputs for specifying the weight of parameters such as:
■ If the user has loans.
■ Recurring income.
■ If the user has extra incomes.
■ If it has a default history.
○ Clear labeling and visual feedback for the current value of each parameter.
○ A "Save" button for applying changes, with hover, loading, and disabled states.
○ Ensure the design is responsive and visually consistent with other screens.
Shared Components

13. Header
● Functionality: Provides branding and user account management.
● Design Requirements:
○ Include the app’s logo and name prominently.
○ Display account-related information such as the logged-in user’s name and an
option to log out.
○ Ensure the header is responsive and scales appropriately across screen sizes.

14. Navbar
● Functionality: Allows users to navigate between key sections of the app (e.g., settings,
clients, tags).
● Design Requirements:
○ Flexibility to position the navbar as a sidebar or within the header, as determined
by the design system.
○ Clear and consistent styling for navigation links, with hover and active states.
○ Ensure responsiveness and accessibility for all screen sizes.

15. Footer
● Functionality: Provides institutional links and access to help.
● Design Requirements:
○ Include links to institutional pages (e.g., About, Privacy Policy) and a help
section.
○ Ensure consistent styling and responsiveness across all screens.

Final Notes on Colors and Typography

We request the designer to choose colors and typography for this design system with the
following considerations:

● Plan for features that display structured data requiring monospace typography.
● Design for actions that are "destructive," ensuring the ability to warn users effectively.

Currently, the colors used are:

● Deep Lemon: #FBC61E


● Brilliant Azure: #2B9EFF
● Palatinate Blue: #413DFF
● Bright Yellow: #FF9F1C
● Outer Space: #444444
● Ghost White: #F8F8FF
● Light Gray: #D4D4D4
● Cultured: #F6F7F9
● Cinnabar: #ED4337

The typographies used are:

● Lalezar
● Roboto

We are open to alternative suggestions that better align with our design goals and enhance user
experience.

You might also like