Business operations were fragmented across departments, tools, and manual processes.
Connect work across HR, attendance, projects, inventory, CRM, marketing, and accounting without forcing every company into one process.
Layered access · Connected customer context · Progressive Request flow · Shared product rules.
Request completion increased 17 percentage points, from 62% to 79%, in a before/after production comparison.
From fragmented operations to a product
The organizations we worked with were already using digital tools. Different teams relied on different systems and processes.
The friction of boundaries
These tools could work well inside individual departments. Friction appeared when work crossed those boundaries. Information lived in different places. Status required manual follow-up. Responsibility became harder to trace.
"The product problem appeared when handoffs forced people to reconstruct ownership, status, or context outside the system."
Internal deployment exposed where early product assumptions failed in real work.
How might we reduce operational fragmentation while preserving the different ways teams need to work? Product principle: separate company-specific behavior from rules that remain useful when structures and responsibilities change.
Jobs connected the ecosystem
Modules organized capabilities. Jobs connected the experience across them. These recurring jobs were synthesized from internal use, feedback, workflow mapping, and analytics.
Attention changed with the task
Manager and Employee labels described accountability, but not moment-to-moment intent. We used attention modes to guide hierarchy without pretending that each person had only one fixed need.
Frequency was only one signal
Usage frequency alone was not a prioritization rule. A high-impact approval might happen less often but carry greater consequence.
How signals were prioritized
These dimensions guided discussion; they were not converted into invented precision or a mechanical score.
Frequent work needed a faster access surface
Attendance was a high-frequency mobile job. The experience kept the immediate action, verification, current status, and history close together instead of reproducing the denser Web workflow.
- Check-in and check-out remained the primary action.
- Face and location context supported attendance verification.
- History made recorded time and status easier to confirm.
Permission became a core product decision
As ISS365 needed to support different organizational structures, permission could no longer be treated as a simple screen-level rule.
Five access contexts → one effective state
The interface resolved access from five contextual rules before choosing what to show or enable.
Interface response states
The resolved state affected navigation, search, visibility, actions, and workflow behavior.
Release changed the decision loop
Early development focused on one question: "What needs to exist?" After release, another became equally important: "What is working, what is breaking, and what deserves attention next?"
Feedback routing
AI-assisted labels reduced sorting effort, but people still reviewed meaning and priority. Routing a signal answered who should investigate, not what the team should build.
Different problems needed different responses
One workflow, different platform responsibilities
Connection did not always mean replacement
Improving Request Submission
The Request journey became the clearest example of how a production signal moved from detection to investigation, design, and measurement.
Established: where completion dropped and how large the signal was.
Largest observed drop: the approval-details step.
Suggested: what behavior surrounded that drop-off.
Observed behavior: hesitation, backtracking, and repeated interaction.
Investigated: what users were trying to understand.
Friction: required information, progress, and post-submission state.
Request funnel completion
Same tracked steps, before and after release. Values show the share that reached each step.
Before/after production comparison, not a controlled A/B test. The workflow improved by 17 percentage points, but the data does not prove that redesign alone caused the entire change. Exact study counts and measurement windows are omitted here.
Design responses to the diagnosis
Diagnosis: too much information competed upfront, while system feedback was weak after submission.
Workflow schematic, not a product screenshot.
Shared where repeated, flexible where context differed
As modules were developed in parallel, similar interactions began behaving differently. The goal was to standardize behavior where repetition created real product or implementation cost.
A shared pattern had to earn its place
A solution stayed local while requirements were specific or evolving. Reusable behavior needed components, variants, and usage guidance that explained when, why, and how to apply the pattern.
Showing less info wasn't always better
The goal was to reduce unnecessary cognitive effort. In accounting-heavy workflows, users repeatedly worked with familiar codes and structures. Hiding too much could make comparison slower rather than easier.
Preserving useful density
For these workflows, we preserved useful density while improving:
Because system-level measurement was not defined early, this is presented as a governance decision, not a quantified efficiency claim.
My role as Product Design Lead
My ownership operated at different levels across the product. Across a three-designer team, my reviews increasingly focused on decisions with implications beyond a single feature.
Swipe horizontally to see all ownership details.
| Area | Decision role | What I owned |
|---|---|---|
| Request submission | Direct lead | Investigation, design, validation, and post-release measurement |
| Product IA and shared behavior | Design lead | Direction across recurring product patterns |
| Permission experience | Co-defined | User-facing behavior and trade-offs with Product and Engineering |
| Design System | Design lead | Shared-pattern direction and governance |
| Web and Mobile behavior | Collaborative | Cross-platform decisions with Product and Engineering |
| Design team | Review and governance | Decisions with implications beyond a single feature |
Real use exposed the difference between company-specific behavior and reusable product rules.
Good design did not always remove complexity. It decided where that complexity should live.
The question was no longer only "What should we design?" but "At what level should this problem be solved?"
What I would do differently: Define system-level measurement earlier
Measurement was clearer for Request than for system-level work (Permission, Design System). If setting up again, I would define earlier:
The goal would not be to create more dashboards. It would be to make important system decisions easier to evaluate after release.