Shori

Overview

Shori is NTT DATA's Efficiency Suite, a SaaS tool to manage, automate, and streamline BPO services, integrated into the Clonika ecosystem. It is a multiclient, multirole, and highly configurable product, where each organization adapts its services, workflows, and permissions to its own needs.

I joined the project to lay the design foundations and give shape to a product built from scratch. I worked as a hybrid Product Designer and Product Strategist, defining the information architecture and the screens, along with the look and feel of the tool. I led the decision to functionally validate the user flows before moving forward, to surface the information that was not yet resolved. The core challenge was ordering a complex, highly configurable system into clear, efficient interfaces for each type of user.

Product Outcomes

MVP delivered and deployed to production, with the product in real use.
Information architecture and user flows validated with users before development.
Scalable, client-themeable visual design system established as the product foundation.
Design foundations that supported the product's evolution beyond the MVP.

Shori task management interface shown on a desktop iMac — Inbox view listing BPO service tasks with status filters and multi-column data table

Context

Shori was conceived as NTT DATA's own product, not as a commission for a single client. The goal was to offer a tool able to adapt to the specifics and scale of any organization managing BPO services, with teams spread across the country. That meant designing from scratch, with no previous tool to build on, and serving many different clients and roles at once.

Goal

Build a flexible, configurable tool to manage, automate, and streamline BPO services, on three core premises:

Multiclient and multirole, with a single stable version of the product.
Workflow and form configuration within reach of users themselves, without depending on development.
Usability and consistency in a system with heavy parameterization.

Challenges

Ordering a hierarchy with many levels, client, tenant, service, process, and product, alongside a permission system, and near total configurability across workflows, forms, statuses, and SLAs, without losing the user or the product's usability.
Designing for operational efficiency. Users handle as many tasks as possible, so every click counts. Reducing clicks and steps was key to not penalizing their productivity.
Designing a scalable, themeable visual system. The interface had to stay simple and work as a neutral base, able to take on each client's corporate colors without redesigning the tool.
Verifying on screen that each flow was complete, with no gaps, before building, since requirements came from the functional team.

Understanding
the users

The research was carried out by the research team (6 users across 5 profiles, plus 2 individual interviews), and the functional team brought the requirements and the knowledge of users and their needs. I came in on that basis to translate that knowledge into screens, shaping a design that responded to each profile and validating that the flows served their real work.

The tool is multirole and permissions are configurable. The design centered mainly on two operational profiles with very different needs, Coordination and Operation, alongside a third, more administrative profile.

Coordination.

Their goal is to oversee and distribute the team's work.

They need an overview of assigned and unassigned tasks, the ability to assign and reassign quickly, prioritize and filter, and track SLA compliance.

Operation.

Their goal is to handle as many tasks as possible. They open each task, complete the information, change its status, and move on to the next.

They need a focused, frictionless environment where every step counts and nothing distracts them from operating. The tool had to feel as familiar as their email inbox, but faster and more structured.

Administration.

Administration profiles configure clients, projects, roles, users, and workflows. They are not the day-to-day operational focus, but they shape all the flexibility of the product.

This difference in goals, operating fast versus overseeing and distributing, is what drove the design of two distinct workspaces within the same tool.

Approach

01. Functional discovery and information architecture

Before designing screens, I led the decision to functionally validate the user flows. Requirements came from the functional team, but as I brought them to the screen, gaps appeared: unresolved information and decisions that had not yet been made. Reviewing each flow visually was the way to surface those gaps before building, not after.

From there, I ordered the information architecture around the product hierarchy, client, tenant, service, process, and product, and translated it into navigation the user could understand without knowing that structure from the inside.

Information architecture diagram for Shori, mapping the product hierarchy from client and tenant down to service, process and product, with the resulting navigation structure

02. From requirements to screen: design and user validation

Before implementing, I translated functional requirements into visual proposals and validated them with users to make informed decisions, not just intuitive ones. The goal was to surface problems at the screen level before reaching development.

One example of that validation was the case creation screen. The user must select the case status before finalizing it, and we had to decide where to place that action. Before implementing, I compared two design proposals and validated them with several operational users:

Comparison of the two design proposals for the case status selector in Shori's case creation screen

Design proposal comparison — Option 2: case status selector placed in the footer, next to the create and cancel actions

Option 1

Placing the statuses in a fixed top block, anchored to the header on scroll, so it stayed visible while the case was being completed.

Option 2

Placing the statuses in the footer, next to the create and cancel buttons, at the end of the creation flow.

After validating them with users, I chose the second. Placing the status at the end, next to the create or cancel actions, better matched the natural order of the task, first you complete the case, then you decide its status, and it left room to resolve the additional edge cases that came up when finalizing a case.

03. Scalable, themeable design system

I defined the look and feel and a visual design system meant to act as a simple, neutral base, built to scale from the start. The key was that the interface could take on each client's corporate colors without redesigning anything, so the product could grow to new brands by changing only the visual layer.

The design system defined the product's visual layer, and development implemented it on the Chakra component library. Relying on a robust library instead of building components from scratch was a pragmatic decision to launch a scalable, consistent MVP without slowing the delivery pace.

Design system for Shori showing color palette, button variants, typography scale, table, stepper, form components, and icon set

Solution

The core of the tool is the Inbox, the space where the user sees and manages their work. It is the screen that best captures the product's challenge: bringing order to a large amount of information and possible actions in a clear, operational view.

The Inbox brings together the task list with its filters, priority, SLA tracking, and actions for each task. It was designed to adapt to each user's role and to make operating fast, with the minimum number of clicks, on a neutral and scalable visual system capable of adopting each client's brand identity.

My contribution focused on the MVP and the evolution of several screens from it, laying the design foundations on which the product continued to grow.

Role Coordination and Operation

Shori Administration view — client management list with NTT Utilities branding showing active clients, statuses and access controls

Role Administration

Learnings

Validating before building saves more than it costs.

Bringing requirements to the screen and reviewing them with a critical eye surfaced gaps and pending decisions that, left undetected, would have carried over into development. But before validating, you have to align: understand the team and the requirements well, understand the user, and only from there define the screens with judgment for each type of profile. Stopping to validate didn't slow the project down, it protected it.

In an operational tool, every click counts.

Thinking about design in terms of efficiency, not just clarity, changes the decisions you make. One extra step is multiplied across hundreds of tasks a day, so reducing friction is a direct impact on the user's productivity.

Design to scale from day one.

Defining a neutral visual system and relying on a robust component library wasn't a limitation, it was what let the product grow to new clients and keep evolving on solid foundations.

SaaS Efficiency Suite for managing BPO services