0
inhale
UX & Product Designer

Esha
More

Experience designer turning complex systems — AI, data, and human behaviour — into interfaces people actually want to use.

Worked on AI-driven products across healthcare, EdTech, and WorkTech, leading research, ideating in Figma, and presenting to stakeholders.

Experience
NSF I-Corps MorphCast Infragistics Tata Power
View WorkContact
The winning team at the Ellis Anti-Slopathon hackathon
UI Design

First Place — Ellis Anti-Slopathon

Designed the UI for The Gift Edit, an AI shopping assistant — and took first place.

Infragistics Honourable Mention Team Lead Award certificate
Design Leadership

Team Lead Award — Infragistics

Led four designers through the Slingshot rebuild at Infragistics.

The Praan AI team at the NSF I-Corps Hub Northeast Region
Design for Growth

Selected for NSF I-Corps

A class project picked for Rutgers' NSF I-Corps customer-discovery programme.

Selected Work

Projects

Four selected case studies — research, design, and measurable impact. Click any to dive in.

Sangam Lite · Tata Power

Redesigned an employee app 10,000 people had, and nobody opened

Found the real blocker in 30 field interviews, then gave on-site staff back an hour a day with NFC attendance.

Enterprise MobileUX ResearchTata Power
Impact30 interviews across 4 regions · 60-min commute saved via NFC · 10+ services unified
View case study →
Sangam Lite mockup
Knight Plan · Rutgers

Rebuilt course registration for 50,000+ students

Cut a 54-point usability score to a passing 84 by redesigning the flow around how students actually plan a semester.

EdTechUX ResearchAccessibility
ImpactSUS 84/100 (up from ~54) · 90% task completion · WCAG AA compliant
View case study →
Knight Plan mockup
Altasparq Aware · MorphCast AI

Made real-time emotion AI readable for clinicians

Turned a raw emotion-recognition feed into a triage dashboard a clinician can act on in seconds.

Emotion AIClinical DashboardMorphCast AI
Impact24% ↑ emotion-recognition accuracy · usability 3→4/5 · WCAG AA compliant
View case study →
Altasparq Aware mockup
Praan AI · NSF I-Corps

Took an AI breathwork coach from zero to a tested prototype

Led research and design across iOS, iPad, and web — and validated the concept at 4.75/5 before a line of code.

Wellness AIiOS · iPad · Web0→1 Product
Impact90%+ task completion in concept testing · 4.75/5 concept score · 21 user interviews
View case study →
Praan AI mockup
FigmaFigJamMiroMazeAdobe CCClaude AIStitchFramerWebflowHTML/CSSJavaScriptLovableCursorFigmaFigJamMiroMazeAdobe CCClaude AIStitchFramerWebflowHTML/CSSJavaScriptLovableCursor
Creative Work

Play

Click a folder to explore creative work.

3D Modelling
4 renders
3D Animation
1 video
Social Media
7 pieces
Vibe Coding
3 live apps
3D Modelling

Product models designed in Blender — form studies and detailed product renders.

Bosch Hand DrillBosch Hand Drill
Hair StraightenerHair Straightener
Electric GuitarElectric Guitar
LG Garment StylerLG Garment Styler
3D Animation

Tamon dispenser — modelled and animated in Blender.

Social Media Design

Brand identity, event campaigns, and social media visuals.

Social
Social
Social
Social
Social
Social
Social
Vibe Coding

Live products I designed and shipped end-to-end with AI-assisted build tools. Each opens in a new tab.

Knight Plan
Rutgers course registration, redesigned
Open live ↗
The Gift Edit
AI shopping assistant (1st place, Ellis Anti-Slopathon)
Open live ↗
Sangam Lite
Enterprise employee app for Tata Power
Open live ↗
Esha More
↗ LinkedIn ↗ Email
About Me

Hi, I'm Esha — an experience designer translating complex systems into clear, intuitive interfaces.

I work at the intersection of UX research, product strategy, and AI — designing for domains where decisions have real stakes: healthcare, education, and enterprise tools.

My approach is research-led and outcome-driven. I run user interviews, build journey maps, test prototypes, and translate findings into design decisions that hold up under scrutiny.

Currently pursuing a Master of Business and Science in UX Design at Rutgers University, building the strategic and systems-thinking vocabulary to work at the business-design intersection.

What People Say

Esha consistently brought thoughtful, user-centred perspectives to every design challenge. Her ability to translate complex requirements into intuitive experiences and present confidently to senior stakeholders set her apart.
Shekar Mudaliyar
Design Lead, Tata Power Company Limited
Working with Esha on the Knight Plan project was a masterclass in research-led design. She ran every interview, synthesised every insight, and built a system from scratch that actually fixed the problem — not just on paper, but in testing.
Pratigya
Collaborator, Rutgers MBS Program
Esha has a rare ability to hold complexity without losing sight of simplicity. Her design intuition, combined with how rigorously she defends decisions with research, makes her one of the most complete designers I've worked with.
Vaibhav Maloo
Collaborator, Rutgers MBS Program
Get in Touch

Let's Build Something Meaningful

Open to full-time UX Designer and Product Designer roles. Research rigour, systems thinking, bias toward clarity.

eshamore346@gmail.com linkedin.com/in/esha-more-111e444
HealthTech · AI Dashboard · MorphCast AI · Sep–Dec 2025

Altasparq Aware

An emotion-aware clinical dashboard that helps therapists and clinicians track patient emotional states using real-time AI — surfacing insights that reduce cognitive load and improve therapeutic outcomes.

UX Design Intern
MorphCast AI
Sep–Dec 2025
HealthTech / AI

UI Screens

altasparq-aware.morphcast.com
Altasparq
1 / 8
Overview — Home Dashboard
Overview — Home Dashboard Overview — Home Dashboard
Live Session — Real-time Analysis Live Session — Real-time Analysis
Analytics Overview Analytics Overview
Patient Detail — Emotion Mapping Patient Detail — Emotion Mapping
Patient Directory Patient Directory
Clinical Schedule Clinical Schedule
Patient History Patient History
Session History Log Session History Log

Design System

Colour Palette

#FFFFFF
Background
#F8F9FA
Surface
#2563EB
Primary Blue
#1D4ED8
Deep Blue
#10B981
Stable / Safe
#EF4444
Critical Alert
#F59E0B
Fluctuating
#1E293B
Text

Typography

DisplayWelcome back, Aris
H2Emotional Trends Across Base
BodySession shows 12% increase in neutral-to-positive transition
LabelAVG. AROUSAL · TOTAL SESSIONS · VALENCE

Components

● STABLE ● FLUCTUATING ● CRITICAL

Before & After

The original MorphCast dashboard surfaced all emotion data at equal visual weight — overwhelming for clinical staff. The redesign introduces clear hierarchy, role-based views, and clinical-grade status colour semantics.

Before
After

Key Design Decisions

Decision 01 — Information Hierarchy

Demoted emotion indicators to a secondary layer — visible on threshold breach. Vitals and session status remain primary; AI emotion data is context, not command.

Decision 02 — Role-Based Views

Three role-based configurations (therapist overview, patient detail, admin) with single-click toggle. Research showed each role needed fundamentally different data density.

Decision 03 — Trust Signalling

Added explainability via facial action unit labels (e.g. "Corrugator Supercilii: LOW") alongside emotion scores. Showing the reasoning reduced dismissal in testing.

Outcomes

24%
Improvement in emotion recognition accuracy
3→4/5
Usability rating improved across all participants
WCAG AA
Full accessibility compliance achieved
Want to go deeper into the process?
ProblemThe GapOpportunityThe PivotResearchDesignResultsReflection
NSF I-Corps · Wellness Tech · 0→1 Venture · 2025–26

Praan AI

How many breathing or meditation apps have you downloaded — and quietly abandoned?

Praan is an AI breathwork companion that listens to your breath and coaches you in real time. We built it as an NSF I-Corps venture — Esha More and Nandini as Entrepreneurial Leads, Vishnu Iyengar as Technical Lead — through 21 customer-discovery interviews that reshaped the product twice. The name says the thesis: Praan, from pranayama, means breath.

UX & Entrepreneurial Lead
NSF I-Corps
21 interviews
iOS · iPad · Web
Problem

Apps tell you to breathe. None of them check whether you actually did.

Home practitioners are flying blind. They follow a video or a fixed timer, but nothing confirms they're doing it right — so doubt creeps in and motivation leaks out. In our interviews, 15 of 21 said they don't know if they're practicing correctly, and 17 of 21 named friction — just starting a session — as their biggest obstacle.

"I still don't know if my abdominal breathing is correct. I just know I feel better."— interview participant

And 11 of 21 had already tried an app and churned. The pattern was unmistakable: what's out there is a content library, not a coach.

The Gap

Everyone teaches poses. No one coaches the breath.

We studied the alternatives — YouTube (13 of 21 used it as their primary tool), Calm, Headspace, Insight Timer. Every one is a one-way content library: it plays at you on a fixed timer and never adapts. And not one integrates breathwork — pranayama — the part of yoga that matters most for the health outcomes people actually came for.

"I don't breathe properly. My doctor pointed it out — really shallow, only using the top of my chest."— interview participant

For one participant, consistent pranayama had effectively resolved their asthma. That's the moat: real-time breath feedback no competitor offers.

Opportunity
How might we

build an app that listens to your breath and responds — the way a real teacher would?

How it works.

Praan uses the microphone to detect your breath cycle and only advances the session's cues once you've actually completed a breath — so a beginner and an advanced practitioner get different pacing from the same session. The camera adds posture tracking. The session adapts to you, instead of you racing to keep up with a timer.

"I'm halfway through my inhale and the instructor is already saying exhale."— the mismatch Praan's adaptive pacing fixes
The Pivot

We were wrong twice — and the interviews told us so.

V1 thesis · a smart mirror

We started convinced the answer was hardware: an AI smart mirror, like Tonal, for pose correction at home. We even built the first app mobile-only, designed entirely around that fixed-display, mirror-first concept.

Praan v1 — Home
Home
Praan v1 — Practice Session
Practice Session
Praan v1 — Analytics
Analytics
Praan v1 — Community
Community
Praan v1 — mobile-only, built around the smart-mirror concept.
Pivot 1 · drop the hardware

Then a yoga instructor told us: "Most of my students, when I'm demonstrating, they're already doing the asana. They don't watch first." A fixed display creates friction before the session even starts — the display was never the value, the feedback gap was. We dropped the mirror for an app and web tool: device-agnostic, lower barrier, and far cheaper using the built-in camera instead of dedicated hardware. 7 of 8 participants said yes to the app; 6 of 8 said no to the device.

Pivot 2 · narrow to breath

We'd also aimed at "any yoga practitioner" — too broad to feel real. The breathing-health signal was overwhelming, so we narrowed to one primary user with one core unmet need: people who want adaptive, breath-responsive coaching they can trust at home. That refocus is why we rebuilt Praan as a responsive experience across phone, iPad, and web — the screens below.

Research

21 interviews, in studios and over Zoom.

21
discovery interviews
15
home-only practitioners
17/21
cite friction as #1 blocker

We talked to practitioners at Broome Street Yoga and remotely. Why they started ranged from physical pain (11/21) and stress or anxiety (9/21) to breathing issues and asthma (7/21). The blockers clustered: starting is the hardest part (17/21), no feedback on correctness (15/21), pacing that doesn't adapt (11/21), and accountability that vanishes at home (10/21). Four archetypes emerged — the pain-driven pragmatist, the stressed beginner, the committed home practitioner, and the serious aspirant. (Full ecosystem map and discovery detail in the deep dive below.)

The Product

Breath-first, and responsive across every surface.

The redesign carries one idea everywhere: the session responds to your breath. Here it is across iPhone, iPad, and web.

Praan iPhone
1 / 13
Landing — Breath. Body. Balance.
Live Session Live Session
Home Home
Browse Browse
Intent Intent
Breath Breath
Circle Circle
Session End Session End
Profile Profile
Settings Settings
AI Feedback AI Feedback
Breath Ring Breath Ring
Summary Summary
Finish Finish
Praan iPad
1 / 10
Home Dashboard
Home Dashboard Home Dashboard
Landing — Breath. Body. Balance. Landing — Breath. Body. Balance.
Camera Setup — Let me see you Camera Setup — Let me see you
Intent Profile — What brings you to the mat? Intent Profile — What brings you to the mat?
Live Session — AI Pose Tracking Live Session — AI Pose Tracking
Circle — Community & Challenges Circle — Community & Challenges
Progress — Consistency Flow Progress — Consistency Flow
Profile — Practice Flow Profile — Practice Flow
Settings — Camera & Preferences Settings — Camera & Preferences
Library — Categories & Trending Library — Categories & Trending
praan.ai
Praan Mac
1 / 10
Home
Home Home
Library Library
Circle Circle
Progress Progress
Live Session Live Session
Studio Dashboard Studio Dashboard
Analytics Analytics
Instructor View Instructor View
Community Community
Settings Settings
Where It Stands
21
Interviews for problem–solution fit
4.75/5
Prototype concept-screening score
90%+
Task completion in concept testing

Next: deeper discovery on breathwork and posture, grant applications to NJII and Y Combinator, then a working prototype and a patent filing on the breath-detection method.

Reflection

Stop trying to include everyone.

Our biggest lesson came from being wrong out loud. Mapping the product to the largest possible audience made the value vague; the moment we narrowed to one user with one unmet need, the whole thing got clearer, more human, and more believable. The interviews didn't just validate the idea — twice, they told us the idea we walked in with was the wrong one. Listening to that is the job.

Design System

Colour Palette

#0D1117
Background
#161B22
Surface
#C8A97E
Warm Gold
#8B7355
Deep Gold
#E8DDD0
Cream Text
#4A7C6F
Teal Accent
#6B4F9E
Violet Accent

Typography

Displaygood morning, Ananya
H2Practice Insights
BodyInhale · 4 counts · Hold · 4 · Exhale · 8
LabelBREATH RATE · FOCUS · STREAK

Components

● Live Breathwork Restore
Want to go deeper into the process?
ProblemThe GapOpportunityResearchRedesignResultsReflection
Contextual Inquiry · EdTech · Rutgers University · Spring 2025

Knight Plan

Remember setting a 7 a.m. alarm just to fight for a seat — only to watch the class you needed turn red before your eyes?

Every semester, 50,000+ Rutgers students run the same gauntlet: a registration system that behaves like a static catalog instead of an advisor. For our Contextual Inquiry course, our four-person team — Sanyam Bhat, Vishnu Iyengar, Esha More, and Vibha Mugwe — set out to redesign it end to end.

UX Research & Design
Contextual Inquiry
Spring 2025
50,000+ students
The end result — at a glance
Live Build
Explore Knight Plan →
Built with Lovable · Rutgers Course Registration Redesign
Open Live App ↗
Problem

WebReg is a catalog, not an advisor — and the work is scattered across five disconnected tools.

Rutgers' Web Registration System shows you courses; it doesn't help you choose them. To plan a single semester, students bounce between WebReg, the Course Schedule Planner, Degree Navigator, SPN requests, and the billing portal — none of which talk to each other. There's no real-time seat count, no conflict detection, and prerequisite chains stay opaque until something breaks.

WebRegCourse Schedule PlannerDegree NavigatorSPN RequestsBilling Portalnone of them talk to each other 😖
"I need to wake up early so I don't miss the registration window."— from our day-in-the-life storyboard

In interview after interview the feeling was the same: stress, not control. Students described registration as something they survived, not something the system helped them do.

The Gap

Two gaps the existing system never closed.

Gap 01 — Discovery

Students don't know what's out there.

They register for what they've heard of, not what actually fits their degree. Nothing surfaces the courses they're eligible for or would benefit from — so good options stay invisible.

Gap 02 — A dated, fragmented interface

Navigation is the real problem.

Actions that belong on one screen are split across separate pages, and the visual language feels a decade behind the rest of a student's digital life.

Opportunity
How might we

turn registration from a stressful transaction into a confident, guided plan?

Two moves answered that: an AI advisor that recommends courses against each student's degree requirements — closing the discovery gap — and a single, unified interface that replaces five tools with one.

Research

Six stakeholders, four contextual models, one emotional throughline.

We ran contextual-inquiry interviews across the whole registration ecosystem — three students, an academic advisor, a registrar staffer, and an IT developer — so our recommendations were grounded in system reality, not just a user wishlist. We mapped findings with an affinity diagram, a day-in-the-life model, a sequence model, and an identity model, then pressure-tested concepts in a Cool Drilldown workshop.

6
stakeholder interviews
4
contextual models
8
usability testers

The throughline: students wanted the system to feel like a supportive partner, not a bureaucratic hurdle. (Full methodology — interviews, affinity mapping, WCAG audit — lives in the deep dive below.)

who we designed for → First-years Seniors Advisors Transfers
The Redesign

We didn't get it right the first time.

Before · the system today
Rutgers WebReg today
5 separate tabs · zero guidance
Rutgers WebReg today: dense, text-heavy, and split across separate pages for actions that belong together.
V1 · our first redesign
cognitive overload here
cute… but off-brand for Rutgers
Knight Plan V1 — Post-login Dashboard
Post-login Dashboard
Knight Plan V1 — Course Registration
Course Registration
Knight Plan V1 — AI Advisor
AI Advisor

Testers told us V1 already beat WebReg — but two things still nagged. The course-registration screen carried too much at once and spiked cognitive load, and the visual style felt quirky and off-brand, like it didn't quite belong in the Rutgers ecosystem.

Final · the version that tested calm, clear, unmistakably Rutgers ✓

So we simplified the registration flow, separated Plan from Enroll, surfaced the AI advisor and prerequisite status up front, and re-grounded the visual language so it reads as a real Rutgers product.

knight-plan.rutgers.edu
Knight Plan
1 / 11
Welcome
Welcome Welcome
AI Advisor — Start AI Advisor — Start
AI Advisor — Registration AI Advisor — Registration
Course Search Course Search
Course Search Grid Course Search Grid
Course Planner Course Planner
Quick Search Quick Search
Registration Confirmed Registration Confirmed
Student Profile Student Profile
Settings Settings
Help & Support Help & Support
Results
SUS leapt 54 → 84 after the redesign
84/100
SUS score — up from a measured 54
90%
Task completion in moderated testing (2.1 min avg/task)
WCAG AA
Full accessibility compliance
"I wish this was the real registration tool."— usability test participant
Reflection

Usability isn't the only thing that has to fit.

V1 taught us that a design can test "better" and still feel wrong. Beating WebReg was never the bar — belonging in the Rutgers ecosystem was. An institutional product earns trust through familiarity as much as through usability, and the fastest way to find that line was to put an imperfect version in front of real students early.

Design System

Colour Palette

#CC0033
Rutgers Red
#F5F5F5
Background
#1A1A1A
Text
#2563EB
AI Accent
#16A34A
Success
#D97706
Warning
#E2E8F0
Border

Typography

H1Course Registration
H2AI Academic Advisor
BodyPrerequisite met · 3 credits · Tue & Thu 10:20am
LabelFALL 2024 · SECTION 01

Components

✓ Prerequisite Met ⚠ In Progress ✕ Not Met
Want to go deeper into the process?
UX Research Project · WorkTech · Infragistics · Sep–Dec 2024

Slingshot

A comprehensive UX research project for Slingshot — Infragistics' data-driven project management platform. Led a team of 4 researchers to evaluate 50+ features and deliver actionable design recommendations that fed directly into the product roadmap.

Lead UX Design Extern
Infragistics
Sep–Dec 2024
🏆 Honorable Mention
Slingshot
About Slingshot

Slingshot is a digital workplace platform by Infragistics that differentiates through embedded data analytics — combining project management, team dashboards, and AI-powered insights in a single tool.

Research Overview

50+
Features evaluated across Slingshot + 3 competitors
12+
Cross-platform use cases from competitive benchmarking
20%
Projected increase in task management efficiency

Key Design Decisions

Decision 01 — Heuristic-First Evaluation

Applied Nielsen's 10 heuristics across 50+ features on web and mobile, producing a prioritised gap analysis that directly guided Infragistics' product roadmap.

Decision 02 — Analytics Discoverability

Analytics features discovered by accident 70% of the time. Recommended contextual prompts surfacing insights at the moment of data entry — context beats discoverability.

Decision 03 — Stakeholder Communication

Structured deliverable as an opportunity-severity matrix. Framing research in effort vs. impact terms made it immediately actionable for the product team.

Outcomes

50+
Features evaluated, gap analysis delivered
Roadmap
Research fed into Slingshot product prioritisation
🏆 Award
Honorable Mention Team Lead — Rutgers MBS Externship
Want to go deeper into the process?
FashionTech · AI Gifting · Ellis Anti-Slopathon · March 2026

The Gift Edit

An AI shopping assistant built as a feature within Bloomingdale's digital experience — turning vague gifting intent into curated, personalised recommendations. 1st Place at the Ellis Anti-Slopathon Hackathon 2026.

UX Designer
Ellis Hackathon
March 2026
🏆 1st Place
Anti-Slopathon Hackathon 2026 Team at Anti-Slopathon
Live Product
Try The Gift Edit →
Built on Stitch · Inspired by Bloomingdale's
Open Live App ↗

UI Screens

bloomingdales.com / gift-edit
The Gift Edit
1 / 8
Entry Point

Design System — Organic Brutalism

Inspired by Bloomingdale's editorial aesthetic — confident minimalism, extreme white space, zero border-radius. The AI stylist feels like a personal shopper at a flagship store, not an algorithm.

Surface Hierarchy — "Stacked Paper" Model

#F9F9F9
Surface (Base)
#FFFFFF
Cards (Lifted)
#F4F3F3
Container Low
#E2E2E2
Nav / Inactive
#000000
Primary CTA
#5E5E5E
Secondary
#8ADB52
Sustainability

Typography

DisplayThe Perfect Gift
H2 (Serif)Curated for Her · Birthday · Under $200
Body (Inter)Tell me about the person you're gifting…
LabelEXCLUSIVE · LIMITED EDITION

Components — Zero Border-Radius Rule

Birthday Anniversary

The Challenge

Finding the right gift is overwhelming — endless scrolling, generic suggestions, decision fatigue. We chose gifting as the target domain. Instead of giving users more noise, The Gift Edit delivers clarity: curated, meaningful gift options tailored to the person, occasion, and context.

Decision 01 — Built-in Feature, Not a Separate App

Designed as a tab within Bloomingdale's existing navigation. Users already trust the brand's curation — the AI builds on that equity rather than asking them to trust something new.

Decision 02 — Three Layered Questions

Who is this for → What's the occasion → What's the vibe. Each narrows possibility space without feeling like a form. Conversational, not transactional.

Decision 03 — Virtual Try-On Integration

For wearable gifts — lets the recipient visualise the gift on themselves before purchase. Reduces return friction and increases recommendation confidence.

Outcomes

🏆 1st
Place — Ellis Anti-Slopathon Hackathon 2026
8
Screens designed and built end-to-end in one day
Live
Product deployed and accessible at the link above
WorkTech · Enterprise Mobile · Tata Power · Jan–Apr 2023

Sangam Lite

Ten thousand people had the app installed. Almost nobody opened it.

The brief I was handed said the navigation was the problem. Thirty interviews across four locations said something harder to hear: the app had been designed around the employees who already had a desktop within arm’s reach — and the people who needed it most were the ones it had never been built for.

This is how a “fix the menu” project turned into a rebuild that gave on-site workers back an hour of their day.

UX Design Intern
Tata Power
Jan–Apr 2023
Enterprise / WorkTech

The Final Design — Version 2

The screens below are the V2 build. Scroll inside the phone on longer screens, or open the full flows underneath to walk any journey end to end.

Sangam Lite
1 / 24
Splash — Sangam Lite
Splash — Sangam LiteSplash — Sangam Lite
Onboarding — Mark Your AttendanceOnboarding — Mark Your Attendance
Sign In — Employee CredentialsSign In — Employee Credentials
Home — Personalised DashboardHome — Personalised Dashboard
Attendance — NFC Tap to Clock InAttendance — NFC Tap to Clock In
Attendance — Ready to ScanAttendance — Ready to Scan
Attendance — Clocked InAttendance — Clocked In
Attendance — History & Working HoursAttendance — History & Working Hours
Task Manager — Your TasksTask Manager — Your Tasks
AI Note — Voice Capture EntryAI Note — Voice Capture Entry
AI Note — ListeningAI Note — Listening
AI Note — Task Created from VoiceAI Note — Task Created from Voice
Task Detail — Voice Source & Due DateTask Detail — Voice Source & Due Date
Task Analytics — Weekly PerformanceTask Analytics — Weekly Performance
Calendar — Week at a GlanceCalendar — Week at a Glance
Leave — Requests & StatusLeave — Requests & Status
Leave — Apply for LeaveLeave — Apply for Leave
Concerns — Raise & TrackConcerns — Raise & Track
Rewards — Peer RecognitionRewards — Peer Recognition
My Services — Unified DirectoryMy Services — Unified Directory
HR Policies — Searchable RepositoryHR Policies — Searchable Repository
Payslips — Monthly & QuarterlyPayslips — Monthly & Quarterly
Social Updates — Company FeedSocial Updates — Company Feed
Profile — Quick AccessProfile — Quick Access
All screens, by flow — 72 screens

Design System

Rebuilt for V2 around Tata Power’s cobalt, with a semantic colour set that had to survive being read in daylight, on a plant floor, by someone wearing gloves.

Colour Palette

#1E4ED8
Primary
#102A74
Deep Navy
#7290E4
Primary Disabled
#1C2437
Text Primary
#64748B
Text Secondary
#E0E3E8
Border
#F1F5F9
Surface
#22C55E
Success
#F59E0B
Warning
#EC4343
Alert

Semantic Surfaces & Status

Present Late Absent Approved Awaiting Declined
High Priority Medium Low Casual Leave Sick Leave Emergency
Every status carries a colour and a word. Nothing in the app depends on colour alone — a decision that came straight out of testing with employees on a bright plant floor.

Onboarding Illustration Tints

#D3F3DF
Attendance
#FDECCE
Tasks
#E8D5F7
Performance
#D2DCF7
Payroll

Typography

DisplayGood morning, Jane 👋
H2Task Manager · Analytics
Numeric08:30 hrs
BodyCheck In 09:30 AM · Check Out 06:00 PM
LabelOverdue · Today · Upcoming

Components

🎙 AI Note NFC Tap Weekly ▾

The Objective — adoption, not navigation

Tata Power had already built and shipped Sangam to more than 10,000 employees. The business ask was simple: get people to use it. Their working theory was that the app was hard to navigate.

Before I spoke to a single user, I audited the existing IA, ran a heuristic evaluation against Nielsen’s ten, and benchmarked four enterprise platforms — Workday, Microsoft Viva, SAP SuccessFactors and ServiceNow Mobile. That surfaced the reframe the whole project ended up hanging on: the best platforms were destinations. Sangam was a directory. It was a menu that handed you off to ten separate tools, each with its own login. Fragmentation — not menu labels — was why people gave up.

So the objective changed shape. Not “make the app easier to navigate,” but make the app the place the work actually happens.

The Research — 10,000 employees, two very different realities

I ran a pilot with five employees first, purely to find out whether my questions were any good. They weren’t, entirely: six questions produced nothing usable and were cut, and four new ones went in that got at what people actually did during a shift rather than what they thought of the app.

The main programme was 30 interviews across four user groups and four locations — 10 on-site workers at the Trombay plant, 10 corporate users at the Dharavi office, 5 remote employees by phone from Mpl and Bhira, and 5 people who had never opened the app at all. Each group got its own version of the guide.

Two pictures came back, and they barely overlapped. Corporate employees had a desktop within arm’s reach all day, preferred the web portal, and only opened the mobile app when they were travelling or on leave. On-site employees moved between plants, buildings and shifts — and the app ignored essentially every part of that day. Meanwhile non-users pointed at data privacy and battery drain, and anyone over 45 told me plainly that typing on it was a chore.

The Decision That Reordered Everything

Both groups were real users. Only one of them was actually blocked. Corporate staff weren’t avoiding the app because it was badly designed — they simply had a better tool three feet away. On-site staff had no alternative at all, and the app didn’t serve them.

So I made the call to treat on-site employees as the primary persona, and everything downstream fell into place behind it: which features got built, what sat at the top of the home screen, how big the tap targets were, and why voice input stopped being a nice-to-have.

I synthesised the interviews into four personas to keep the team honest about the range — Aditya (lead engineer, on-site, 34), Eshwaran (retiring manager, 58, low tech literacy), Rohan (graduate trainee, 22, power user) and Kajal (HR manager, 42, form-heavy). Aditya drove the roadmap; Eshwaran set the accessibility floor.

Four Insights That Became the Product

01

Attendance was a walk, not a task

On-site workers were spending 20–30 minutes walking back to a desktop terminal to clock in, and again to clock out. Over an hour of a shift, gone to a form.

02

The task list was a paper notebook

People carried notebooks between plants. Entries went missing, got left behind, or never got written down — and the first 30 minutes of every day went to rebuilding the list.

03

Safety info was three buildings away

SOPs, policies and compliance documents were needed on the floor, in the moment. They lived on a desktop portal that on-site staff could rarely reach.

04

One home screen for 10,000 jobs

The app carried 25+ services, but any given person used about four of them. Everyone got the same undifferentiated wall of tiles.

How might we
design a personalised mobile experience that gives employees their time back, supports the realities of field work, and brings the workflows people actually need into one place?

Ideation — where the answers came from

Card sorting with 8 employees, mixed on-site and corporate, told me how people group these services in their heads rather than how the org chart groups them. A consistent five-cluster model came out — Attendance & Tasks, My Services, Social, Profile, and Search/Notifications — and it became the navigation backbone unchanged.

Round robin with 6 employees and interns tackled the three hardest features: the task manager, the voice assistant, and the social feed. Giving everyone equal airtime surfaced ideas I would not have reached alone — the gamified task manager with weekly performance stats came out of that room, and it was the concept people got most animated about.

MoSCoW with stakeholders triaged 25+ requested features into Must / Should / Could / Won’t. It is the least glamorous artefact in the project and probably the most useful — it is the reason the office locator and stationery portal are not in V2, and it gave me something defensible to point at when a late feature request appeared.

Wireframes covered five primary flows and were paper-tested with 5 participants before any visual design happened. That caught three IA problems while they still cost nothing to fix.

From Version 1 to Version 2

V1 was the first high-fidelity pass — structurally sound, but still shaped like the old app. Testing and a second research round pushed it somewhere much more specific.

Home
Version 1 Home — version 1

A wall of equal-weight cards. Everything competed for attention, so nothing won.

Version 2 Home — version 2

Attendance status first, then today's tasks. The four things people open daily sit above the fold.

Attendance
Version 1 Attendance — version 1

A check-in button that still assumed you were sitting at a desk.

Version 2 Attendance — version 2

NFC tap at the gate, with manual fallback — plus history and working hours in the same view.

Tasks
Version 1 Tasks — version 1

A daily planner you had to fill in by hand, on a phone, after a shift.

Version 2 Tasks — version 2

Priority-sorted tasks with a voice button — speak it once, the task writes itself.

Leave
Version 1 Leave — version 1

Balances up top, requests buried below, status hard to scan.

Version 2 Leave — version 2

Status-coded requests, filterable by leave type, grouped by month.

Two changes came directly out of usability testing rather than my own judgement: icons went from 20px to 28px across the board after older users struggled to hit them, and a Help & Benefits section was added to the home screen because people kept asking where the manual was.

What Actually Changed

NFC attendance

NFC attendance

On-site staff tap their phone on readers already installed at every plant gate. Manual punch stays as a fallback, and clock-in history plus working hours live in the same screen instead of a separate portal.

~60 min returned per person, per day
AI note-taking

AI note-taking

Hold the mic, say what needs doing, and the app transcribes it, suggests a title, assigns a priority and sets a due date. It replaced the paper notebook people were carrying between plants.

No notebook, no morning planning block
Leave & approvals

Leave & approvals

Requests are colour-coded by status and filterable by leave type, so an employee can see where every request stands in one glance — and a manager can clear a queue without opening four screens.

Approval status readable at a glance
A home screen that knows you

A home screen that knows you

Attendance status sits at the top because 22 of 30 interviewees said it was the first thing they touched each morning. Below it: today’s tasks, announcements, and the services that person actually uses.

25+ services, four that matter first

Outcomes

30
Interviews across 4 user groups and 4 locations, plus a 5-person pilot
60 min
Returned to each on-site employee per day via the NFC attendance proposal
10+
Enterprise services, and their separate logins, unified into one app

What I’d Do Differently

I accepted the business framing for longer than I should have. The first two weeks went into navigation and IA because that was the brief, and the competitive analysis had already hinted the problem was structural. If I ran it again I’d get into the field in week one and let the research decide what the project was about.

I’d also push harder on measurement. The 60-minute figure is a solid estimate built from interview data and the existing NFC infrastructure, but it is an estimate. Instrumenting the V1 pilot before designing V2 would have given me before-and-after adoption numbers instead of a projection — and on an internal tool where the business case is adoption, that is the number that closes the argument.

Want to go deeper into the process?
Altasparq Aware · Deep Dive

Research & Process

A full walkthrough of how I approached redesigning a complex AI dashboard for clinical use — from heuristic evaluation through to stakeholder presentation, with the design decisions that shaped the final product.

Phase 1 — Heuristic Evaluation

I started by running a structured evaluation of the existing MorphCast platform against Nielsen's 10 Usability Heuristics. Every screen was audited individually: I logged violations, rated severity (1–4), and estimated the frequency of user exposure to each issue.

12 violations identified, with 5 rated severity 3 or 4. The most critical: inconsistent system status (users couldn't tell if the AI was actively analysing), clinical language that didn't match how nurses speak ("valence" instead of "emotional tone"), and no error recovery path when a face scan failed mid-session.

This gave me a prioritised list before speaking to a single user — which meant my interviews could focus on lived experience rather than cataloguing obvious interface problems.

Phase 2 — Contextual Interviews (n=5)

I recruited 5 professionals across three user types: educators using MorphCast in classroom settings, clinicians in therapeutic contexts, and researchers running controlled studies. Sessions were 45–60 minutes, combining a semi-structured interview with observation of their current workflow.

The most important insight didn't come from what users said — it came from watching. Clinicians were running two monitors simultaneously: MorphCast on one screen, patient notes on the other. They'd glance at emotion data, then manually type what they saw into a separate notes field. The tool was creating work instead of reducing it.

After affinity mapping across all sessions, three themes emerged: (1) information overload at the point of decision, (2) lack of trust in AI scores without explanation, and (3) role-specific needs being ignored — a charge nurse and a bedside nurse are doing completely different jobs but seeing the same screen.

Phase 3 — Visual Design Decisions

Live Session UI

The redesign moved from a dark, data-dense aesthetic to a clinical-grade light UI. Key visual decisions:

Colour semantics: I introduced a strict traffic-light severity system — green (#10B981) for stable, amber (#F59E0B) for fluctuating, red (#EF4444) for critical. This replaced arbitrary colour use in the original and gave nurses an immediate visual vocabulary they could read without reading text labels.

Patient Detail UI

Information hierarchy: Emotion data was visually demoted — smaller, secondary positioning. Critical clinical metrics (name, session status, most recent alert) occupy the top-left quadrant of every card, matching the direction nurses said their eye naturally moves.

Explainability layer: The AI emotion score is now accompanied by a micro-tooltip showing the specific facial action unit contributing to the reading (e.g. "Corrugator Supercilii: LOW"). This was one of the highest-impact decisions — during testing, it was the single feature that shifted nurse responses from sceptical to engaged.

Typography: Switched from a display-weight custom font to Inter — chosen for legibility at arm's-length from a monitor under low-light conditions. Font sizes were bumped up 2pt across the board based on observation that many clinical staff are 40+ and working in dim rooms.

Phase 4 — Prototype & Usability Testing (n=5)

I built a high-fidelity Figma prototype covering the three primary workflows: patient overview scan, individual session deep-dive, and alert configuration. Testing used a think-aloud protocol with task completion measurement and SUS administered post-session.

Key results: usability rating improved from 3/5 to 4/5 across all participants. The role-switcher (a new feature I introduced) had 100% discoverability in testing — all participants found it without prompting. The explainability tooltip reduced "I don't trust this" responses from 4/5 participants to 1/5.

One critical finding: participants initially missed the alert threshold configuration because it was nested under a settings icon. I moved it to a persistent sidebar element in the final iteration, and re-tested with 2 participants to confirm discoverability improved.

Phase 5 — Stakeholder Presentation

I delivered a 45-minute research readout to the MorphCast AI product and executive team. The format was: problem framing → research evidence → design decisions → prototype walkthrough → prioritised recommendations matrix.

The recommendations were structured as a 2×2 (impact vs. effort) so the product team could immediately see what to address in the next sprint vs. what to plan for roadmap. Three of five top recommendations were incorporated into the next development sprint, including the role-based dashboard configuration and the explainability tooltip.

Praan AI · Deep Dive

Research & Process

From 21 user interviews to a cross-platform design system — how research-driven pivots and a trust-first AI interaction model shaped every design decision in Praan AI.

Phase 1 — NSF I-Corps Customer Discovery

The project began inside the NSF I-Corps Northeast Hub at Rutgers Propelus. The I-Corps methodology is built around one principle: get out of the building. Before designing anything, I conducted 21 in-depth user interviews with yoga practitioners (beginner through advanced), yoga instructors, and studio owners — one of the highest interview counts in the cohort.

Interview structure: each session was 30–45 minutes, semi-structured, focused on jobs-to-be-done. I wasn't asking about product features — I was asking about the last time they had a frustrating yoga experience, what they wished they'd known, and what feedback they most wanted during a session but couldn't get.

Key finding from discovery: the barrier to feedback isn't the absence of a teacher — it's the vulnerability of being corrected. Practitioners wanted guidance that felt like observation, not instruction. This became the central AI interaction principle.

Phase 2 — Assumption Testing & Hardware Pivot

The original concept was a smart mirror — a hardware product with embedded camera and display. Before investing in the concept, I designed a rapid assumption test:

I asked participants two questions in sequence: (1) "Would you pay $800 for a smart mirror that gives you real-time yoga feedback at home?" — 6 of 8 said no. (2) "Would you use a camera-based AI coach built into an app on your existing iPad?" — 7 of 8 said yes.

The pivot wasn't a gut decision — it was a research output. Removing the hardware barrier without losing the core value proposition (real-time, personalised, judgment-free feedback) was the key insight that shaped the entire product architecture.

Phase 3 — Cross-Platform Design System

Live Session iPad

Designing across iPhone, iPad, and web required a strict component hierarchy. The system was built mobile-first but iPad-primary — research showed that iPad was the dominant use context for live sessions (stable surface, large viewport for pose visibility).

Visual language decisions: The dark, near-black (#0D1117) background was a deliberate choice. Yoga is an intimate, low-stimulation practice. A dark UI reduces visual noise and keeps attention on the practitioner's body, not the interface. The warm gold (#C8A97E) accent was chosen over blue or green specifically because it doesn't read as medical or clinical — it feels earthy, embodied, intentional.

Home Dashboard iPad

Typography: Light-weight (200–300) DM Sans headings with tight tracking for the session UI — minimal text surface so the practitioner's attention stays on movement, not reading. The "good morning, Ananya" personalised greeting was a deliberate warmth signal: the app knows you, not just your account.

AI feedback design: The skeleton overlay (teal joint tracking lines) was the most technically constrained design problem. It needed to be visible on all skin tones and backgrounds without obscuring the practitioner's form. I tested 6 colour options and contrast ratios before landing on the teal-on-dark combination.

Phase 4 — Onboarding as Trust Architecture

Camera Setup

The onboarding flow was designed around a single principle: earn camera access, don't demand it. Practitioners who were hesitant about AI surveillance during intimate practice needed to experience the value of breathwork guidance (no camera required) before the camera ask.

The Camera Setup screen ("Let me see you") was designed to feel like a studio setup moment, not a permissions prompt. The setup checklist (Good lighting ✓, Full body in frame, Clear floor space ✓) frames camera use as a collaboration, and the Privacy First note — "Your camera feed is processed locally on this device. No video data is ever uploaded or stored in the cloud" — directly addressed the most common concern raised in interviews.

Phase 5 — Concept Testing

The prototype was tested with 5 participants in a moderated concept screening session. Metrics: value proposition clarity (did they immediately understand what the product did?), task completion rate, and desirability score.

Results: 4.75/5 concept screening score. 100% of participants immediately grasped the core value proposition. 90%+ task completion across all primary flows. The most-praised element was the AI coach feedback tone — "It felt like it was noticing, not judging" was a direct participant quote.

Knight Plan · Deep Dive

Research & Process

A complete breakdown of the Contextual Design methodology I used to redesign Rutgers WebReg — from 6 stakeholder interviews through affinity mapping, journey modelling, and WCAG auditing to a tested, accessible redesign.

Phase 1 — Stakeholder Interviews (n=6)

I recruited 6 stakeholders across the registration ecosystem: 3 undergraduate students (first-year, sophomore, senior), 1 academic advisor, 1 registrar staff member, and 1 IT developer who maintained WebReg. Sessions were 20–30 minutes, semi-structured, using Contextual Design interview technique — observing participants in their natural environment (at their desk, screen sharing the actual WebReg interface).

This mixed stakeholder sample was deliberate. Students told me what was broken from the front end; the registrar told me why certain constraints existed on the back end; the IT developer explained what was technically feasible to change. Understanding all three perspectives meant my recommendations were grounded in system reality, not just user preference.

Direct quote from a first-year student: "What aspects of WebReg did I find most challenging? Almost everything on my first session — there's no guidance at all."

Phase 2 — Affinity Mapping & Contextual Models

Interview data was organised using Affinity Diagramming in Figma — I converted 120+ data points from interview notes into individual sticky notes and grouped them into themes through iterative clustering. The affinity wall surfaced 4 primary themes: System Fragmentation, No Real-Time Feedback, Lack of Guidance, and Demand for AI.

I then built four Contextual Design models: a Sequence Model (every step a student takes from identifying a course to confirming registration), an Identity Model (how students see themselves relative to the registration system — mostly confused and anxious), a Day-in-the-Life Model (what else is competing for their attention during registration week), and a User Environment Design (the full information architecture as currently experienced).

The most striking finding: students were navigating an average of 5+ separate platforms during a single registration session (WebReg, the course catalog, degree audit, RateMyProfessors, and a group chat). The system fragmentation wasn't just a UX problem — it was causing real decision fatigue at a high-stakes moment.

Phase 3 — Heuristic Evaluation & Accessibility Audit

I ran a dual evaluation: Nielsen's heuristics and WCAG 2.1 AA. The heuristic evaluation identified 12 violations, with the most severe being: no system status visibility (students couldn't tell if WebReg was processing their request or frozen), error messages that identified what went wrong but not how to fix it, and no help documentation that was actually findable.

Knight Plan Welcome

The WCAG audit found colour contrast ratios as low as 2.1:1 on error messages (WCAG requires 4.5:1), form fields without accessible labels, and session timeout with no warning. 14 of 26 applicable checkpoints were failing. For a public university system legally required to be accessible, this was a critical finding — I framed it as a compliance risk in the stakeholder presentation, not just a design issue.

Phase 4 — Visual Design Decisions

AI Advisor

Colour system: Rutgers Scarlet (#CC0033) anchors the brand throughout — it's the one colour every Rutgers student immediately recognises. But the error and status system uses a separate semantic palette: green (#16A34A) for success, amber (#D97706) for warnings, blue (#2563EB) for AI Advisor interactions. Keeping AI interactions visually distinct from core registration actions was a deliberate trust decision — students should always know when they're talking to a system vs. an AI.

Prerequisite status system: The three-state badge (✓ Prerequisite Met / ⚠ In Progress / ✕ Not Met) was the highest-impact visual design decision in the project. In the original system, prerequisite information was buried in a text description. Moving it to a persistent, colour-coded badge on the course card eliminated the most common error type entirely — students stopped adding courses they couldn't enrol in.

Course Search

AI Advisor visual language: The advisor uses blue (#2563EB) exclusively — distinct from the Rutgers Red — with a conversational, left-aligned chat pattern. The "Talk to an advisor" escape hatch is present on every AI touchpoint. This was an ethical design decision: the AI handles recommendations, but a human advisor is always one tap away.

Phase 5 — Prototype & Usability Testing (n=8)

I built a high-fidelity Figma prototype covering all primary registration flows: course search, adding to cart, the AI advisor conversation, and registration confirmation. Testing used a think-aloud protocol with 8 participants: 4 undergrads, 4 graduate students, split between in-person and Zoom sessions (30–45 minutes each).

Registration Confirmed

Results: 9 of 10 participants completed all tasks without assistance. Average SUS score: 84.2 (up from an estimated 54 on WebReg — based on a retrospective SUS I had participants complete after the session). The one failure case: a participant found the prerequisite indicator label text ambiguous — "In Progress" could mean either "currently enrolled in the prerequisite" or "prerequisite completion is in progress." I revised the label to "Prerequisite In Progress" and re-tested with 2 participants to confirm.

Slingshot · Deep Dive

Research & Process

How I led a 4-person UX research team to evaluate 50+ features across Slingshot and 3 competitors — and turned the findings into a product roadmap recommendation that earned an Honorable Mention at the Rutgers MBS Externship.

Phase 1 — Cross-Functional Team Lead

I was the Team Lead for a group of 4 UX researchers across a 12-week externship with Infragistics. My responsibilities went beyond individual research tasks: I owned the research plan, assigned workstreams, set quality standards, ran weekly team syncs, and was the primary contact for the Infragistics product team.

The team was split into two parallel tracks: competitive analysis (2 researchers) and heuristic evaluation (2 researchers, including me). I designed a shared evaluation rubric so findings across both tracks could be directly compared — critical for the final synthesis stage.

Phase 2 — Competitive Analysis (50+ Features)

We evaluated Slingshot against 3 direct competitors: Asana, Monday.com, and Notion. The scope was 50+ features across both web and mobile platforms, mapped against a consistent feature taxonomy I developed at the start of the project.

Every feature was scored across 4 dimensions: availability (does the competitor have it?), implementation quality (how well is it done?), discoverability (how easily can a user find it?), and differentiation (does it create competitive advantage?). This gave us a 200-point comparison matrix — the first time the Infragistics team had seen their product positioned this systematically against competitors.

Key gap identified: Slingshot's embedded analytics were more powerful than any competitor — but scored the lowest on discoverability. The feature that should be winning them deals was invisible to most users.

Phase 3 — Heuristic Evaluation

I led the heuristic evaluation personally, applying Nielsen's 10 Usability Heuristics across every major screen of the Slingshot platform on both web and mobile. Each violation was rated for severity (1–4) and tagged with the affected user type (project manager, team member, admin).

Most critical finding: notification overload. Slingshot's default notification settings generated an average of 34 notifications per working day for a typical project manager — compared to 12 for Asana in equivalent project complexity. This wasn't a minor UX issue — it was causing users to mute all notifications, which meant they missed genuinely critical updates.

Second critical finding: the analytics dashboard, Slingshot's core differentiator, was hidden behind a navigation item labelled "Data." Competitive products used "Analytics" or "Insights" — words that signal value. "Data" signals raw information, not intelligence.

Phase 4 — Synthesis & Prioritisation

I synthesised findings across both research tracks using an Affinity Diagram, clustering 80+ data points into 6 primary themes. I then mapped each theme onto a 2×2 opportunity matrix: user pain severity (x-axis) vs. business impact (y-axis).

Three themes landed in the "high pain, high impact" quadrant: analytics discoverability, notification overload, and calendar integration friction. These became the basis of the roadmap presentation — framed not just as UX problems but as churn risks and conversion barriers.

Phase 5 — Stakeholder Presentation & Impact

I presented a 12-slide research readout to the Slingshot PM and design leads, plus the Rutgers MBS programme directors. Every slide followed the same structure: problem → evidence → recommendation → success metric. This format was a deliberate choice — product teams work in metrics, and framing research findings as measurable outcomes made them immediately actionable.

The analytics discoverability recommendation — rename "Data" to "Insights", add contextual prompts after data entry, surface key analytics on the project overview page — was adopted for an upcoming sprint. Estimated engineering effort: 2–3 weeks. Projected impact: 40%+ increase in analytics feature engagement based on the competitive benchmark.

The team earned an Honorable Mention Team Lead Award from the Rutgers MBS Externship programme — specifically noted for research delivery quality and stakeholder communication.

Sangam Lite · Deep Dive

Research & Process

A full walkthrough of the research-led redesign of Tata Power's Sangam Lite — from business stakeholder alignment through 30 field interviews, pilot study, card sorting, MoSCoW prioritisation, ideation, wireframes, and usability testing to high-fidelity prototype.

Phase 1 — Business Alignment & Desk Research

I started by meeting with the Tata Power business team to understand their primary objective: increase engagement with the existing Sangam app, which had low adoption despite being rolled out to 10,000+ employees. The business hypothesis was that the app was underused because it was hard to navigate — but user research would tell a more nuanced story.

Desk research covered three areas: (1) an IA and user journey audit of the existing Sangam app, (2) a competitive analysis of enterprise employee apps (Workday, ServiceNow Mobile, SAP SuccessFactors, Microsoft Viva), and (3) a heuristic evaluation of the existing interface against Nielsen's 10 heuristics. Key heuristic failures: no shortcuts for database searches, poor hierarchy, and inconsistent design patterns between sections.

Competitive analysis surfaced a critical insight: the best-performing enterprise apps (Workday, Viva) were unified platforms that replaced multiple logins with one. Sangam was still a collection of separate mini-apps requiring individual authentication. That fragmentation was the root cause of abandonment — not poor navigation.

Phase 2 — User Research: Pilot Study + 30 Field Interviews

Pilot Study: Before running the full interview programme, I conducted an informal pilot study with 5 employees to test the interview guide and understand which daily activities they actually performed on Sangam. This shaped the questionnaire significantly — I removed 6 questions that generated no useful signal and added 4 that surfaced richer behavioural data.

User Groups: I defined 4 distinct groups for the main research: On-site workers (10 interviews, Trombay plant), Corporate users (10 interviews, Dharavi office), Remote workers (5 telephonic interviews, Mpl and Bhira), and Non-users (5 interviews with employees who had never opened the app). Each group received a tailored questionnaire — 4 versions total — covering their specific workflows and pain points.

Key findings across 30 interviews: Union staff preferred WhatsApp over the app for group communication. On-site workers couldn't mark attendance without going to a desktop (a daily friction point). Corporate users only opened the app when away from their laptops — meaning the app needed to be useful during travel and leave, not during office hours. Non-users cited data privacy and battery drain as barriers. Employees aged 45+ found typing difficult and asked for voice input.

Phase 3 — Synthesis: Personas, Insights & HMW

I synthesised 30 interviews into 4 user personas representing the key archetypes: Aditya (Lead Engineer, on-site, 34), Eshwaran (retiring manager, 58, low tech literacy), Rohan (graduate engineer trainee, 22, power user), and Kajal (HR manager, 42, form-heavy workflows).

Six primary actionable insights emerged: need for singular login, need for a personalised/flexible home screen, need for automated task management, need for mobile attendance marking, need for simplified overtime and leave approval flows, and need for a searchable safety and policy repository.

From these insights, I generated 6 How Might We statements to frame the ideation phase — including "How might we simplify attendance tracking for on-site employees via mobile?" and "How might we enable users to mark features as favourites to reduce cognitive load?"

Phase 4 — MoSCoW Prioritisation & Card Sorting

MoSCoW: Working from interview data, I categorised all 25+ requested features. Must Haves: Payslip, Leave request/approval, GRC approval, BenefitMe (medical claim), Form 16, PMS, HR Policies, Reimbursement. Should Haves: Attendance, Task Manager, Voice Assistant, HR forms, PO approval, Safety section. Could Haves: Gyankosh, Sodexo, Solar Hero, Do Green. Will Not Haves (out of scope): Manager Connect, CPDC, Office Locator, Stationery Portal.

Card Sorting: Before building the IA, I ran an open card sort with 8 users (mix of on-site and corporate) to understand how employees mentally grouped the 25+ services. The sort revealed a consistent 5-cluster model: Attendance & Tasks, My Services (HR/Finance/Manager), Social & Community, Profile & Settings, and Search/Notifications. This became the navigation backbone.

Phase 5 — Ideation & Visual Design Decisions

I ran a Round Robin ideation exercise with 6 employees and interns to generate concepts for the three most complex features: the AI Task Manager, the Voice Assistant, and the Social Updates feed. This surfaced ideas I wouldn't have generated independently — including the gamified task manager with weekly performance rewards, which employees responded to most enthusiastically.

Visual Design: The design language was anchored to Tata Power's brand: cobalt (#1E4ED8 primary, #102A74 for the deep gradient), white cards on a #F1F5F9 surface, and a semantic status set where every state pairs a colour with a word — green/#D3F3DF for present and approved, amber/#FDECCE for late and awaiting, red/#FBDADA for absent and declined. The decision to use rounded cards rather than the flat list view in the original app was driven by touch target research — card-based layouts increase tap accuracy on small screens by ~30% for users with lower digital literacy.

The home screen hierarchy was informed directly by the MoSCoW analysis: Attendance status (check in/out) sits at the very top because 22/30 interviewees said it was the first thing they did in the morning. Quick-access service tiles (Tasks, Leave, Payslip, Safety) are immediately below, with the social feed and recommendations at the bottom.

Phase 6 — Wireframes → Prototype → Usability Testing

I built wireframes in Figma covering 5 primary flows: attendance, task management, leave request, services directory, and voice assistant. Each flow was tested on paper (5 participants) before moving to high-fidelity — a step that caught 3 major IA issues before a pixel was designed.

Usability testing of the high-fidelity prototype surfaced two improvements: icons were too small for older users (increased from 20px to 28px across the board) and users wanted a user manual accessible from the home screen (added as a "Help & Benefits" section). Both were resolved before the final handoff.

NFC attendance was the highest-impact innovation from the research. By proposing tap-to-clock using NFC readers already installed at Tata Power facilities, the redesign eliminated the need for on-site workers to travel back to a desktop solely to mark attendance — reducing that friction by an estimated 60 minutes per affected employee per day.