work/rotom dex

rotom dex

role:ux strategy, copywriting, development

timeline:personal project

ux strategycopywritingdevelopmentdiscord botchatbot design

ask me about this project

executive summary

800+ pokémon supportanticipates user intentpersonality-driven design

Designed and developed a Discord chatbot for the Pokémon community targeting casual audiences
Implemented UX principles to anticipate user intentions and create a sense of personality
Built robust error handling with spellcheck and input leniency
Created a character-driven experience grounded in the Pokémon universe

Rotom Dex bot in action — sample of the bot in action—querying pokémon information via discord

Problem Space

Discord is a VoIP application for video game communities. In April 2016, Discord launched its official API, enabling designers and engineers to build chatbots.

This project covers the design and development of Rotom Dex, a chatbot for the Pokémon community targeting casual audiences. Goal: a robust bot that anticipates user intentions and creates a sense of personality.

project context

A personal project worked on during free time to learn app development and launch. No clear end goal—public launch vs. proof-of-concept. Without a benchmark, much of the structured UX process was stripped away, but the project still sheds light on topics like scope creep and designing with development in mind.

Goals

Design and develop a robust chatbot that anticipates user intentions and creates a sense of personality.

Process

Research

Each phase was informed by consultation with acquaintances familiar with the subject matter rather than upfront user research. Two goals guided the work:

Research goals

Determine how users interact with chatbots—the bot would be more like an encyclopedia than a conversation partner (think Siri, not Cleverbot)
Examine chatbot capabilities—understanding what existing Pokémon bots can do would inform Rotom Dex's features

The next step was examining existing Discord bots. In the Pokémon space, one stood out: Beheeyem, an official bot of the /r/Pokemon Discord server. While an impressive upgrade, Beheeyem still had room to grow in interaction design and robustness.

Beheeyem—key points

Target audience is competitive players
Detailed stat values and viability ratings are immediately visible, which can increase cognitive load
Some edge cases aren't considered—users can be misinformed about certain moves or types
Some results aren't displayed in a meaningful or logical way, forcing users to parse through to find what they need
Spellcheck catches typos but doesn't extend beyond pointing out mistakes—users must re-enter their query

Research takeaways

Users often look for a specific detail rather than all possible information—separating queries into multiple discrete functions reduces information shown at any given time
With thousands of possible queries (many with fictional game terminology), typos are inevitable—proactively anticipating user intent helps ensure the right information reaches the user
Ensuring data is correct and presented logically prevents users from consuming false information that could negatively impact their experience outside of Rotom Dex

note

Whether increasing the number of functions reduces cognitive load compared to showing more data is something to test when the bot reaches wider release.

Ideation

UX is often miscategorized as UI—chatbots and other low-visual mediums are overlooked. As AI and ML rise, the UX of conversing with technology matters more. Three topics guide Rotom Dex ideation: features and scope creep, robustness, and personality.

Features and Scope

Lack of deadline pressure and learning as the main motivator led to trying to implement everything. That soon slowed the project as attention shifted from MVP toward a polished product.

The MVP was the "dex" function: users type r.dex pikachu to get basic information (ID, type, height, weight, flavor text, 2D sprite) about any of the 800+ Pokémon. Additional features considered:

Item, move, type, and ability catalogues
Shiny sprites, stat spreads, evolutionary chains, egg groups
Competitive viability, about/help, prefix customization, easter eggs

Robustness

Pokémon terminology is often made-up or fictional—users will make mistakes. Rotom Dex includes features that prevent users from encountering errors they cannot act upon:

Spellcheck — Using the npm meant spellcheck package and dictionary tables, Rotom Dex suggests the closest result for invalid queries. Common misspellings reduce errors. Async/await lets users reply "yes" or "no" directly without re-typing.

Rotom Dex spellcheck interaction example — spellcheck suggests the closest match—rotom dex asks if the user meant thunderbolt

Multiple Input Parameters and Input Leniency — The "type" function accepts Pokémon, type, or move arguments and produces meaningful output. Users can use various delimiters for dual-types (electric-fire, electric/fire, electric fire all work).

Rotom Dex type function examples — the type function accepts pokémon, type, or move names and returns meaningful output for each

Personality

Adding a face and character increases engagement. Rotom Dex is a character from the games and animated series. Approach: script for all functions, backstory for how it arrived on Discord, and consistent speech patterns.

Design

Designing for a Chat Interface

The UI design is dictated by and limited to how Discord's interface works. Even with these limitations, thoughtful formatting is more effective than plain text.

Formatted response—more effective — formatted response—easier to scan

Plain text—less effective — plain text—harder to parse at a glance

Space, Color, Contrast

Discord's limited UI tools make space, color, and contrast more important. Beheeyem's Fire type layout is hard to scan: (x2) and (x0.5) notations add fluff, no distinction between categories and members, the donation footnote breaks immersion, and the blue accent doesn't match "Fire." Rotom Dex improves on this with thumbnail icon, color, and hierarchy.

Beheeyem Fire type display — beheeyem—dense layout, limited visual hierarchy

Rotom Dex Fire type display — rotom dex—space, color, and contrast for easier scanning

Designing with Development in Mind

The dual designer-developer role enabled concurrent design and development. Code could be changed and tested immediately—no wireframes, limitations considered during design. Technical constraints (e.g., Discord's single-embed-per-message limit) shaped how information is displayed and how users initiate conversations.

Designing Interactions

Rotom Dex uses a prefix convention (r.) to distinguish bot messages. Three scenarios: (1) valid command with valid arguments—Rotom Dex returns the info; (2) valid command with invalid arguments—spellcheck asks for clarification, user replies yes/no; (3) invalid command—Rotom Dex fails silently to avoid spam.

Prefix convention for invoking Rotom Dex — rotom dex responds when messages begin with r. and a valid command. the prefix can be customized per server if another bot conflicts.

Scenario 1: valid command response — scenario 1: r.dex pikachu—rotom dex returns the requested info

Scenario 2: spellcheck clarification — scenario 2: invalid argument—'did you mean thunderbolt?'

Scenario 2: user confirms correction — scenario 2: user replies yes or no to complete the interaction

Dealing with Exceptions

Rotom Dex handles edge cases where information deviates from normal game mechanics. For example, Electric-type Pokémon with Levitate are immune to Ground-type moves. The ※ footnote informs users of these exceptions.

Electric-type with Levitate exception — electric-type with levitate—footnote (※) explains the ground immunity

Flying Press move exception — flying press (fighting + flying) requires special type matchup handling

Outcomes

Rotom Dex was tested by a small group from its target demographic throughout design and development. As a personal project, it has enough core functionality to be considered fully featured.

Future considerations

Short-term

Launch to a wider audience by advertising in Reddit and the Discord bot community
Use increased user volume to pinpoint key usage metrics
Probe for pain points users may encounter
Add or change features based on insights gained

Long-term

Migrate from offline database to an online resource such as PokéAPI
Implement more interactable UI elements such as reactions
Create a different interaction model in direct-message threads—e.g., ML-based NLP instead of rule-based
Adjust or update the database for future Pokémon versions

Learnings & Reflections

what i'd do again

Concurrent design and development - being able to build and test simultaneously was a huge benefit
Anticipating user intent - robust error handling and input leniency improved user experience significantly
Personality-driven design - adding character and voice increased user engagement

what i'd do differently

Better scope management - the lack of deadline pressure led to scope creep that slowed development
More user research upfront - testing with a wider audience earlier would have provided better insights
Clearer MVP definition - establishing a clear minimum viable product earlier would have helped focus efforts

next:zboard companion app →