Figma Motion sequence using genuine saved-build states · Menu, setup, search, lobby, play and result · Fictional fixture data

Cowordle / Lexivanto.
The game starts before the first word.

UX Designer · Collaboration & playtesting

I help a multiplayer word game feel understandable from the invitation to the shared board.

Ongoing UX collaboration · Informal playtesting · Product in development

Ongoing UX collaboration, from finding problems to shaping changes.

Choose: Four modes establish the product before a match starts. — Genuine saved-build sequence · fictional fixture dataThese local captures show the breadth I review during ongoing collaboration; they do not claim that I designed or implemented every screen.

Genuine saved-build sequence · fictional fixture dataThese local captures show the breadth I review during ongoing collaboration; they do not claim that I designed or implemented every screen.

I work alongside the project creator, using hands-on playtesting, responsive reviews and product discussions to identify usability problems and shape changes.

I turn feedback from each play session into UX decisions; engineering and implementation remain with the developer.

The design challenge starts before the first guess: players need to understand who invited them, whose turn it is and when the match begins.

This account draws on informal play sessions and development feedback. The project creator confirmed my contribution; I am not presenting it as a formal research programme.

What play revealed.

A short decision log connects reported friction to the response it prompted. Implementation and successful retesting are separate questions.

The invitation was harder to find than it should have been.

Observed: during one reported session, I needed help finding the incoming request.

Direction: bring the request into view with explicit accept and decline actions, then enter the match after acceptance.

Requested change; independent two-device retesting is still needed.

Actual development capture + animated UX annotation
The sender can create a link. The motion isolates the missing handoff: the recipient still needs a visible place to recognise and act on the invitation.

A row needs an owner, not just a letter.

Feedback: I proposed coloured circular initial badges in place of plain row letters.

Current state: the saved build now uses circular initial badges. I have not yet retested whether players read row ownership faster.

Earlier board using plain Y and M row letters — Recorded interface change · outcome not yet validatedI proposed circular initial badges so row ownership would carry identity as well as colour. The current build now contains that pattern; I still need to retest whether players read it faster.

Current saved build using circular AE and SE owner badges beside the rows — Recorded interface change · outcome not yet validatedI proposed circular initial badges so row ownership would carry identity as well as colour. The current build now contains that pattern; I still need to retest whether players read it faster.

Difficulty and responsiveness are different problems.

Feedback: the medium bot felt too fast; later sessions also reported delays entering and starting matches.

Direction: review bot pacing separately from match synchronisation. A faster-looking interface cannot resolve a delayed shared state.

The real saved-build states establish the test context. Static captures cannot measure latency or prove that synchronisation is resolved.

Choose opponent: The player selects online, friend or bot play. — Genuine saved-build sequence · fictional fixture dataThe sequence is driven from the unchanged saved build with local fictional fixtures. Static captures show the states that need two-device timing validation; they do not measure latency.

Genuine saved-build sequence · fictional fixture dataThe sequence is driven from the unchanged saved build with local fictional fixtures. Static captures show the states that need two-device timing validation; they do not measure latency.

Make the invitation a decision, not a search task.

The existing invitation screen creates a link. The incoming-request proposal addresses a different moment: the recipient needs to recognise the invitation and know what accepting will do.

LexivantoFriends

AIncoming duel

Alex invited you to play

Shared board · No time limit

Accept & playDecline

Illustrative acceptance flow — not implemented

The interaction makes the consequence explicit: accepting moves directly into a shared room and confirms when both players are ready.

Accepting the invitation should be the start of play—not the start of another navigation task.

Keep the board, keyboard and opponent in the same conversation.

On a phone, I review whether I can keep the board, keyboard and turn context in view at the same time. Each mode changes what has to remain visible.

Proposed next checks

Receive and accept an invitation without assistance.
Start on two physical devices and compare the visible match state.
Play with board, keyboard and turn context visible on a narrow screen.
Repeat the player-chosen-word flow, including cancellation and rematch.

These are follow-up tasks, not tests completed for this case study. No success rate or resolved synchronisation claim is reported.

Duel gameplay in the saved Lexivanto phone layout — Four genuine phone statesEach mode creates a different information problem. I review the active task at phone width rather than treating responsiveness as a scaled desktop screenshot.

Four genuine phone statesEach mode creates a different information problem. I review the active task at phone width rather than treating responsiveness as a scaled desktop screenshot.

Each playthrough gives me the next problem to solve.

I contribute by identifying friction and shaping UX decisions with the project creator. I continue to review the product through play; proposals remain separate from changes confirmed in use.