RELIANCE JIO • HR OPERATIONS PLATFORM

JIO WORKSMART

Designing the handoffs between people, decisions, and the work still left to do.

As the product designer for Jio WorkSmart, I translated a fragmented HR exception process into a shared interaction model for six roles. This is the story of how I mapped responsibility, designed for missing information, and separated approval from operational completion.

ROLE Product Designer
CONTEXT Reliance Jio Enterprise HR
STATUS Actively Shipped & In Use
WorkSmart reporter dashboard and approval review presented on two phones
Reporter hub and approver workspace · Device mockup

Explore the original interface screens throughout the case study.

01 CONTEXT

A fragmented HR process where context and responsibility had to survive repeated handoffs.

02 MY ROLE

Product design across role mapping, interaction flows, decision hierarchy, and supporting states.

03 KEY DECISION

Preserve context through clarification, and give operational completion its own endpoint.

04 OUTCOME

Implemented and used internally. A reflection on designing continuity between people.

A design case study: problem framing, modelling, interaction decisions, and reflection. Original screens illustrate the final design; interface values are not project outcome metrics.

01 / FRAMING THE PROBLEM

The difficult part was the handoff, not the approval button.

WorkSmart began with a fragmented HR exception process: requests, supporting documents, follow-ups, and decisions moved between corporate and regional teams. My design problem was to keep a request understandable as responsibility changed hands.

As the product designer, my scope covered role-based interfaces, workflow mapping, clarification paths, decision support, and operational completion. I framed the work around three questions: what does this person need to know, what can they decide, and who needs to act next?

MY DESIGN APPROACH
  1. Frame the handoffsLocate where context and responsibility can be lost.
  2. Map roles and statesSeparate each person’s decision from the request’s status.
  3. Design the exceptionsCarry missing evidence and responses back into review.
  4. Resolve the interfaceTranslate the model into request cards, actions, and feedback.

Retrospective summary of the design logic, illustrated by the final design artifacts below.

DESIGN REASONING

Structure the request before it reaches a reviewer.

I separated request classification from the detailed evidence form. The design makes category selection the first commitment, then asks for the facts needed to assess that kind of exception.

Tradeoff: A longer intake can feel demanding. Grouping the questions into stages gives that effort a clearer sequence.

01 · Choose the request type
01 · Choose the request type

Separating classification from evidence gives a complex intake a clearer sequence.

HRBP - Create new request.pdf · Design artifact
02 · Capture the evidence
02 · Capture the evidence

The grouped questions translate the information needed for a decision into the intake structure.

HRBP - Create new request.pdf · Design artifact
03 · Confirm submission
03 · Confirm submission

A request ID connects submission feedback to later follow-up.

HRBP - Create new request.pdf · Design artifact
02 / MAPPING RESPONSIBILITY

Six roles meant six decision contexts—not six unrelated products.

I used role and responsibility mapping to organize the experience. The reporter needs to raise and follow up; the validator needs to check evidence; the approver needs to decide; the Action Owner needs to execute. Request viewers and the central team need visibility without the same decision controls.

The design tension was consistency versus relevance. I kept a recognizable request summary across roles, then changed the available actions and overview information according to responsibility. That preserved context without presenting every control to every person.

DESIGN REASONING

Keep the request recognizable; change the action layer.

A validator can assess or ask for information, while the central team can monitor and export. The common record connects those experiences.

Tradeoff: Role-specific views introduce more states to maintain. Reusing the request structure limits unnecessary variation.

Validator · Assess the request
Validator · Assess the request

A shared request summary preserves context while the action layer reflects the validator’s responsibility.

Validator Screens.pdf · Design artifact
Validator · Record the assessment
Validator · Record the assessment

Questions and remarks make the assessment explicit before the decision is committed.

Validator Screens.pdf · Design artifact
Central team · Monitor the queue
Central team · Monitor the queue

Oversight uses a different hierarchy from review: queue condition comes before individual decisions.

Central team view.pdf · Design artifact
Central team · Review and export
Central team · Review and export

The common request pattern carries through to oversight without importing approval controls.

Central team view.pdf · Design artifact
03 / DESIGNING THE EXCEPTION

Missing information became a loop I had to design end to end.

A straight approval flow was insufficient for requests that arrived with incomplete evidence. The design needed to preserve the work already done while making the missing information someone’s next action.

I treated clarification as a sequence with four connected parts: a question addressed to a person, a visible response task, a reply with evidence, and a return to review. The original question and received response remain together so the reviewer can recover context.

THE CLARIFICATION MODEL
  1. AskName the recipient and the missing information.
  2. AssignSurface a response task in the reporter’s queue.
  3. RespondKeep remarks and supporting documents together.
  4. ResumeReturn the evidence to the reviewer’s decision context.

Retrospective summary of the design logic, illustrated by the final design artifacts below.

DESIGN REASONING

Preserve the request through uncertainty.

The same request carries the clarification history instead of requiring a fresh submission. This was the central interaction decision in the case study.

Tradeoff: The loop creates more intermediate states than approve or reject. Clear queue labels and next actions are necessary to keep it legible.

01 · Ask a specific question
01 · Ask a specific question

Recipient and query fields make the information gap an assigned action.

Validator Screens.pdf · Design artifact
02 · Make the response actionable
02 · Make the response actionable

A visible Resolve action turns an outstanding question into a response task.

HRBP - Create new request.pdf · Design artifact
03 · Respond with evidence
03 · Respond with evidence

Keeping remarks and attachments together preserves the meaning of the response.

HRBP - Create new request.pdf · Design artifact
04 · Resume the review
04 · Resume the review

Showing the response alongside the original query restores context at the handoff.

Validator Screens.pdf · Design artifact
04 / DESIGNING FOR JUDGMENT

A recommendation needed context, not visual authority.

The approval screen contains a system recommendation, but the design still has to support a person making a consequential decision. I placed the recommendation with the request facts rather than making it the sole focus of the page.

The hierarchy keeps the incident summary, requested days, leave status, and supporting detail near the decision. Approval, rejection, and requesting more information remain explicit choices. The separate confirmation gives remarks a deliberate place in the interaction.

DESIGN REASONING

Make the recommendation one input to a decision.

Visible context and explicit actions preserve the distinction between a system suggestion and the approver’s judgment.

Tradeoff: Additional context makes the screen denser. The summary/detail hierarchy lets the reviewer scan first and inspect further when needed.

Context before the decision
Context before the decision

The recommendation is placed with the evidence; explicit choices preserve human judgment.

Approver Screen.pdf · Design artifact
A deliberate confirmation step
A deliberate confirmation step

A separate confirmation creates space for a deliberate decision and its remarks.

Approver Screen.pdf · Design artifact
05 / DEFINING COMPLETION

I separated permission to act from proof that the work was done.

Mapping the downstream work exposed a crucial distinction: an approval does not itself make the operational change. If the interface treated approval as the endpoint, it would hide the remaining responsibility.

I gave the Action Owner a separate completion action and a confirmation that explicitly asks whether the required changes have been made. The wording, remarks, and success feedback reinforce a different endpoint from approval.

DESIGN REASONING

Give operational completion its own state.

The design makes the final handoff visible instead of allowing the approval event to stand in for execution.

Tradeoff: This adds a step for the Action Owner. Its value is accountability; it still relies on the person accurately confirming the work.

01 · Work awaiting execution
01 · Work awaiting execution

The execution queue makes the responsibility after approval visible.

Action Owner Screens.pdf · Design artifact
02 · Confirm the operational change
02 · Confirm the operational change

The wording distinguishes an operational change from an approval event.

Action Owner Screens.pdf · Design artifact
03 · Close the loop
03 · Close the loop

Separate completion feedback reinforces the final state of the interaction model.

Action Owner Screens.pdf · Design artifact
06 / PRESERVING CONTEXT

A compact summary and a deeper history solved different reading needs.

The request card needed to support quick scanning; the case record needed to explain how the request arrived at its current state. I separated those levels of information rather than asking one screen to do both equally.

The list keeps the request recognizable, while the detail view carries roles, dates, remarks, and clarification events. This is progressive disclosure applied to decision history: enough context to find a case, then enough detail to understand it.

DESIGN REASONING

Keep the trail available without loading it into every card.

The expanded history supports continuity when a different person takes over a request.

Tradeoff: Details require an extra navigation step. The summary must retain enough identifying information to make that step predictable.

A compact status view
A compact status view

A compact summary supports scanning without exposing the entire history.

Request View for status and latest update.pdf · Design artifact
A readable decision trail
A readable decision trail

The deeper record preserves the reasoning and events behind the current status.

Request history.pdf · Design artifact
07 / COMPLETING THE INTERACTION SYSTEM

The design had to hold together outside the main flow.

I extended the interaction language to filtering, attachments, and unavailable pages. These states matter because reviewers need to find evidence, reduce a queue, and recover when a destination fails—not only move through an ideal request.

The final design set shows grouped filters with Apply and Clear all, a dedicated attachment dialog, and a recovery action on the error screen. Together they make the supporting interactions explicit enough to carry through implementation.

DESIGN REASONING

Design recovery and supporting tasks as part of the system.

Consistent actions and feedback connect these small interactions to the larger request journey.

Tradeoff: A reusable pattern cannot erase context. Filters still need meaningful category labels, and errors need a useful next step.

Narrow the working set
Narrow the working set

Grouped controls make queue reduction explicit. Placeholder labels remain visible in this source artifact.

Default Filter and Attachment screens.pdf · Design artifact
Keep evidence accessible
Keep evidence accessible

A focused dialog gives supporting evidence its own interaction without crowding the summary.

Default Filter and Attachment screens.pdf · Design artifact
Offer a way back
Offer a way back

Recovery language and a next action extend the interaction design beyond the successful path.

Error Screen.pdf · Design artifact
08 / EXPLORING THE VISUAL IDENTITY

The mark connected the person to the task.

The identity exploration considered workplace, collaboration, and checklist symbols. The resulting mark combines a person with a checklist, tying the visual identity to the same people-and-responsibility theme as the interaction design.

The exploration board and standalone mark show this part of the design process directly. I present them separately from the interface decisions: an identity can make the product recognizable, while clarity still depends on the workflow and hierarchy.

Exploring the visual language
Exploring the visual language

The exploration connects workplace, collaboration, and checklist imagery to the design theme.

Logo Design.pdf · Design artifact
The standalone WorkSmart mark
The standalone WorkSmart mark

The person-and-checklist mark gives the people-and-task relationship a recognizable identity.

Logo Design-1.pdf · Design artifact
09 / IMPLEMENTATION & REFLECTION

My main learning: design the transitions between people.

WorkSmart was implemented and is used internally at Jio. My contribution was the design structure behind that experience: distinct responsibilities, a clarification loop that preserves context, and a completion state beyond approval.

The final screens demonstrate the interaction model; they do not establish a measured reduction in handling time or errors. I would evaluate those outcomes through clarification turnaround, repeated requests for the same evidence, and the time between approval and operational completion.

The lesson I carry forward is to map uncertainty and handoffs as carefully as the main flow. A clear screen matters, but continuity between screens—and between people—is what makes the design coherent.