How to Build a Platform Teams Actually Use

A software project can be technically successful.

The servers are stable.

The features have shipped.

Security is in place.

The interface looks clean and modern.

Then, a few weeks later, something strange happens.

People are still opening the old Excel file.

They write things down first and enter them into the system later.

They message a colleague instead of using the platform.

Or worse, part of the team barely logs in at all.

Technically, the product is live.

From a business perspective, adoption has not happened yet.

That difference matters.

Software that has been delivered is not necessarily software that gets used.

GOV.UK guidance for internal services makes a useful point: employees are users too, and internal systems should be designed with the same focus on usability, accessibility, security, and continuous improvement as public-facing services.

So the real question is not:

“How do we design a good platform?”

A better question is:

“How do we make this platform become part of the team’s natural way of working?”

Start With the Work, Not the Screen

One of the most common mistakes is to begin a project by talking about the dashboard.

Which cards should appear?

Should the navigation be on the left or the right?

Which charts should be on the homepage?

Those questions matter.

Just not first.

Before designing the interface, you need to understand what the user is actually trying to get done.

A sales user may not really want to:

Open the customer page.

What they actually want may be:

Quickly understand what this customer bought last time and what follow-up needs to happen next.

A warehouse user may not want to:

Complete an inventory form.

They may want to:

Hand over the right item quickly, avoid mistakes, and know that stock levels were updated correctly.

Good product design starts with the job.

Not the screen.

First understand what the user is trying to finish. Then design the interface around it.

Observe the Real Workflow, Not the Meeting-Room Version

Ask a department manager:

How does order processing work?

You may get a clean, logical process diagram.

Then sit beside someone who actually does the work.

The reality may look different.

Customer information arrives through WhatsApp.

There is an Excel file in the middle of the process.

Someone checks a customer code in another application.

Certain values are entered from memory.

An unusual case requires a phone call.

A step described as “quick” in the process documentation actually takes 20 minutes.

This is why user research is more than interviews.

Observation matters.

GOV.UK recommends understanding who users are, what they are trying to accomplish, how they do it today, and the real-world context in which the service is used.

Some of your best requirements will not come from what users tell you.

You will discover them by watching the work happen.

Do Not Simply Digitize a Bad Process

Imagine a request currently needs six signatures.

The easiest digital transformation is to reproduce those exact six approvals inside the new platform.

Now instead of six paper signatures, you have six digital approvals.

Is the process better?

Maybe it is only digital.

Before building a workflow, ask:

• Why does this step exist?
• Is it still necessary?
• What risk is it controlling?
• Can two steps become one?
• Can part of the decision be automated?
• Do all requests really need the same approval path?

Digitalizing a poor process does not automatically improve it.

It can simply make a bad process digital.

Design for Roles, Not for “The User”

In enterprise software, there is rarely one generic user.

A sales manager and a sales representative may use the same platform, but they do very different work.

The representative may perform:

• Search
• Create
• Update
• Follow-up

dozens of times every day.

The manager may mostly:

• Review
• Compare
• Approve
• Monitor

A finance user may need transaction-level detail.

An executive may only need exceptions and trends.

If everyone gets the same dashboard, navigation, and information density, there is a good chance the experience is not ideal for anyone.

For each role, understand:

• What tasks do they perform?
• Which ones are frequent?
• Which information do they need?
• What should they not see?
• Where do they make decisions?
• Which actions are urgent?
• Which tasks happen once a month?

Permissions are not only a security concern.

They also shape the user experience.

A user should not have to navigate around dozens of features they never need or cannot use.

Make the Most Frequent Task the Shortest Path

On a public website, a visitor may complete a task once a month.

In enterprise software, a user may perform the same action 80 times a day.

One extra click can look insignificant in a demo.

Now multiply it:

80 times a day × 200 working days × 100 users

It is no longer insignificant.

Enterprise UX needs to care deeply about frequency.

For high-frequency tasks, things like these can make a real difference:

• Keyboard shortcuts
• Bulk actions
• Smart defaults
• Recent selections
• Fast search
• Saved filters
• Duplicate actions
• Inline editing
• Reduced navigation

A useful question during design is:

How many times per day does this user do this?

That question can completely change the priority of the interface.

Not Everything That Exists Needs to Be Visible All the Time

Enterprise software is often genuinely complex.

Different roles.

Many settings.

Exceptions.

Business rules.

Multiple workflows.

But a complex domain does not mean every piece of complexity needs to be visible at once.

If a form contains 35 fields but 90% of users only need 10 of them, the rest may only need to appear when relevant.

If advanced settings are only for administrators, regular users should not have to see them every day.

This is where progressive disclosure helps.

Show what matters now.

Reveal more detail when it becomes relevant.

The goal is not to hide functionality.

The goal is to protect attention.

Users should not have to scan through irrelevant complexity to find the one thing they need.

Consistency Matters More Than Creativity

If the Save button is green on one page, blue on another, and replaced by an unfamiliar icon somewhere else, users have to relearn the interface over and over.

The same applies to:

• Labels
• Navigation
• Icons
• Tables
• Filters
• Modals
• Errors
• Date formats
• Actions

W3C accessibility guidance emphasizes consistency, predictable behavior, clear labels, and understandable navigation because unexpected changes make interfaces harder to use.

In enterprise software, a design system is not just about visual polish.

It helps users predict what will happen.

And predictable software requires less training.

Use the Language Your Users Already Use

Users should not need to learn your system architecture vocabulary just to do their job.

If everyone in the company says:

“Purchase Request”

but the software says:

Procurement Acquisition Entity

the problem is not the user.

Product language should match the real language of the business.

That does not mean technical terminology is always bad.

If users genuinely use the technical term, use it.

The goal is not to simplify everything.

It is to:

Speak the language of the work.

Search and Filtering Are Core Features in Large Systems

If you have 30 customers, a simple list may be enough.

If you have 300,000 records, it is not.

In enterprise platforms, search and filters often become part of the primary workflow.

Users may need to:

• Search using multiple identifiers
• Build combined filters
• Sort results
• Save common filters
• Export results when authorized
• Open a record and return without losing context

These may not be the most impressive features in a product demo.

But after three months, they are often exactly what determines whether people enjoy using the platform or start avoiding it.

Re-entering the Same Data Is One of the Fastest Ways to Kill Adoption

Imagine customer information already exists in the CRM.

But the user needs to enter it again to create a quotation.

Then the accounting team enters the quotation details again.

Later someone manually copies the document number back into the CRM.

From an architecture perspective, you may have three separate systems of record.

From the user's perspective:

Why am I typing the same information three times?

This is where integration becomes part of UX.

APIs, events, and system integration are not only backend concerns.

If they eliminate copy-paste and repeated data entry, they directly improve daily user experience.

W3C WCAG 2.2 even includes a criterion called Redundant Entry, aimed at reducing unnecessary repeated input during a process.

A useful rule is:

If the system already knows something, there should be a good reason for asking the user to enter it again.

Error Messages Should Tell Users What to Do Next

This:

Error 1048

may mean something to a developer.

It means almost nothing to a user.

Even:

Operation failed.

is not especially helpful.

A useful error message should answer, where possible:

• What happened?
• Why did it happen?
• What should the user fix?
• Was their previous input saved?
• Can they try again?
• Where can they get help?

For example:

“Customer number not found. Check the number or create a new customer.”

is far more useful than:

Customer Reference Exception

Good error design is not only about describing failure.

It is about helping the user recover from it.

Performance Is Part of UX

A page can look beautiful and still create a terrible experience.

Search takes six seconds.

Save gives no feedback.

Large tables freeze.

Users click twice because they are not sure whether the request was submitted.

Performance is not only a technical metric.

It changes behavior.

When systems feel slow or unreliable, users create workarounds.

Excel.

Email.

Messaging apps.

Paper.

Or:

“I’ll enter it later when the system is working properly.”

Trust builds slowly.

A few bad experiences can destroy it quickly.

Accessibility Is Not a Last-Minute Feature

Accessibility is not only about users with permanent disabilities.

People may have visual, motor, cognitive, or temporary limitations.

They may also:

• Work on small laptops
• Use keyboards heavily
• Work in noisy environments
• Be older
• Use the application for many hours every day

W3C WCAG 2.2 provides current testable accessibility criteria around areas such as:

• Keyboard focus
• Target size
• Dragging
• Consistent help
• Redundant entry
• Accessible authentication

Many accessibility decisions improve the experience for everyone.

Better contrast.

Clear labels.

Keyboard navigation.

Larger clickable targets.

Simpler forms.

Recoverable errors.

These are not only accessibility features.

They are signs of a well-designed interface.

UAT Should Mean More Than “The Feature Works”

User Acceptance Testing often turns into a technical checklist.

Does Save work?

Yes.

Does the report open?

Yes.

Can the user log in?

Yes.

But real UAT should ask:

Can the user complete their real work with this system?

Use realistic scenarios.

For example:

“A customer calls to ask about yesterday’s order and also wants to change the delivery address.”

Then watch:

• Where does the user start?
• Where do they pause?
• Where do they make mistakes?
• Which information can they not find?
• Which workaround do they return to?

Technical testing proves the software functions.

Usability testing shows whether the software supports the job.

You need both.

Training Matters, but It Should Not Compensate for Bad UX

A common response to interface problems is:

We’ll explain that during training.

If saving a simple form requires 20 minutes of training, the problem may not be training.

That said, enterprise software often contains genuine complexity, and training is a normal part of rollout.

Useful formats may include:

• Short role-based sessions
• Two- to five-minute videos
• In-product guidance
• Contextual help
• Searchable documentation
• Scenario-based examples
• Internal super users

The goal is not to make users read a 100-page manual before they can complete a daily task.

Training should accelerate adoption.

It should not be a workaround for confusing design.

Rollout Is Not Only a Technical Deployment

You can activate excellent software for 500 employees at 8:00 on Monday morning and hope everyone adapts.

Something interesting will probably happen.

Change management matters.

Users need to understand:

• Why is the system changing?
• What will change?
• When does it happen?
• What becomes easier?
• How long will the old system remain available?
• Where can they get help?
• What happens to their feedback?

Microsoft’s current Power Platform adoption guidance treats successful adoption as more than a technical implementation. It includes vision, metrics, leadership sponsorship, governance, training, support, and community.

Adoption is a Product + Technology + People problem.

Internal Champions Can Be More Effective Than IT

Every department usually has people who:

• Understand the process deeply
• Learn technology quickly
• Are trusted by colleagues
• Become the first person others ask for help

These people can act as champions or super users.

Their job is not just training.

They provide feedback.

Spot real problems early.

Introduce new features.

Translate user needs back to the product team.

Microsoft also uses champion networks as part of its adoption guidance to help drive usage and create stronger feedback loops.

Sometimes the best ambassador for a platform is not the person who built it.

It is the person who uses it every day.

Do Not Measure Adoption With Login Count Alone

If 80% of users logged in once, you still know very little about whether the product succeeded.

They may have logged in because their manager told them to.

Better metrics depend on the product, but may include:

Active Users

What percentage of eligible users are actually active?

Returning Users

How many come back repeatedly?

This is often much more meaningful than first-time login.

Task Completion Rate

What percentage successfully complete the core workflow?

Time on Task

How long does a key task take?

Error and Rework Rate

How often does work need to be corrected?

Feature Adoption

Are the important features actually being used?

Old Process Usage

How many people still rely on Excel, email, or the old system?

Support Volume

Which parts generate the most questions or tickets?

User Satisfaction

How do users actually feel about the experience?

A platform is not adopted because accounts exist.

It is adopted when users regularly complete meaningful work inside it.

Averages Can Hide Problems

Imagine overall task completion is 92%.

That sounds good.

Then you segment the data:

Experienced users: 97%

New users: 64%

The story changes.

Or:

Desktop: 96%

Tablet: 68%

Or:

Sales: 95%

Operations: 70%

Performance data should be segmented.

Averages can hide serious problems affecting specific user groups.

A good metric does not only answer:

What happened?

It helps answer:

Who did it happen to?

Find the Drop-Off Points

Imagine 1,000 users start a process.

950 complete step one.

920 complete step two.

Only 580 complete step three.

Something is happening between step two and three.

Maybe:

• The form is confusing.
• Users do not have the required information.
• A permission is wrong.
• The page loads slowly.
• The terminology is unclear.

Analytics identifies the problem area.

User research explains why it happens.

That combination is powerful.

Data tells you where. Research tells you why.

Make Feedback Easy Inside the Product

If reporting a problem requires users to:

• Take a screenshot
• Find an email address
• Write down the application version
• Copy the URL
• Explain which page they were on

many will simply stop reporting issues.

A good feedback mechanism can collect context automatically:

• Page
• User role
• Browser
• Timestamp
• Version
• Correlation ID

Then ask one simple question:

What did not work?

That makes feedback easier and debugging faster.

But there is another important part:

Respond to feedback.

If users report the same issue ten times and never see anything change, there may not be an eleventh report.

More Features Do Not Automatically Mean a Better Product

One of the easiest ways to turn a good platform into a difficult one is to accept every feature request forever.

Sales asks for one option.

Finance asks for another filter.

Management wants another dashboard.

Operations requests five more fields.

Three years later, the product has 400 features and nobody knows what half of them are for.

Every feature creates ongoing cost.

Not only development cost.

It affects:

• UI complexity
• Testing
• Documentation
• Support
• Security
• Maintenance
• Training
• Performance
• The future product roadmap

Sometimes the best new feature is:

Removing an old one.

Going Live Is When Real Product Data Begins

Before launch, many product decisions are based on research and hypotheses.

After launch, something important changes.

You have real behavior.

You can see:

• Which features people actually use
• Where they abandon tasks
• What they search for
• Where errors happen
• Which workflows create support tickets
• Which parts nobody touches

This is not the end of product development.

It is the beginning of real iteration.

GOV.UK service guidance emphasizes that digital services are never truly finished and should continuously improve based on user needs and evidence.

A successful product is not one where version 1 is perfect.

It is one where:

Version 2 learned something from version 1.

A Practical Adoption Framework

How Do You Know the Team Has Actually Adopted the Platform?

Not when every account has been created.

Not when training is complete.

Not when the software goes live.

Not even when 90% of users log in once.

Real adoption happens when the platform becomes the natural path for getting the work done.

Users go there first.

They no longer need parallel systems.

They stop re-entering information elsewhere.

Old workarounds begin to disappear.

New users learn the workflow faster.

And the team can operate inside the platform without constant management pressure.

That does not happen because the interface looks good.

It starts with understanding users.

It continues with the right workflow.

It depends on integration, performance, and accessibility.

It is strengthened by training and change management.

And it improves through data and feedback.

A good platform is not something a team is forced to use.

It is something the team eventually prefers not to work without.

←Back to articles