Every department had its own tool, so work stalled at every handoff.

The organisations we worked with were not starting from zero. Most departments already had a tool that worked for their own needs.

A simple internal request could move through several people: the employee submits, the manager reviews, another team processes it, and the employee waits for a status. Information lived in different places. Status needed manual follow-up. Responsibility became harder to trace.

Managers depended on Projects, Sales, Accounting, HR and Operations to know where to step in. Employees had to remember where each task, request or process lived.

This was an actionable root cause. It changed the work from "redesign the confusing screen" to three system-level actions.

We mapped the product from the job down to the interface: Jobs, then Workflows, Business objects, Rules, Capabilities, and last Modules.

These jobs shared one set of objects: Task, Request, Employee, Customer, Project, Order, KPI, Approval, Status and Organisational Unit. A Request, for example, could connect an employee, a manager, a department, an approval rule and a status.

A fixed Manager or Employee persona was a useful start but too simple for an SME. One person could work in two modes, and the account stayed the same while the responsibility changed with the task.

After the first core modules were live, the question changed from "what needs to exist?" to "what deserves attention next?". Frequency alone was a weak answer: attendance creates daily usage, while a permission error or a high-impact approval happens less often and carries more risk. So signals were weighed on five dimensions, and each signal got one of four responses.

This kept the roadmap from turning every request into a feature. A signal first had to reveal the type and level of the problem.

Permission could not stay a screen-level rule once ISS365 had to support different organisational structures. Three needs had to stay in balance: users see only what they may access, permission does not block work they are responsible for, and the model supports both simple and complex organisations.

Broad roles such as Owner, Manager and Employee give a starting point. More control opens through three steps: organisation and department, then project and data scope, then responsibility and exception. The result is closer to a hybrid of RBAC and ABAC than to a purely fixed-role system.

Permission also changed what the interface shows. Hide when the resource itself should not be discoverable. Show as restricted when users may know it exists but cannot open its content. Show as disabled with an explanation when keeping an unavailable action visible helps explain the workflow.

The second decision came from an all-in-one assumption: every existing tool should eventually move inside the platform. CRM showed why that can fail. Customer conversations already happened in Zalo, Facebook, fan pages and other touchpoints, while orders, purchase history, ownership and sales activity lived elsewhere.

The value came from reducing fragmentation around the customer relationship, not from forcing every conversation into ISS365. The choice carried a long-term dependency risk around APIs, authentication, platform policies and maintenance. We accepted it because replacing familiar channels would have created a larger behaviour-change risk with weaker user value.

The Request journey shows how a signal moved from detection to design. Production analytics showed a meaningful drop around the approval-details step. Users were already reaching and starting the flow, so discoverability was less likely to be the main problem. Different evidence answered different questions.

The evidence showed repeated hesitation, backtracking, repeated interaction and weak system feedback. Users struggled to understand which information was required, whether their action had registered, where they were in the process and what would happen after submission. The working diagnosis had two parts: decision load, with too much information and too many choices upfront, and weak system feedback.

As modules were built in parallel, similar interactions began to collect different local implementations. Users had to relearn behaviour, and designers, developers and QA repeated work. The rule was: repeat first, abstract second. A solution stayed local while the requirement was specific, the behaviour was still changing, or the domain truly needed a different pattern. When behaviour became stable and repeated across contexts, it moved into the shared system: local solution, repeated behaviour, review, shared rule, then Figma and Storybook.

Reusable behaviour needed usage guidance too: when to use it, why it existed, how it behaved and which edge cases it covered.

Standardisation had a limit. One view held that fewer fields and lower density would always be easier. Accounting workflows challenged that: experienced accountants rely on familiar codes, columns, terminology and financial structures, and hiding too much slows comparison. For dense expert workflows we kept the useful information and improved hierarchy, grouping, alignment, scanability and error prevention.

My design reviews therefore asked questions that reach beyond one screen.