UI Design
HR App
A mobile app for employees to submit vacation and leave requests directly from their smartphone, with real-time visibility into available balance and the status of every request.
Project Overview
Introducing the Project
A mobile app for employees to submit vacation and leave requests directly from their smartphone, with real-time visibility into available balance and the status of every request.
Role
UI Designer
Duration
20 hours
Tools
Figma, Figjam
Problem Statement
What problem are we solving?
Defining the problem precisely is the first act of design. Without a clearly framed problem, any solution risks answering a need that doesn't actually exist.
Context
In structured organizations, absence management is still often handled through emails, paper forms, or desktop HR software. Employees lack a direct, always-accessible channel to track the status of their own requests.
Problem
Employees don't know at any given moment how many vacation days or leave hours they have remaining, nor whether a submitted request has been approved or rejected. Getting this information requires contacting the HR office or accessing tools that are not optimized for mobile.
How Might We
In structured organizations, absence management is still often handled through emails, paper forms, or desktop HR software. Employees lack a direct, always-accessible channel to track the status of their own requests.
Role & Constraints
Context of this project
Naming constraints isn't a weakness it's what separates an honest design process from one that pretends to have no limits.
Solo project
All phases, research, ideation, design, were handled without a team. Iterations were limited.
Employee-side only
Screens cover only the employee flow. The manager/HR approval panel is out of scope.
No technical integration
The project is not connected to a real backend. Data such as balance and history are representative.
No formal user testing
No testing was conducted with real users. UX decisions are based on best practices and competitive analysis.
I chose to focus on the solidity of the main flow rather than covering all edge cases. In a production context, the next step would be to validate the request flow with target users and design the approval panel as a second sprint.
User Research
Understanding the users
Due to the absence of direct access to real users, I conducted desk research based on usage patterns of existing HR apps and typical employee use cases in Italian corporate contexts.
Personas
Marco Ferretti
34 years old
Goals
Submit a vacation request in a few minutes, without having to open a laptop or contact the HR office.
Pains
He never remembers how many vacation days he has left and forgets to check the status of pending requests.
Laura Bianchi
28 years old
Goals
Monitor all her requests in real time submitted, approved, and expired — without having to ask for updates via email.
Pains
She only receives feedback after the fact via email and struggles to quickly distinguish already-approved requests from those still pending.
Emphaty Map
Marco Ferretti
Thinks and Feels
- "I need to send this request before I forget"
- "I don't know if I still have days available"
- "I hope someone approves it before Friday"
Hears
- "You've already used too many vacation days this year"
- "Send me an email for your vacation request"
- "Requests are handled through the HR office"
Sees
- Colleagues still using email to request vacation
- An approval email notification arriving late
- The shared company calendar with no personal status visible
Says and Does
- Sends a WhatsApp message to HR asking for updates
- Checks balance on a shared Excel spreadsheet
- Forgets to submit the request until the last minute
Laura Bianchi
Thinks and Feels
- "I need to send this request before I forget"
- "I don't know if I still have days available"
- "I hope someone approves it before Friday"
Hears
- "You've already used too many vacation days this year"
- "Send me an email for your vacation request"
- "Requests are handled through the HR office"
Sees
- Colleagues still using email to request vacation
- An approval email notification arriving late
- The shared company calendar with no personal status visible
Says and Does
- Sends a WhatsApp message to HR asking for updates
- Checks balance on a shared Excel spreadsheet
- Forgets to submit the request until the last minute
Competitive Analysis
Exploring the market
The competitive analysis helped me understand what the main HR apps on the Italian market already offer, and where gaps exist that shaped my feature decisions.
3 gaps identified
1
Balance not visible before submission
Many apps don't show the updated balance on the same screen as the form, forcing the user to navigate away to check how many days they have left before filling out a request.
2
No status filtering in legacy apps
Older solutions like Inaz don't allow filtering requests by status, making historical monitoring nearly impossible on mobile without scrolling through long lists.
3
No contextual in-app feedback
Most competitors send only a post-submission email notification. No in-app confirmation message reassures the user immediately, creating uncertainty about whether the action succeeded.
Synthesis
From insights to decisions
The synthesis matrix connects research findings to underlying user needs, making the link between an insight and the feature that resolves it explicit.
Research Insight
Marco doesn't know his balance before submitting and risks requesting more days than he has available.
User Need
Know remaining balance before submitting
Feature
New Request
Research Insight
Marco has no immediate feedback after submitting and doesn't know if the action succeeded.
User Need
Contextual confirmation of successful action
Feature
New Request
Research Insight
Laura can't quickly distinguish requests by status and wastes time looking for pending ones.
User Need
Filter requests by status with a single tap
Feature
Request Management
Ideation
Defining the idea
I chose to structure the solution around two distinct features, each designed for a precise goal, rather than cramming everything into a single screen that would be difficult to navigate.
New Request
A multi-step form that guides the employee in choosing the type (vacation or leave), selecting the date range through an inline calendar, and submitting the request. The remaining balance is visible before the user even starts filling in the form.
Driven by: Marco, who doesn't know his balance and often forgets to submit requests on time.
Request Management
A dashboard showing the total balance of vacation days and leave hours, grouping all requests by status through tabs (Pending, Approved, Rejected) with a separate section for expired requests.
Driven by: Laura, who needs to monitor the status of her requests without depending on email.
Information Architecture
How the app is structured
Mapping the architecture before building screens allowed me to define the navigation structure and make the project's boundaries explicit.
Design Gap Acknowledged:
The manager or HR flow for approving requests was not designed in this sprint. This is a deliberate gap: in a real product, the approval panel would be the second priority sprint without it, the end-to-end flow remains incomplete.
Solution
Designing the solution
The final solution translates the two features into distinct flows, each optimized to minimize the number of steps needed to reach the goal.
#
"New Request" functionality
Driven by: Marco and the balance visibility gap identified in the competitive analysis.
The screen immediately shows the remaining balance for vacation (days) and leave (hours), before the user even selects the type. The inline calendar allows date range selection without leaving the page. Before submitting, a summary card shows the number of selected days or hours and the residual balance after the potential approval, eliminating uncertainty about the impact of the request.
New Request's Screens
The following mockups illustrate how this flow translates into the interface:
#
"Request Management" functionality
Driven by: Laura and the absence of status filters in older competitors.
The main screen groups all requests into three filterable tabs Pending, Approved, Rejected with a numeric badge on the active status. A separate "Expired" section, accessible through a dedicated control, lets users review inactive requests without mixing them with active ones.
Request Management's Screens
The following mockups illustrate how this flow translates into the interface:
Testing Strategy
What I would test next
No formal testing was conducted at this stage of the project. This section outlines the plan I would have followed before a real release.
Round 1 — Concept Validation
Before hi-fi mockups
- Interviews with 3–5 employees to validate the need for balance visibility before submitting a request.
- Comprehension test of the status tabs: do users intuitively distinguish "Pending" from "Expired"?
- Verification that the multi-step new request flow matches the user's mental model.
Round 2 — Usability Testing
On the hi-fi prototype
- Task: "Submit a 5-day vacation request starting October 17th." Metric: error-free completion rate and number of taps.
- Task: "Find your last approved request." Metric: seconds from the main screen.
- Task: "Check how many leave hours you have left after selecting 4 hours." Metric: correct answer without leaving the new request screen.
Key hypothesis to validate:
The main risk is that the inline calendar in the form may feel too bulky on screens smaller than standard iPhone size. If more than 30% of users attempted to close it before completing the selection, it would be necessary to redesign the interaction for example, moving the calendar into a separate bottom sheet.
Learnings
Retrospective
This section collects honest reflections on what worked, what I would do differently, and the most important thing I learned while working on this specific domain.
What worked
Showing the balance on the same screen as the form eliminated one of the main friction points identified in research.
The tab system for request status made the dashboard readable even with many items in the list.
The confirmation screen with an explicit message resolved the immediate feedback problem without adding complexity to the flow.
What I'd do differently
I would have designed the manager panel as well, to validate the full end-to-end flow not just the employee side.
I would have tested the inline calendar with real users before finalizing it, given the complexity of the interaction on mobile.
I would have used different colors or icons to visually distinguish vacation cards from leave cards in the dashboard.
The main takeaway
"Designing for employees taught me that the real problem is never 'submitting a request' it's not knowing what happens after you submit it."
Great design starts
with a conversation
30 minutes. No commitment. We'll figure out together if I can actually help.
© 2026 - Built with 🧡 by Daniele