Systems UX Research | Workflows, Internal Tools & Dashboards

Systems research

Study the work, not just the screen

People rarely complete a workflow inside one tool. They may search for information, update records, request approval and pass a task to another team. A usable screen can still be part of a difficult process when information is missing, responsibilities are unclear or users have to repeat the same work.

UX Pacific studies how people experience internal and operational systems. We connect interface use with tasks, roles, rules and handovers to help your team understand what needs attention. This can involve software, manual processes and the transitions between them.

When to research

When systems research is useful

Use this study area before selecting or replacing a tool, redesigning a workflow or rolling out a new system. It is also useful when teams report difficult onboarding, frequent help requests, duplicated records, workarounds or inconsistent task completion.

A small team may need to investigate one approval process. A growing business may need to understand work across several tools. An enterprise may need evidence across roles, departments or markets. We scope the study around a decision and a manageable set of workflows, rather than treating every system as one large project.

What we investigate

Questions we help you answer

Can users find the information needed for their task? Do labels, dashboards and status messages make sense to each role? Where do people switch tools, copy information or wait for permission? What happens when a task is rejected, interrupted or handed over? Which difficulties come from the interface, and which require a process or policy decision?

We also investigate how new users learn the system and how experienced users manage exceptions. These perspectives help distinguish a learning difficulty from a recurring barrier that training alone may not resolve.

01

Internal tools and business platforms

Explore tasks in customer management, administration, HR, finance, inventory or operational tools. The emphasis is on what people need to do and how the tool supports that work, not on auditing the software architecture.
02

Approvals, handovers and shared responsibilities

Study requests, review steps, permissions and transitions between teams. Identify unclear ownership, missing context and repeated steps, including the manual work that sits outside the formal process.
03

Dashboards, records and decisions

Examine how users interpret reports, locate records and understand alerts or task status. Research can assess comprehension and usefulness; it does not independently certify the accuracy of underlying data or business calculations.
04

Onboarding, exceptions and recovery

Explore initial learning, help resources, interruptions and recovery from mistakes. Understand whether people know what to do next and can obtain appropriate assistance without losing task context.

Who to include

Include the right roles and conditions

The same workflow may look different to the person entering a request, the approver and the administrator. We agree which roles and experience levels to include, along with relevant access needs, locations and working conditions. Research focuses on the system experience, not judging individual employee performance.

For multi-market or distributed teams, we consider language, local processes, time zones and permissions. Shared tasks support comparison, while differences in workflow and system configuration are documented. We confirm recruitment and access feasibility before committing to the scope.

Our approach

How we gather evidence

Task & Workflow Analysis examines the steps, information and dependencies involved in work. Contextual inquiry explores actual use, while interviews help explain goals, constraints and workarounds. Usability testing investigates agreed tasks in an existing system or prototype.

Where available and authorised, support records, training materials and usage data can add context. We distinguish observed actions from reported difficulties. Task time and errors can be measured under agreed conditions, but a test result is not automatically an organisation-wide productivity estimate.

From insight to action

From the research question to practical priorities

We first clarify the decision, selected workflows, user roles and available systems. We agree access arrangements, test environments, participant criteria and outputs. Where live work contains sensitive information, suitable alternatives such as masked records or representative test data are considered.

Findings connect difficulties to specific tasks and conditions. We discuss improvement options with your team, separating interface changes from process, policy or technical dependencies. Proposed changes can then be tested where further validation is needed.

The output

What your team receives

Agreed outputs can include workflow maps, role-specific needs, task-level findings and prioritised experience barriers. Recommendations explain the evidence, affected users and dependencies your team needs to consider. Training or support gaps may be documented alongside interface issues.

A findings discussion helps product owners, operations, IT and learning teams agree next steps. The proposal specifies deliverables, any measures to be collected and whether follow-up testing is included. Research does not imply that system changes or software implementation are part of the engagement.

Research in context

Different roles, teams and markets

The same workflow may look different to the person entering a request, the approver and the administrator. For multi-market or distributed teams, we consider language, local processes, time zones and permissions, documenting differences in workflow and system configuration.

Find the right service

Choose the service around your decision

Explore System Experience Research for a focused study. Employee Experience considers the wider work experience. Service Design can connect workflows with service delivery, while Technology Experience may be relevant when the question centres on interacting with a new technology.

Research principles

Confidentiality, participation and study limits

We agree participant consent, recording permissions, authorised access and the handling of confidential material. Findings should be shared at an appropriate level without unnecessarily identifying individual staff members. Research sessions must not interfere with essential operations or require unsafe actions.

Systems UX research is not a cybersecurity assessment, technical performance audit or compliance certification. Findings reflect the roles, tasks and conditions studied. Recommendations inform decisions; they do not guarantee savings, fewer errors or successful adoption without implementation and subsequent evaluation.

Before we begin

Frequently asked questions

Can you study third-party or legacy systems?

Yes, where access can be arranged. We identify experience barriers and distinguish changes your team controls from those requiring a vendor, technical team or process owner.

Do you need production access?

Not always. A test environment, prototype or walkthrough may be suitable. We agree the safest workable approach and document any limitations compared with live use.

Can research support a system migration?

Yes. Research can document current workflows, investigate role-specific needs and test proposed tasks before rollout. Data migration, integration engineering and deployment remain separately scoped activities.

What should we share to start?

Tell us about the system, relevant roles, selected workflows, known difficulties and the decision you need to make. Include timing, access restrictions and available evidence. You do not need to choose a research method first.

Systems