SaaS Redesign Research Framework · CHAPTER 4 OF 5

Workflows, roles, and competitors

Step 3 Software Workflow Research

Understand the Real Workflow,
Not Just the Software Flow

Software workflow research helps the design team understand how work actually happens in that software process.

What the complete industry
workflow looks like

Where this product fits in the
larger process

Whether the product covers the full workflow or only one part of it

Which steps still happen offline, manually, or outside the system

It helps identify:

Understand the Real Workflow, Not Just the Software Flow

Software workflow research helps the design team understand how work actually happens in that software process.

It helps identify:

What the complete industry workflow looks like

Where this product fits in the larger process

Whether the product covers the full workflow or only one part of it

Which steps still happen offline, manually, or outside the system

If the Workflow Is Misunderstood, the Redesign Breaks the Process

Without workflow research, the design team may only redesign what they see on the screen. But in SaaS software, the Software may represent only one part of a much larger process.

Process Gaps

Redundant Steps

Incomplete Paths

Navigation Issues

Process Gaps
Redundant Steps
Incomplete Paths
Navigation Issues

If the Workflow Is Misunderstood, the Redesign Breaks the Process

Without workflow research, the design team may only redesign what they see on the screen. But in SaaS software, the Software may represent only one part of a much larger process.

Process Gaps

Redundant Steps

Incomplete Paths

Navigation Issues

If the real workflow is misunderstood

Place actions in the wrong sequence

The designer may:

Miss offline or manual steps

Hide critical checks

Create confusion between departments

Design a flow that does not match how users actually work

If the real workflow is misunderstood

The designer may:

Place actions in the wrong sequence
Miss offline or manual steps
Hide critical checks
Create confusion between departments
Design a flow that does not match how users actually work

If the real workflow is misunderstood

The designer may:

Place actions in the wrong sequence

Miss offline or manual steps

Hide critical checks

Create confusion between departments

Design a flow that does not match how users actually work

The redesign must support the real process behind the software.

“A clean interface is not enough.“

The redesign must support the real process behind the software.

Example

In a BMR workflow, we found that shift handoff was happening manually outside the software.

But this was a critical step because it recorded who completed the task, who continued it, and when responsibility changed.

If workflow research was skipped, this step would have been missed completely.

This is why workflow research is important. It helps uncover hidden manual steps that are critical to the real process.

Software Process

Open

Button

User clicks

Offline Process

User clicks

Save

Manual
Handoff

User clicks

Example

In a BMR workflow, we found that shift handoff was happening manually outside the software.

But this was a critical step because it recorded who completed the task, who continued it, and when responsibility changed.

If workflow research was skipped, this step would have been missed completely.

This is why workflow research is important. It helps uncover hidden manual steps that are critical to the real process.

Software Process

Open

Button

User clicks

Offline Process

User clicks

Save

Manual
Handoff

User clicks

Step 4 User Role Involved

Identify Who Uses the Software

At this stage, the goal is not to create detailed personas yet.

The goal is to get a clear understanding of all user types involved in the software.

Illustration accompanying Identify Who Uses the Software

Identify Who Uses the Software

At this stage, the goal is not to create detailed personas yet.

The goal is to get a clear understanding of all user types involved in the software.

Job Role & Description

Department

Qualification required

Responsibilities

Who does he report to

Characteristics

who works with him

Identify

Who uses the software and what each role is responsible for.

Identify

Who uses the software and what each role is responsible for.

Job Role & Description

Department

Qualification required

Responsibilities

Who does he report to

Characteristics

who works with him

This gives the design team an initial understanding of who uses the product and what each role is expected to do.

Detailed user insights are captured later during the User Persona stage.

This gives the design team an initial understanding of who uses the product and what each role is expected to do.

Detailed user insights are captured later during the User Persona stage.

Step 5 Competitor Analysis

The Final Research Step: Competitive Analysis

Competitor research helps us understand what the market already expects from similar software.

It helps us identify standard features, common UX patterns, and gaps where the product can improve beyond competitors.

Illustration accompanying The Final Research Step: Competitive Analysis

The Final Research Step: Competitive Analysis

Competitor research helps us understand what the market already expects from similar software. It helps us identify standard features, common UX patterns, and gaps where the product can improve beyond competitors.

It helps identify:

Standard features competitors already provide

Common layouts and navigation patterns

Useful workflow structures

Reporting and dashboard expectations

Gaps where the product can improve

It helps identify:

Standard features competitors already provide
Common layouts and navigation patterns
Useful workflow structures
Reporting and dashboard expectations
Gaps where the product can improve

It helps identify:

Standard features competitors already provide

Common layouts and navigation patterns

Useful workflow structures

Reporting and dashboard expectations

Gaps where the product can improve

There are two types of competitors
to study:

Direct
Competitors

Indirect
Competitors

There are two types of competitors to study:

Direct
Competitors

Indirect
Competitors

Direct Competitors

Direct competitors are products that solve the same core problem for the same type of users.

They help us understand what users already expect and where the product can stand out..

For example, for a BMR product, other Batch Manufacturing Record software would be direct competitors.

Competitor 1

Competitor 2

Direct Competitors

Direct competitors are products that solve the same core problem for the same type of users.

They help us understand what users already expect and where the product can stand out..

For example, for a BMR product, other Batch Manufacturing Record software would be direct competitors.

Competitor 1

Competitor 2

Indirect Competitors

Indirect competitors are not direct alternatives to your product, but they have one feature or workflow that overlaps with yours.

Example: A BMR product had a warehouse module, so we studied Zoho Inventory for inventory and stock movement flows.

It is not a BMR competitor, but it solves one overlapping workflow well. Making it an indirect competitor.

ZOHO

Inventory

BMR

Indirect Competitors

Indirect competitors are not direct alternatives to your product, but they have one feature or workflow that overlaps with yours.

Example: A BMR product had a warehouse module, so we studied Zoho Inventory for inventory and stock movement flows.

It is not a BMR competitor, but it solves one overlapping workflow well. Making it an indirect competitor.

ZOHO

Inventory

BMR

The goal is to understand market standards, user expectations, and opportunities to make the product better.

The goal is not to copy competitors.