.png)
Aligning Minds, Not Just Files -
Requirements Management Tool
Role
UX Designer & Developer
Timeline
30 Days
Client
Bosch
THE PROBLEM
At BOSCH, designing UI for car infotainment systems wasn't the hard part, aligning teams around those designs was. Developers were guessing requirements, designers were repeating themselves in email threads, and stakeholders were left asking, “Wait, where are we on this?”
​
The existing process was broken: handoffs were messy, documentation was scattered, and miscommunication bloated timelines. We needed one truth, one space, and one flow.
THE MISSION
Create a centralized requirements management tool where engineers, designers, and developers could collaborate in real-time and where stakeholders could actually see progress before the final demo.
Proposed solution UI - A Dashboard with HMI Screen on left and screen specific requirements on right with their current status.
APPROACH
Rather than designing in a vacuum, we grounded everything in Jobs-To-Be-Done and sprint-based Lean UX.
JTBD + Lean UX in Action
Why do users need the Tool? - JTBD Highlights
Requirement Engineer
"I want to write element-specific requirements fast and avoid repeated clarification."
UX/UI Designer
"I want to hand off designs without manually explaining every pixel shift."
Developer
“I want latest specs + designs in one view—no scavenger hunts.”
Manager
“I want live project status and clear ownership, not a Slack guessing game.”
Stakeholder
“I want visibility. Early. Often. Organized.”
What features could help? - Ideation
HMI Element Selection and Add Requirement
Select UI Element and add specific requirement for developers.
Requirement Status
Role based requirement status update for each user - New, In Review, Done, Cancelled, Approved
Embed Design File
Embed Figma design file in the tool to access and add requirements to it.
​​
HMI Screens library
A cloud-based folder system to store and reuse any screens imported from figma. ​​​
Role-based Access
Who can do what? Each user will have their own role matrix, with one admin deciding permissions.
Stakeholder Dashboard
A dashboard showing overall project level progress, activity, blockers and changes, in read-only mode.
Consolidated Requirement View
Show all requirements in hierarchy. Project level > Variant level > Screen Level > Element Level
SRS PDF Download
Automated SRS Document generation and download
Change Log
For Design file changes, requirement changes, status changes, Project level changes
How could these features sync? - Ideation
How and What we built? - Lean UX Highlights
We worked in 2-week cycles with a cross-functional crew - Product Manager, UX Designer/Developer (Me), Software Architect and Full-stack Developers
Wireframe 1 & 2 : List of Projects > Each Project Overview Screen
Wireframe 3 & 4 : List of Screens & HMI Requirements in SRS format
Wireframe 5 : Screen Requirements View - Left side is the HMI screen, right side is the screen specific requirements
INITIAL DESIGN AND WORKFLOW - MVP
We started building the tool with initial plan to check the usability and technical feasibility of the product and see how it could actually help its users the best!
Initial Screen after login for all users
Each project tab contains project specific content, screens, requirements, download SRS option and all other details.
Project Tab when clicked takes you to Project Overview. Where the team can see overall status and project details.
All the HMI requirements of the project - List view
All the project screens uploaded from Figma
Screen specific requirements view
Add generic/ project requirements from the list view.
Adding Element specific requirements for the screen.
Select the element, click on the "Add Requirement" .
What we learnt and adapted? - Design Iterations
Requirement form needed rich text editor:
To format text, add tables, embed images and font settings.
​
​An option to link requirement to a UI Element:
If the user adds requirements from list view, a drop-down to select an element we can link it to.
​
2-way mapping of requirements:
Highlight requirements linked to a UI element on element selection and highlight UI element on selecting requirement.
​
Stakeholder Dashboard:
​A separate dashboard with filtered details for easier and faster update for clients and stakeholders.
​
High-fedility form, where we added custom field or client specific addition option for requirement form.
2-way mapping
Stakeholder Dashboard
How it finally looked? - Just a peek!
Requirement Status - New, Modified, In Review, Approved, Cancelled, On Hold, Done.
Requirement Card View - Card consists of action buttons (Edit, Delete, Activity Log, Comments, Relink requirement), Requirement Status, Brief Description, Author, linked Element, Requirement ID.
Expandable Requirement Tree - All requirements are arranged in a Hierarchy - Project requirements > Screen requirements > Element Requirements. A project level requirement can have multiple screen level requirements as children, a screen requirement can have multiple element level requirements as children.
Requirement Status Indicator - A requirement status color coded bar in list view for easier skimming and searching, with actually opening the requirement.
What did we achieve? - Results
40% drop in design-to-dev handoff issues
​
Automated and faster SRS document generation
​
2 sprints saved per release through clearer communication
Stakeholders gave early feedback, not late-stage surprises
AND WE CONCLUDE! - REFLECTIONS
This wasn’t just a tool—it was a system of clarity. We didn’t just reduce errors; we rebuilt trust across roles. Designers felt heard, devs felt confident, and stakeholders finally felt informed.
This project showed me that great UX isn’t just about screens—it’s about building the connective tissue between people, tools, and progress.