SYSTEMSLens
Before I designed anything, I studied how each partner worked. They all did the same basic things, just in their own way. So I built one system that fits everyone. Nobody had to change how they work.
02 · RAKUTEN · 2018–2020 · ROLE: LEAD UX DESIGNER
Every partner testing devices in one lab, finally run as one system.
- Situation
- Rakuten’s lab teams were managing device testing across many partners, each with its own way of working, and no one view of what was happening.
- Clarity
- I studied how each partner actually worked, found what they had in common, and designed one portal everyone could run on.
- Shipped
- A portal where every team could see the work, track it, and act on it, on desktop or on a tablet in the lab.
Built forWebTablet
01 · The mess
Rakuten's lab tested devices for many partner companies. Each one worked its own way, with its own handoffs and its own quirks.
That made the whole operation hard to see. Technicians wanted to know their next step without more admin. Managers wanted one view of what was moving, what was stuck, and what had passed.
So the job was never really "design some screens". It was to understand every different way of working, and find the one system underneath them.
- 01Every partner tested devices their own way
- 02Nobody could see where a test had got to
- 03Tracking was manual, across too many tools
- 04Managers had no single view of the lab
- 05One portal had to fit all of them
02 · The work
Research
Each partner had built their own testing software and their own way of running it. I started by reading all of them and settling what we were actually building.
Partner
Own software
Own way of testing
Built independently, for its own way of working.
Partner
Own software
Own way of testing
Built independently, for its own way of working.
…and more
More of the same
Each one different
Several OEM partners, each with its own stack.
read them all, then scope
One shared scope
What every partner genuinely had in common, and what had to stay theirs.
Iterations
This one did not need many rounds. We agreed what we were building before design started, so the hard part sat somewhere else: making a huge amount of data readable.
The material
Test cases, runs, defects, nodes, versions, owners, across every partner at once.
The screen
Status
Issue
Node · version
Defect ID
One row per issue, ranked so triage happens before reading.
- We only needed one or two rounds of changes. That is rare. It worked because everyone agreed early on what we were building.
Collaboration
I worked across three companies at once: employed by Infosys, engaged by Cisco, building a portal Rakuten owned.
Three companies, one project
Infosys
Employed me; the delivery team
Cisco
Engaged me onto the project
Rakuten
Owned the portal
Reported to
Cisco's CTO, with Rakuten's own team
Day to day
Senior developers, and the CTO directly
- The portal housed the software of major global device manufacturers, partner names protected under NDA
03 · The big calls
PRODUCTLens
A screen that just shows numbers was not enough. People needed to spot what was stuck and fix it right there. And what each person sees depends on their job.
EXECUTIONLens
This one had to get built, so the work went all the way from understanding people to wireframes to finished UI. Two very different people use it. A technician standing at a bench, and a manager checking progress from a desk.
04 · The build
FIG 02.1MULTIPLE OEM PARTNERS · ONE PORTAL
OEM 01OEM 02OEM 03One shared way of workingPortalmany flows → one system
FIG 02.2
FIG 02.3
FIG 02.4
FIG 02.5
FIG 02.6
Problem → part
- Many partner ways of workingOne way to run the lab
- Fragmented status handoffsOne view of every test
- Manual tracking and context switchingStatus that updates itself, and a clear next step
- Manager uncertaintyRole-based dashboards and analytics
- Lab-floor access needsTablet-ready testing views
05 · The facts
★ Ryan Soni
Case 02 · RAKUTEN · 2018–2020
3
Companies involved
2018–20
Timeline
Shipped
Status
- Role
- Lead UX Designer. I read how the partners worked, mapped it, then did the wireframes and the UI
- Who was who
- I worked for Infosys. Rakuten owned the portal. Cisco and Rakuten were the clients
- Who I answered to
- Senior people at Cisco and at Rakuten, through discovery, design, and review
- Users
- Lab technicians, the managers above them, and leadership
- Product
- The Rakuten Lab Management Portal, for testing devices
- Scale
- Testing ran through it for many partner manufacturers
· Outcomes ·
The team told us there was less manual tracking and less jumping between tools, and they took to it well. Nobody measured it, so I will not put a number on it
The real screens are protected. Everything here is rebuilt from memory
06 · The takeaway
Enterprise portals are rarely hard because of the screen. They are hard because the work underneath is split across too many places. This is what I do about that.