Designing complex SaaS workflows: lessons from Keeyu

Complex software needs to help people understand where they are, what has happened and what they can do next. Simplifying the interface starts with those questions. Removing controls or adding more space can make a screen quieter while leaving the difficult decision untouched.

Keeyu manages post-purchase operations for large retailers. Its product brings together brands, sales channels, integrations and operational workflows. Our published project account describes work on the structure connecting those parts, alongside the screens people use to set up and operate the platform. This article draws out the design decisions in that account and offers a way to review similar problems in another product.

1. Start with the relationships, then draw the screens

In her account of the project, Refract designer Lan explains how the team worked from the actual product and its underlying relationships. A screen could look coherent in isolation while leaving customers uncertain about how their settings, data and actions fitted into the wider system.

That is a useful starting point for any workflow review. Choose one task and map its dependencies. Which account or workspace owns the record? What must be configured first? Who can change it? What happens to the next step if the current one fails? These questions often reveal why a journey is confusing before any visual design begins.

• Name the thing the person is working on and keep that identity visible.
• Distinguish prerequisites from optional improvements.
• Show which decisions affect the current record and which affect a wider account.
• Map how someone resumes the task after an interruption.

Those are review prompts, not a claim that every item was a measured problem at Keeyu. They turn the same structural concern into a practical audit for your own product.

2. Make progress informative

The Keeyu account describes using hierarchy, grouping, progress and guided actions to help customers follow setup and operational flows. The intention was to retain useful context without presenting every detail at once.

A progress indicator earns its space when it answers a real question. A numbered sequence can show how far through setup someone is. A status can explain whether information is saved, being checked or ready to use. A grouped checklist can make a long task manageable. The right pattern depends on the work; adding a progress bar does not establish that the user knows what to do.

Consider an illustrative integration flow: entering credentials, checking permissions and importing records are different states. Calling all three “Connected” hides the distinction between a successful login and a usable integration. The interface should reflect the actual system state and explain what action, if any, the person needs to take.

3. Put help where the decision happens

For Keeyu, the team designed guidance to sit alongside the customer’s work. Lan’s account describes connecting a question to the relevant area of the interface and refining buttons, highlights, tooltips, panels and content states so that guidance felt part of the product.

The broader lesson is to give help a job. A tooltip can explain a term. An inline message can explain why a field needs attention. A guided action can take someone to the relevant setting. Each should preserve enough context for the person to understand why they arrived there and how to continue.

Review the escape route too. Can someone dismiss the help, return to their task and find it again? Useful guidance gives a person more control over the work. It should not make them complete a tour before reaching an urgent task.

4. Use the design system to carry behaviour

The published Keeyu story describes designers working with engineers on reusable patterns and reviewing decisions in staging. The design system supported implementation as well as visual consistency.

That suggests a more useful component review than checking whether two buttons look alike. Compare what they mean. Does saving close the panel or keep it open? Where does validation appear? Does an empty state explain the absence of data? Which action can be undone? Reusing a component without agreeing those behaviours can reproduce the same ambiguity across a product.

Write down the content and state rules alongside the visual specification. Then inspect representative records in the built product: empty, ordinary, unusually long and incomplete. A convincing design file is only one part of the evidence.

5. Take one difficult journey into the next review

Start with a customer task that support or product teams can describe precisely. Gather the existing flow, representative records and any available observations. Review structure, progress, guidance and recovery together, then prototype the highest-priority change with the engineers who will build it.

The Keeyu account supports the design approach and the work described here. It does not supply a measured conversion or task-completion uplift, so we do not attach one to it. For your project, agree the baseline and success measure before release. That makes the next review about whether the task improved, as well as whether the interface looks better.