Insight One · Payments platform · Jan – Jul 2024
Let every role see what it needs to see.
I redesigned Insight One’s payment terminal management platform: I segmented information by user type, defined rules for uploads and created its first design system.
Each stone is a metric from this case.
Support tickets vs. the three months before the project
Components in the first design system, all implemented
Modules redesigned end to end
User paths analyzed across 10 sections
Context
Insight One is Agnostiko’s product for managing payment terminals from different brands across their whole lifecycle, from a cloud console. Agnostiko hired me to redesign it; I worked with teams in Mexico, the US and Venezuela, and its first client was a Mexican bank. When I joined it had no design system: every module set its own visual criteria.
The deeper problem went beyond the interface. Every module was open to every user, there was no feedback or guidance on processes, and no clear rules for uploading key files such as databases. There were two designers; I led the negotiations with business, product, engineering and the pilot client.
My rolethe bridge between teams
There were two designers on the project. I led all the negotiations, from the pitch to defending the design decisions, and worked with product, engineering, QA, sales and the pilot client:
Design & research
- Research with four methods: interviews, moderated tests, QA feedback and a focus group
- Task flows and user flows by user type
- Low- to high-fidelity prototypes
Cross-team alignment
- Brought the pilot client’s need to the table with business
- Ideation sessions with engineering, product, QA and sales
- MVP prioritization with a matrix and MoSCoW
Design system
- Argued for an initial design system to standardize and scale
- Around 20 components, all implemented
- Style guide, typography and breakpoints
The bottleneckeveryone saw everything, nobody knew what to do
The problem wasn’t an ugly screen. The platform didn’t distinguish who should see what, and it didn’t guide the people using it.
Every module was open to every user.
Decision-makers, IT technicians and developers saw the same thing, even though they did different jobs on the same platform.
No feedback, no instructions and no rules for uploading key files.
In bulk uploads, such as databases, users couldn’t tell whether the information had been sent correctly.
“There are processes where I’m not sure if the information was sent or loaded correctly.”
Julieta · Bank Manager
“In the displayed tables, I don’t feel like we’re seeing the columns with the information we need.”
Andrés · IT Systems Manager
What I did
- Mapped task flows and user flows by user type: 32 paths across 10 sections to see where each one got lost.
- Defined rules and guidance for bulk uploads with the team: detailed error messages, a clear split between single and bulk uploads, and two-step deletion.
The disagreementbusiness scope vs. client need
The scope business had defined didn’t match what the pilot client needed to operate.
Didn’t want to include how many terminals were offline or for how long.
The defined scope left out data the client considered basic.
With that data the bank decides whether to send someone to the store to check what’s wrong.
Without it, the platform showed information but didn’t help people act.
What I did
- Brought the pilot client’s need to the table with business and defended the design that reflected it.
- Brought product, engineering, QA and sales together in ideation and technical-feasibility sessions to validate the scope before building.
What was decided
The offline-terminals data made it into the dashboard.
- That way the bank can see which terminals are failing and since when, and decide whether to send someone to check.
Decisionswhat I fought for
An initial design system before one-off screens
I argued for building components and an initial DS to standardize and be able to scale later. Around 20 components were created and implemented.
Visual and information-architecture alignment
On a platform with huge volumes of data and tables, I organized hierarchy, filters and states so the information could be read and acted on.
Uploads with guidance and clear rules
A guided flow — upload, verify, load, report — with visible states and detailed error messages.
Style guide and components
Scroll to see the full style guide ↔
Headings and subtitles in Poppins, in several weights. Body text and tags in Roboto.
Layout breakpoints were defined for desktop, tablet and mobile, specifically for the log-in flow.
Scroll to see the ~20 design system components ↓
Impactwhat changed
Support
Design system
From analysis to redesign
Source: tickets reported by support and QA in the three months before the project, compared with the period after.
Evidencebefore and after of the key modules
- Generic interface with no brand identity and a confusing flow
- Hero with a clear value proposition and integrated branding
- Data without hierarchy and a map with no useful context
- Prioritized KPIs and distribution by terminal
- Dense table with no filters and no status visibility
- Terminal KPIs, active filters and clear states
- Dense list with no categories, hard to scan
- App grid with cards and clear categories
- Process with no feedback or clear validations
- Guided flow: upload → verify → load → report
- List with no role segmentation or visible permissions
- Per-user cards with role, permissions and status clearly differentiated
What I learned
Aligning expectations is design too
Companies starting to integrate UX often expect optimal results in a single pass. Part of my job was keeping what business asked for, what the client needed and what the technical team could build aligned.
“A clear system starts by deciding who needs to see what.”
Melany Olivares