HireVault
UX Case Study: HR Document Automation SaaS Product
- Domain
- HR Tech / Document Management
- Designed
- July 2024 - November 2024
- Duration
- 5 months (part-time)
- Scope
- Designing a SaaS solution from scratch
- My Role
- Lead UX Designer
- Primary Tool
- Figma
The mark. A vault for documents, drawn plainly so it sits quietly above an interface people use all day.
Introduction
HireVault is a system that automates and simplifies HR paperwork for companies that frequently hire and off-board employees. Instead of manually creating and handling documents, HR teams can use HireVault to do everything digitally, saving time and reducing errors.
Problem Statement
HR teams handle a high volume of paperwork, yet many still rely on manual document creation, email-based approvals, and storage systems. This makes it difficult to maintain efficiency, track signatures in real time, and securely manage sensitive employee records. As hiring scales, these challenges grow, highlighting the need for a more structured, automated, and secure approach.
The problem mapped out. Manual creation, email approvals and scattered storage each feed the next, which is why fixing any one of them alone does not help.
My Role
I worked as the sole designer on this project for 5 months (part-time), focusing on building the product from the organization’s perspective. While some backend systems for document uploads were in place, the product needed a structured design approach to handle HR workflows effectively.
My responsibilities included:
- Research – Understanding how organizations manage HR documents and approvals.
- Ideation – Defining core features, user flows, and interaction patterns.
- Wireframing – Structuring layouts and workflows for clarity and ease of use.
- Design & Handoff – Creating UI components, styles, and high-fidelity screens for development.
The process I worked through. Discover and Define took the longest, because the product only became simple once the workflow underneath it was understood.
1. Discover
In my previous workplaces, I noticed that in early-stage startups and small communities, HR & content teams manually created offer letters and other hiring documents. This made me curious, how do hiring teams actually manage and maintain these documents at scale?
To understand this better, I spoke with professionals in HR & recruitment across different organizations. I asked about their document creation process, pain points, and existing tools to see where the biggest challenges lay.
1.1 User Research
To begin with, I explored the traditional methods companies use for hiring documentation. I reflected on my own experiences, at an early-stage startup, I had directly emailed the HR team, and on one occasion, I even shared my documents via a Telegram DM. This made me curious about how structured or unstructured this process is across different organizations.
To understand this better, I reached out to HR professionals from different company sizes and gathered insights on how they handle document creation, approvals, and onboarding workflows.
Oversees hiring and employee documentation while ensuring company policies are followed.
Responsibilities- Prepare and manage offer letters, NDAs, and other HR documents
- Track hiring progress and ensure all paperwork is completed
- Handle employee records and compliance requirements
Pain points- Repetitive document creation, each hire needs the same paperwork
- Tracking approvals is frustrating, constantly following up over email
Current workarounds- Uses MS Word for templates, sends via email, stores in Google Drive
- Keeps an Excel sheet to track approvals manually
Recent challenges- Misplaced an employee’s ID proof, had to request it again
- Took too long to find a salary slip during a meeting
Oversees the final approval of offer letters, ensures smooth onboarding, and ensures compliance across hiring stages.
Responsibilities- Approve offer letters from the HR team and forward them for signing
- Ensure employees meet compliance requirements during onboarding
- Track whether new hires have read policies before document submission
Pain points- Constantly checking emails to track signed status
- Delayed feedback slows down the hiring process
- Manual Kanban tracking, needs frequent updates as hiring progresses
Current workarounds- Uses ClickUp or Taskade to manually track hiring stages
- Relies on subordinates for progress updates instead of a system
Recent challenges- Missed an admin position in the approval process, causing confusion
- Different approval parties per position leads to miscommunication
Recently cleared interviews and is awaiting onboarding.
Responsibilities- Submit the documents the company asks for
- Meet compliance requirements during onboarding
- Read company policies and handbooks before submission
Pain points- Delayed onboarding email, waited without clarity on next steps
- Document list sent as plain text, attachments emailed manually
- No clear onboarding structure, hard to work out the order of steps
Current workarounds- Replies to emails with attachments
- Uploads to the internal portal if the company has one
Recent challenges- Resent documents several times due to incorrect uploads
- Onboarding delayed by back-and-forth communication
By analyzing the roles and responsibilities of Heena and Harikesh, it became clear that their challenges weren’t isolated cases. Many HR professionals face similar inefficiencies in handling documents, tracking approvals, and ensuring compliance. To break down the problem further, I categorized the key pain points observed during research.
1.2 Pain Points Analysis
To break down the challenges in HR documentation and onboarding, I categorized pain points into two perspectives:
HR & Hiring Team Challenges
The issues faced by organizations in managing documentation.
- Repetitive manual document creation
- No real-time tracking of signed status
- Scattered and insecure document storage
- Manual updates to track approval progress
Employee Onboarding Struggles
The difficulties employees face during the hiring process.
- Delayed onboarding communication
- Unclear document upload requirements
- No structured onboarding flow guidance
- Back-and-forth errors in document submission
1.3 Problem Identification
Refer to the figure below for more context. It highlights the scope of work needed to address these pain points and provides clarity on how the solution should be structured.
Where the problems overlap. The intersection is the part the product had to solve first, since everything else depends on it.
Overall Problems to Address
- Manual document workflows
- Inefficient signature tracking
- Unstructured employee onboarding
- Confusing approval hierarchy setup
- Fragmented document storage
- Lack of real-time progress visibility
1.4 Compliance Research
To design a standardized yet flexible onboarding process, I researched how different companies handle hiring documentation.
- After analyzing multiple mid-sized and large organizations, I identified common steps that appear across most onboarding workflows.
- By eliminating uncommon or company-specific steps, I structured a default onboarding flow that covers essential compliance and hiring requirements. This flow ensures a seamless, automated experience while maintaining adaptability.
- Since every company follows its own process, teams can customize their onboarding by adding or removing steps as needed. This approach keeps the system structured yet flexible, allowing businesses to align it with their internal hiring policies.
The figure below illustrates how common steps were extracted from different company workflows to form a high-level onboarding structure that adapts to various hiring needs.
Common steps pulled from several company onboarding flows. What survived across all of them became the default; what did not became optional.
From research insights, I found that while compliance steps vary across companies, certain core processes remain the same. Based on these patterns, I structured a default compliance flow that covers essential requirements. Teams can adapt it as needed, ensuring both standardization and flexibility.
1. Basic Details
- Input of all personal and residential details
- Mobile number verification via OTP
- Email verification via OTP
2. Identity Verification
- Aadhaar Verification. Insert Aadhaar number, OTP verification, upload front photo of Aadhaar, upload back photo of Aadhaar.
- PAN Verification. Insert PAN number, OTP verification, upload front photo of PAN.
3. Banking Details
- Bank account number and IFSC code input.
- Upload cancelled cheque (auto-extracts details).
- For MNCs: Salary account setup by the company, followed by employee verification.
4. Self-Declaration & Final Confirmation
- Recheck all provided details before submission
- Confirm compliance agreement
- Final OTP verification (Mobile Number + Email)
2. Define
During the Discover phase, I had explored how HR teams handled documentation and approvals. Through research and user stories, I had found clear inefficiencies that slowed down the process and created unnecessary friction.
In this phase, I will define the core challenges I had identified, ensuring the solutions directly address the pain points uncovered.
2.1 User Stories
Neha, an HR Manager, handles offer letter approvals through manual document creation and email-based approvals. When admins request changes, she has to restart the entire process, leading to delays and frustration.
Neha’s story. A change request sends her back to the beginning, because there is no version of the document that can be revised in place.
Insight Taken from the Story
The lack of a structured approval system forces unnecessary rework. No real-time tracking or revision-friendly workflow makes the process inefficient.
Amit, a Hiring Lead, forwards offer letters for approvals. A missed stakeholder causes confusion, forcing him to restart the process manually, leading to delays and accountability issues.
Amit’s story. One missed stakeholder restarts the whole approval chain, and nobody can see where it broke.
Insight Taken from the Story
The lack of automated stakeholder mapping leads to missed approvals and rework. No role-based approval system creates inefficiencies and delays.
Yashvi, an HR team member, struggles to locate and retrieve employee documents across multiple storage platforms. A wrong file submission leads to confusion and accountability issues.
Yashvi’s story. Documents live in several places at once, so retrieval is guesswork and the wrong file reaches the wrong person.
Insight Taken from the Story
The lack of centralized storage and smart search makes document retrieval slow and error-prone. No verification system increases the risk of misfiled documents.
2.2 How Might We?
After uncovering key challenges from my research, I shifted my focus from problems to possibilities. I translated insights into actionable questions, ensuring that solutions would be practical, scalable, and truly user-focused.
By framing the right HMW questions, I created a bridge between discovery and ideation, moving beyond identifying friction points to designing seamless, intuitive workflows. This structured approach didn’t just highlight what was wrong; it set the stage for meaningful improvements. Now, with clear direction, I’m ready to define the most effective design solutions.
Each friction point turned into a How Might We question. Framing them this way kept the next phase focused on the problem rather than on features.
Insight Taken from HMW Analysis
I turned user story insights and pain points into actionable questions. Now, I’ll take the next step, translating these into concrete features for the app.
2.3 Feature Prioritization
Matrix Method (Impact vs. Effort)
After defining key solutions, I had to refine and prioritize features that would have the greatest impact. Not every idea makes it into the final product, only the ones that streamline the user experience, reduce friction, and align with core needs.
To do this, I:
- Listed all potential features.
- Identified the most effective ones based on user impact and feasibility.
- Assigned priority levels to ensure a structured implementation.
Features plotted on impact against effort. The top-left quadrant is what shipped first.
MoSCoW Method (Must-Have, Should-Have, Could-Have, Won’t-Have)
I initially considered arranging these features into phases (1, 2, 3, & 4) but realized that using the MoSCoW method makes it easier to understand and explain. This approach clearly defines what’s essential for the first version and what can be introduced later.
To do this, I:
- Categorized features based on their importance.
- Identified which features are must-haves for launch and which can be introduced later.
- Structured them into clear priority levels to guide development.
The same features sorted by MoSCoW. This is the version I could explain to a stakeholder in one sentence, which the phase model never allowed.
3. Ideate
The Discover phase helped me reveal inefficiencies, while the Define phase helped me structure key problems and priorities. With clear insights and feature direction, I now move into Ideate, where solutions take shape through workflows and design.
I structured the system using HUB layouts, where each HUB served as a dedicated space for key dashboard functions. Instead of scattering features across multiple sections, I grouped them into nodes, ensuring that every action had a clear, logical place.
The system as HUBs. Each HUB owns a set of functions, so a new feature has an obvious home instead of being appended to a menu.
Each HUB contained its own set of functionalities, which later expanded into detailed elements based on user needs. This approach made navigation more intuitive and allowed new features to be seamlessly integrated without disrupting the existing structure.
IA for Template Dashboard
Supports template creation, version control, and role-based access for efficient document handling.
Template dashboard architecture. Creation, version control and role-based access hang off one node.
IA for Document Dashboard
Supports template creation, version control, and role-based access for efficient document handling.
Document dashboard architecture. Every document carries its status and its parties, which is what the list view reads from.
IA for Team Management Dashboard
Handles role creation, permission management, and member actions like assignment, updates, and deactivation.
Team management architecture. Roles are defined once, then permissions and member actions follow from them.
IA for Onboarding Process
Covers document submission, identity verification, and e-signing, ensuring compliance before onboarding completion.
Onboarding architecture. Submission, identity verification and e-signing in sequence, with completion gated on all three.
4. Create
After defining the information architecture and user flows, I moved into the visual design phase. This section showcases the final implemented designs, highlighting how research insights and structural planning translated into functional, user-centered interfaces.
The product is one workflow rather than a set of tools. A document gets written once as a template, filled in as a form, signed by whoever inside the company needs to sign it, and then handed to the person being hired, who finishes their side in the same place. The screens below follow that order.
4.1 The templates dashboard
A template is an ordinary document with its blanks marked. HR uploads the file they already use, an offer letter or an NDA, and the builder turns each blank space into a named field. The dashboard lists every template with who created it and when, so nobody rebuilds one that already exists.
The templates dashboard. Every template with its owner and creation date.
Row actions, kept in the row rather than on a separate screen.
4.2 Building a template
Creating a template starts with the file. Once it is in, every blank becomes a field with a name, and every field is assigned to a party, either the company or the person being hired. Those key value pairs are what the form fills in later, which means the wording of the letter is written once and never retyped.
Naming the template and choosing the file it is built from.
The filled creation step, with the description and source file set.
Reviewing the template with its fields marked on the document.
Switching parties. Each field belongs to whoever is responsible for filling it.
Editing a template. Changes apply to documents created after the edit, so documents already out for signature are not altered underneath anyone.
4.3 The documents dashboard
Every document generated from a template lands here with its status, its type and the people attached to it. This is the screen an HR manager keeps open, because it answers the question that used to take an email, which is where a document has got to.
The documents dashboard, organised by status, type and assigned personnel.
4.4 Creating a document
Making a document is choosing a template and filling a form. The fields defined in the builder appear as inputs, and the PDF updates as they are filled, so nobody opens the document itself to type into it. That is the step that removes the repetitive work Heena described, where every hire meant rewriting the same paperwork.
Selecting the template the document is generated from.
The form built from the template’s fields.
The document preview updating as the form is filled.
4.5 Parties, fields and bulk entry
A document usually needs more than one signature, so the parties are set before the fields are filled. Each party gets the fields assigned to them in the template, and the signing order follows the approval hierarchy rather than whoever happens to open it first. For teams sending the same document to several people, details can be added in bulk instead of one form at a time.
Adding parties. Signing authorities are attached to the document, not to the template.
Filling the fields. Every value maps to a marked blank in the PDF.
Bulk add, for sending the same document to several people at once.
4.6 Sending it out and chasing it
Once the document is complete it goes out for signature, and the status is visible from the dashboard instead of an inbox. Reminders can be sent to any party still outstanding, which is the part that replaces Harikesh checking email to find out who has signed. I also designed the email the party receives, since that message is the product for anyone outside the company.
Viewing the document with its current signing status.
Reminding parties who have not signed yet.
The email a party receives, with the document and the action in one place.
Signing complete. The document is closed and stored against the employee record.
4.7 The new hire’s side
The last part of the workflow belongs to the person being hired. They complete KYC, agree to the terms, and upload their documents in the same tab rather than replying to an email thread with attachments. That is the problem Vaibhav described, where a plain text list of requirements turned into repeated uploads and a delayed start.
The consent form. Terms are read and agreed before anything is collected.
Identity verification, following the compliance flow set out in section 1.4.
Document upload, with the required list shown as a checklist rather than prose.
Confirmation of the details before submission.
Completion. The hire is onboarded and every document sits against their record.