erify, they should have

a tool tip KYC Sections

v

telling them
what theyThisare viseran
ifying ,
anatomy of the sections for the KYC.

Design System
Phone Number Verify phone number examples are Phone
number, email, BVN, etc

Loading state


Documentation
Shows that the email being
mail.com checked or validated The section header: 

This is the head text of section, captures a
summary of the details required in the
section.
r and email The Section des
hone n umbeI rwas assigned
fr ur ther task
and con i m yo . to document the KYC component at
email add ess Describes the se
Verification Pending
 what we’d collec
Shows that the email verification is
pending. could be as a result of
Phone Number Verify phone number User.clicking “Let us help” on the

verification modal

This is the header text here

ess Accompanied by a body text to show to explain what is ex

r and email
hone n umber and confirm your email address.

Verification Successful

Phone Number Verify phone number Shows that the email has
been verified.
O ptional

O ptional Input Fields:


Input fields can
The Input Fields:

sometimes be optional,
This can be other inp
when optional we add
what the requiremen
the text description
See Component In U se under the input field to
show that its optional

See Component In U se
er’s contact address. House no. and street address field can contain alphabets, numbers, spaces, and
mmas, periods, and hyphens (e.g., 123 Main St., Apt 4B). Also includes a dropdown for the country
Name
Requirement

Was it a
challenge?
The entire engineering team would work with what I have
documented, the design team would reference it for future use so... 

Yes it was, but I love challenges so…why not.

This is the header text here

Accompanied by a body text to show to explain what is expected

Optional
Getting Started...
Rayna UI's component documentation. I took reference from there…solid stuff!
The Basics...
The first basic thing that’s needed is an understanding of the use of each
components. 



Being able to describe the functions of respective parts of the components and
being able to define how they can be used and reused.

SunFi Dynamic KYC documentation

Choosing the right component is essential for optimal functionality and user experience. Each component type are used in
specific scenarios. Below is a guide to help determine the best component for the best use.
Here’s an

Example
The KYC Module is used to describe a module of the KYC. Think of modules like

stages…

Header text K Y C s tat u s

Accompanied by a body text to show to explain what is expected

Header text

Accompanied by a body text to show to explain what is expected

Header text

Your identity verification are required to verify your identity.

KYC modules

This is an actionable Card, designed to guide users directly to the specific module they need to

complete tasks. It includes visual elements to keep users updated on their status, along with icons

to describe the module and prompt them to click.

The header text: 


Describes the particular module of the KYC

Status: 


Indicates the status of the what’s been done by the user,

doesn’t include the tooltip when there’s no need for further tips.

Header text K YC s tat u s

Accompanied by a body text to show to explain what is expected

The Description:
 The CTA Icon:


Describes what we will need the user to do in this module. Serves as a prompt for the

user to know the card is

Icon:
clickable; The entire card is

representing the header text of the card. clickable, this is just a prompt.

Header text

Your identity verification are required to verify your identity.

The Checked Icon:

This represents the module of the KYC

when it’s completed.

Soo..like I
mentioned earlier….
The understanding of exactly how the

entire component works from atoms

to molecules to the element itself is

one key thing you’d need to properly

document stuff...
A few
tips...
So a few tips to be able to document stuff…

Understand the “what” “how” and “why” of the component.

Ensure to clearly describe the function of each part of the component.

Ensure to document how they can be used in multiple states 


(e.g The default state, in progress, completed)

Add the link to use cases of the component.

One step you should not miss is Asking Questions..


If you need to clarify anything please do…

don’t document beans (In this context, something that’s not relatable)
 /ˈtʃɪəz/
Feel free to comment another tip that can
help with design system documentation.