Scope: Product Architecture, Design System 0→1, CRM, Attendance, Personalized Workspace, AI Knowledge Base, Design Team Governance
Context: SaaS B2B Platform / Internal Operating System
NDA Note: Do ràng buộc bảo mật, tôi không thể chia sẻ số liệu kinh doanh, dashboard nội bộ hoặc dữ liệu chi tiết. Case study này tập trung vào product thinking, design system, workflow comparison và operational impact có thể chia sẻ công khai.

How This Started

ISS365 did not start with a grand vision. It started because every team inside the company was losing their mind.

Sales was managing customers through Facebook, Zalo, Gmail, and personal notes scattered across different devices. They would get a message on Facebook, follow up on Zalo, get confirmation through Gmail. By the time they needed to check the conversation history, they had to piece it together from three different places.

HR was managing attendance with a mix of manual check-ins, spreadsheets, and vague records. When payroll came around, they had to dig through everything again to get accurate numbers.

Managers wanted to see what their teams were doing, but the information was split across different tools.

Employees just wanted to check in, see their tasks, and find internal information without opening five different applications every morning.

So the company decided: let's build one system that handles all of this.

On paper, that sounded reasonable. In reality, it was much messier.

We needed CRM, Attendance, HRM, Project Management, Reports, Knowledge Base, Accounting, Orders, Products, Marketing, and system settings. That is a lot of modules. And the hard part was not building them individually. The hard part was making them feel like they belonged together.

My job as Product Design Lead was to figure out how.

The Real Problem Was Not What You'd Think

When people first heard about ISS365, they assumed the main issue was navigation. Too many modules, too many menus, too many buttons.

But after spending time with different teams, I realized the actual problem was deeper than that.

If we built one experience for everyone, the product would either be overwhelming or useless.

So the question I kept asking was: How do we let different teams work in the same system without making them all go through the same experience?

That question changed how we approached the whole product.

What I Did

I was not designing individual screens. I was trying to organize complexity.

I worked on understanding how different roles moved through their day. I talked to stakeholders about what mattered most. I created patterns that could be reused across modules so we did not have to redesign tables, filters, and forms a hundred times. I reviewed designs before they went to engineering to catch consistency issues early. I worked with PM to say "no" to things, or at least "later".

The hardest part of the job was in the messy middle: when business wanted more features, engineering wanted simpler implementation, and users just wanted to get their work done without thinking about the product.

In those moments, I kept asking: Is this a one-off thing, or should it become part of the system?

That one question prevented ISS365 from turning into a pile of disconnected tools.

Before We Designed Anything, We Watched

I did not run a formal user research lab. I just spent time with sales people, HR managers, employees, and admins while they worked.

What I saw was important.

Sales users were jumping between platforms constantly. They did not care which channel a message came from. They cared about the customer. But the tools made them think by platform instead.

HR did not need "a check-in feature". They needed attendance data they could trust, filter, sort through, and connect to their monthly reports and payroll systems. A fast check-in is worthless if the data is garbage later.

Most users did not use all ten modules every day. They had a small group of tools they kept coming back to, depending on their role.

Company knowledge was scattered. Some was in documents. Some in folders. Some in chat. Some only in someone's head. New employees had to ask around constantly.

Permissions were not just a backend detail. They shaped what users could see and what answers the system was allowed to give.

These observations pushed us away from "let's add more features" and toward "let's organize what we have better".

P1: Personalized Workspace — When Favorites Were Not Enough

The first version of this feature was simple.

Let users save their favorite modules. Done.

It made sense. It was easy to explain. It was easy to build. So we started there.

But after watching different roles work, I felt it was too shallow.

A sales person was not just bookmarking CRM. They were trying to create a small working area inside a massive system. They wanted CRM, Customer Management, Reports, and Follow-up Tasks in one place so they could start their day from there instead of navigating through the full menu.

An HR person wanted Attendance, Employee Records, HRM, and payroll-related data grouped together.

A manager wanted Dashboard, Reports, Approvals, and Team Activity.

So I pushed the team to expand the idea. Instead of just saving modules, users should be able to create their own workspace. Group their tools. Control their own entry point into ISS365.

It was a small design decision, but it changed how the product felt. Instead of always starting from the full system structure, users could start from their own work context.

Before this, getting to a frequently used feature took a few steps: open the main menu, find the module group, select the module, enter the sub-page.

After, it was one click from the workspace.

Not a huge improvement on paper. But in reality, when you do something twenty times a day, reducing it from four steps to one makes a real difference.

What I Would Have Done Better

The first release had one flaw: blank personalization.

We asked users to build their workspace from scratch. Some did. Some did not. They just left it empty.

If I continued this, I would have created role-based templates first: Sales Workspace, HR Workspace, Manager Workspace. Let people start from there and customize it. That would have reduced the friction of the blank slate.

P2: CRM — The Day We Stopped Thinking By Channel

CRM was the most important module because it touched sales directly. Revenue touched it. So it had to work.

The problem was clear: customer conversations were happening everywhere.

First message on Facebook. Follow-up on Zalo. Details confirmed through Gmail. Sales users were keeping multiple tabs open and mentally connecting the dots.

The obvious UI solution was simple: make channel tabs.

Facebook tab. Zalo tab. Gmail tab.

Engineering liked it because each channel could keep its own logic. PM liked it because it was easy to explain. We started building it that way.

But something bothered me.

I kept watching sales people work. And I noticed they did not think: "I need to check my Zalo inbox."

They thought: "What happened with this customer?"

That was the insight that changed everything.

The tabbed version organized the interface around the platform. It was technically clean. But it repeated the same problem in a nicer UI.

I brought this back to the team. It was not an easy sell.

But I kept asking: is the tabbed version what sales actually need, or is it just what is easier to build?

After some debate, we decided to redesign.

Instead of thinking "channel tabs", we thought "customer timeline".

Now Facebook, Zalo, and Gmail were not separate inboxes. They were touchpoints inside one relationship.

The flow became: Message source → Customer profile → Conversation history → Lead status → Follow-up action.

What Was Harder Than Expected

The timeline model solved the user problem, but it created technical problems.

What if the same customer contacted through different phone numbers? What if they moved from one lead to another? What if two sales people were touching the same customer?

We could not solve all of this perfectly in version one. Some of the matching logic had to be phased. But choosing the customer-first model early meant we avoided building a cleaner version of the old fragmented system.

That would have been worse.

P3: Smart Attendance — Making A 10-Second Action Reliable

Attendance seemed simple. Employee checks in. System records time. Done.

But when we talked to HR, it became clear that check-in was only the surface.

The real question HR cared about was: can I trust this data?

Because they needed that data for reporting. For payroll. For accuracy.

But employees did not care about accuracy. They wanted the check-in to be fast. Nobody wants a complicated flow every morning.

This was a real tension.

So we combined both. Location verification plus face verification.

The design had to make this feel fast for employees but trustworthy for HR.

We kept the mobile check-in flow short: confirm location, verify face, show result.

On the management side, HR could filter records, review them by team or month, export them, and use them for payroll calculations.

This made both sides work.

What We Did Not Get Right

Face verification is sensitive. Users need to understand what data is being captured and why.

In the first version, we treated it like a technical feature and moved on. We should not have.

If I continued this, I would add clearer communication about privacy. What data is captured. How it is stored. How it is used. For a feature involving facial recognition, trust is part of the experience, not just a legal note.

P4: AI Knowledge Base — Why Permission Matters More Than Speed

The Knowledge Base started with a simple observation: company information was everywhere.

Documents in folders. Guides in wikis. Processes in chat groups. Some knowledge only existed in someone's head.

So the obvious idea was: use AI. Let people ask questions and get answers.

But here is the problem with that idea.

Not every employee should see every document. Not every manager should access HR information. A sales person and an admin might ask the same question, but the system should not always return the same answer.

So the real design challenge was not "how do we make AI faster?"

It was "what is this user allowed to know?"

That changed the whole approach.

A simple AI search box would have looked modern and felt powerful. But it could expose information beyond someone's permission. That is a serious risk in an enterprise system.

So I pushed the design toward permission-based retrieval.

The logic became: User asks → System checks permission → Only allowed sources are searched → AI generates answer → Answer visibility follows access rights.

This was slower to design. But it was more responsible.

What Still Needs Work

The AI Knowledge Base needs a stronger trust layer.

Users need to see where the answer came from. They need to be able to report wrong answers. Admins need to see which documents are being used frequently and which ones are confusing people.

For internal knowledge, the answer is only useful if people trust where it came from. We built the permission side right. We did not build the trust side well enough.

P5: Design System — Patterns, Not Just Components

With a platform like ISS365, the design system is not about colors and buttons.

The real value is stopping every module from becoming its own product.

CRM, Attendance, HRM, Reports, and Customer Management all needed similar things: tables, filters, forms, detail pages, status labels, action menus, empty states, permission states.

If each module solved these differently, users would have to relearn the product every time they switched areas.

So I worked on patterns that could be reused.

Tables needed the same sorting, filtering, and bulk actions across modules.

Forms needed predictable create/edit behavior.

Status labels needed to be scannable.

Permission states needed to explain why something was hidden.

The hard part was not creating components. The hard part was deciding when to reuse a pattern and when to allow an exception.

I had a simple rule:

If a pattern appears across multiple modules, make it standard. If it only serves one workflow, keep it local. If it adds complexity without clear value, cut it or save it for later.

This helped the team make decisions faster.

P6: The Tension That Never Goes Away

There was always conflict on this project.

These tensions were not signs of dysfunction. They were signs that everyone cared about shipping something good.

CRM was the clearest example.

The tabbed version would have shipped in half the time. It was technically cleaner. Each channel could keep its own logic. PM could explain it in a sentence. But it repeated the same problem the sales team had complained about in the first place.

I had to push back. Not in a destructive way, but by asking: "What do sales people actually think about when they open this product?" The answer changed everything.

Personalized Workspace had a similar tension.

A simple favorite list would have been enough for version one, maybe even good enough for version two. But after watching users work, I realized they were not just saving modules. They were trying to carve out their own working space inside a much larger system.

So I pushed the team to expand the idea. Not because I had perfect foresight, but because the original direction felt too shallow.

Not every decision went my way. Sometimes we had to ship a phased version because timeline and engineering capacity were real constraints. Sometimes the business case was stronger than my design arguments. That is the reality of working on a real product.

But the important part was making sure those trade-offs were deliberate, not accidental. When we chose to defer something, we knew why. When we chose to simplify something, we understood the cost.

How We Measured Impact

Because of NDA, I cannot share raw business numbers. So I used workflow comparison, internal observation, stakeholder feedback, and product signals.

I tried to avoid making the impact sound bigger than what we could prove.

Concrete signals I can share:

• 3 customer channels connected into CRM: Facebook, Zalo, Gmail

• Frequent module access reduced from several navigation steps to one workspace entry point

• Attendance check-in observed internally at around 5–10 seconds in normal conditions

• Shared table, filter, form, status, and permission patterns reused across multiple modules

• Permission states became part of the core UX instead of being treated as backend-only logic

These are proxy signals, not public business claims.

What I Would Do Differently Now

If I continued ISS365, I would invest earlier in analytics.

A lot of early decisions came from observation and feedback. That helped us move forward, but it was not enough for long-term optimization.

I would want clearer data on:

Which workspace shortcuts are used most often? Which modules are saved but rarely opened? Where do sales users get stuck in CRM? How often does face verification fail? Which Knowledge Base questions return weak answers? Which permission errors happen repeatedly? Which shared patterns actually reduce design and development time?

This data would help us make the next phase smarter.

I would also push accessibility earlier. Contrast, keyboard navigation, focus states, error messages, form validation, and responsive behavior. These should not be cleanup work at the end. For a platform used every day, those details matter.

One more thing: I would improve defaults.

Personalization is powerful, but blank personalization is not. Users should not have to build everything from zero. The system should provide useful starting points based on role — Sales Workspace, HR Workspace, Manager Workspace — and then let people customize from there. That would reduce the friction of the first experience.

Looking Back

ISS365 taught me something important.

A big product does not fail because it has many features. It fails when users cannot see how those features fit into their actual work.

The most valuable design work was not the polished UI. It was the structure underneath: what to group, what to connect, what to hide, what to standardize, and what to leave flexible.

But honestly, we did not get everything right.

Some modules needed better defaults. Some had edge cases we could not solve in version one. Some needed stronger privacy communication. Some needed better trust layers. Not everything was perfect, and that is okay.

Those were not failures. They were the reality of shipping a product for many teams doing different kinds of work. The next phase should have been: fix the foundation, not add more modules.

The biggest lesson was simple:

A complex product does not need to feel simple. It needs to feel clear.