Designing the MINGO ecosystem

MINGO started as a wallet, but it had grown into a much larger product spanning Wallet, Tickets, NFT Collections, Market, Play, profiles, rewards and community features. The main challenge was no longer one screen or one flow — MINGO needed a clear system that could connect all of these services.

Over four weeks I redesigned the public website and the main mobile app flows. The work covered 7 website pages, 10 app areas and 8 main parts of the ecosystem. I also reviewed the old screens that were available: a wallet audit found 24 usability and trust issues, five of them critical because they could affect account privacy, wallet recovery or financial transactions.

The project began with a single screen. After the client approved the first direction, they shared more of the product and asked me to continue — so the work grew into a redesign of the wider MINGO ecosystem.

MINGO was moving beyond a wallet. A user could manage assets, buy tickets, view NFTs, explore a market, play games and manage a profile — with rewards and community features still to come. That created a basic product question.

The scope also kept growing during the project. I had to design the screens the client needed at that moment while creating patterns that could carry the next feature. If I had designed every request separately, the result would have looked like several different products.

The problems were visible. The old landing page tried to explain almost everything on one long page — company story, problem, solution, B2B and B2C services, technology, token, app features, team, roadmap, FAQs and several competing calls to action. The available wallet screens showed a different problem: important actions were possible, but users were not given enough help at risky moments — most visibly during login, wallet recovery and sending assets.

I had one old landing page and nine old wallet states. I did not have old screens for every MINGO service, and I had no user interviews, support records or product-performance data. So I did not invent problems for screens I had never seen. I used the available information in four ways.

This kept the case study honest: the wallet findings are based on visible old screens, while the wider ecosystem work shows my design decisions for areas where no old screens existed.

I started by listing every website page and app flow the client shared, grouping them into public discovery, account access, security, wallet, tickets, digital assets, Play and Profile. Placing the flows on one large board revealed missing states and repeated patterns — account checks, loading, errors, confirmations and success messages appeared across the product. I then chose each method based on the problem I was solving.

The old landing page held a lot of useful content, but too many messages shared one long journey. From the screenshot I could clearly see five problems.

I changed the website from one long page into seven focused pages: Landing, About, Market, Play, Wallet, Launch and MINGO Tickets.

I reviewed nine old wallet states using Nielsen's usability heuristics and a step-by-step task review. The level shows how serious a problem could be — not how often it happened, because I had no usage data.

The old text often described the system or used a generic button label. I changed it to explain the result and help the user choose the next step.

The website review, wallet audit and ecosystem map pointed to the same five needs.

I did not have data showing how often each problem happened, so I used four questions to prioritize: How serious could the mistake be? Could the user fix it? How many other screens depended on this decision? How important was the journey to MINGO's main value?

A short timeline meant every preference could not become a new direction. Five shared rules kept the ecosystem coherent.

The wallet needed to support asset management while connecting users to Tickets, Market, Collections and Play. I treated it as the primary home base, with ecosystem products revealed as connected destinations rather than competing navigation. The new hierarchy separated wallet actions, ecosystem destinations, and account or security controls so users always understood where they were and where they could go next.

On the public side, I divided the old long page into seven clear destinations — each with one main message and one main action, reusing sections for features, previews, proof, downloads and footers so the site felt consistent without every page looking the same.

Onboarding answered three questions — what is MINGO, what can I do with it, and why create or access an account? After onboarding I separated sign-up, sign-in and recovery so users chose the right path before entering personal details, and the verification flow handled code entry, editing, resend, expiry, error and success without forcing a restart.

Passcode protection became a shared part of the app — creation, confirmation, mismatch, incorrect entry, retry, successful access, and fingerprint or face access where supported. The same pattern then protected wallet recovery, important settings, transfers and Market actions, so security felt expected rather than random. Recovery carried extra guidance because the cost of a mistake is high: users first learned what the phrase controlled, saw it with clear safety instructions, and confirmed selected words before the backup was marked complete.

I arranged Wallet home around the user's main needs — see balance and account, receive or send, review assets and updates, and get help when the wallet is empty. Sending assets was restructured so the right information arrived in the right order, and each stage answered a different question at the highest-risk point in the wallet.

As the project grew, reusable patterns became necessary. I standardized navigation, buttons and action states, forms and help text, account and approval steps, screen states, transaction summaries, cards and the security language — plus colors, type, spacing, icons, contrast and touch targets. This let Wallet, Tickets, NFTs, Market and Play keep their own character while still feeling like MINGO, and gave developers a smaller set of components and states to build.

Gave more time to high-risk flows. Login, recovery and transactions received the most detail because mistakes there have serious results.

Added security without slowing every action. Extra checks appeared only for showing a recovery phrase, creating a passcode, sending assets, listing an item or completing a purchase.

Kept important Web3 information visible. I reduced difficult language while keeping network, address, fee, balance, total and asset status visible when they affected a decision.

Kept promotion away from the main wallet task. The wallet's first job is to manage assets, so promotional content moved aside while clear paths to the rest of the ecosystem stayed.

Let each service have its own character. Tickets and Play could carry stronger imagery and energy; Wallet and Market stayed focused on detail and trust — with the same controls and behavior underneath.

I would test the basic journeys first, then Tickets, NFTs, Market and Play in separate sessions, using test accounts and sample assets so no participant risks real money or private information.

The hardest part was not drawing more screens — it was keeping the experience clear while the brief grew from one screen into a full website and app.