Configuration Provider
A transformative solution for RubyPlay’s integration process, addressing critical operational inefficiencies that previously limited scalability. This internal web-based application streamlines the configuration of operators, brands, games, and currencies—replacing an error-prone CLI interface with an intuitive hybrid solution combining a web-based UI and a JSON-based CLI system.
My Role
Product Owner & Designer
Activities
Research, IA, Prototyping
Environment
Web Desktop
Timeline
June 2020 – June 2021
01
CHAPTER
Intro
In the introductory section of this UX case study, I will provide a brief overview of the company and the design challenge that was addressed. I will also introduce the specific opportunity that the project aimed to capitalize on, along with the KPIs that were established to guide the design process and measure success.
ABOUT THE COMPANY
As a self-confessed progressive iGaming development studio, RubyPlay also offers value-add tools aimed at improving player experiences and facilitating operations for iGaming operators.
35
Casino partners
1.78
Millions in EUR Revenue
5.73
Millions Gaming Transactions
Numbers based on Rubyplay internal report for 2020.
THE CONTEXT
RubyPlay aims to expand its business by onboarding 70 new operators in Q2 2021, requiring an integration process that is fast, scalable, and error-free.
Before the introduction of the Configuration Provider Tool, integration engineers relied on a command-line interface (CLI) for operator, brand, game, and currency configurations. This process presented multiple challenges:
01. High complexity & error-prone setup
due to manual configuration
02. Lack of visibility
for non-technical stakeholders
03. Slow iterations & updates
when new configuration requests were made
04. Limited scalability
to handle multiple integrations at once
Existing issues of the tool
Before exploring potential solutions, we first focused on clearly defining the problem statement. This step was crucial in ensuring alignment among stakeholders, avoiding design decisions based on assumptions, and addressing the root cause rather than just surface-level symptoms.
How can we improve RubyPlay’s integration process so that both engineers and non-technical staff can configure new operators more efficiently while maintaining technical integrity?
GOALS
Defining success
To meet this target of 70 new customers by the end of 2021, the Platform development team has been assigned 3 key results as part of OKRs.
Business objectives
Success metrics
- Decrease integration time
Cut integration time by 50%
- Simplify the configuration process of operators and brands
Integration team should be able to handle 5 integrations at a time by the end of Q2 2021
- Define configurations defaults to be used when operators have no preferences
Identify gaps to support 10 concurrent integrations for the 2nd half of the year
DESIGN CHALLENGE
Design a solution that combines the strengths of both worlds – CLI & GUI
My challenge as a Product Designer was to create a solution for developers who, as experts, prefer using a CLI but struggle with the inefficiencies of copy-pasting JSON data, making a GUI less appealing for them.
Key Considerations:
- The solution must preserve the existing data model and hierarchical configuration structure (system defaults, operator settings, brand-specific settings)
- Integration engineers require granular control over complex JSON configurations
- The solution must integrate seamlessly with existing back-office systems
- Any approach must support both technical precision and operational efficiency
02
CHAPTER
Discovery
As part of the Discovery phase of this case study, I employed research methods to gain a better understanding of the project. These included Stakeholder Interviews & Requirements Gathering, User Research with Integration Engineers and Analysis of Current Integration Workflow.
UNCOVERING requirements
Stakeholder interviews
Screenshot from a call with Integration Engineers explaining their current workflow (which also included the use of Excel spreadsheets and VBA)
The discovery process began with structured interviews across multiple departments to establish a comprehensive understanding of integration requirements and constraints. Key stakeholders included:
- Integration Engineers: Provided detailed insights into the current workflow, pain points, and time-consuming aspects of the configuration process
- Server Team Lead: Outlined the technical architecture, API capabilities, and data model constraints
- Business Development: Shared customer acquisition targets and integration timeline expectations
- Product Management: Aligned the project with broader company initiatives and prioritized feature requirements
These interviews revealed that while the underlying API service was technically sound, the interface severely limited productivity. Integration engineers spent approximately 70% of their time on manual configuration tasks using the command-line interface, with each new customer requiring 8-12 hours of detailed configuration work.
USER RESEARCH
Analysis of the existing workflow
To gain deeper insights into the daily challenges faced by the primary users, I conducted extensive call sessions with the integration engineers.
Screenshot from a call with Integration Engineers presenting their database schema
Key observations included:
- Engineers maintained extensive documentation and checklists to avoid configuration errors
- The command-line interface required perfect syntax and offered limited error recovery
- Engineers developed workarounds for bulk operations by creating custom scripts
- Verification of configurations required running additional queries and manual checks
- There was no simple way to clone configurations between similar operators
- Changes requested by existing customers required revisiting complex configuration sequences
The engineers’ expertise in working with the technical interface was impressive, but the process clearly imposed significant cognitive load and created unnecessary technical barriers to what was essentially a data management task.
Screenshot of an actual list of configurations for an operator
We mapped the entire integration workflow from initial customer entry creation through to live deployment. The configuration process included these primary stages:
01.
Creating the operator profile with basic details and technical parameters
02.
Configuring supported currencies and exchange rates for the operator
03.
Setting game availability and parameters at the operator level
04.
Creating and configuring individual brands under the operator
05.
Customizing currency and game settings at the brand level when different from the operator defaults
06.
Testing and verification of all configurations
07.
Deployment to production environments
List of setup stages
Each stage involved multiple command-line operations, with engineers carefully tracking progress through spreadsheets and documentation. The process lacked visibility for other stakeholders, who had to request status updates directly from the engineers.
03
CHAPTER
Design process
Based on insights from the Discovery phase I started to ideate and create solutions. This section will provide a part of the deliverables used to communicate some of those ideas, such as Information Arhitecture and Mock-ups. Please note that deliverables went through a series of iterations, each time being improved with feedback from stakeholders.
Core Design Strategy
Design Principles
Our design strategy for the Configuration Provider Tool centered on solving integration inefficiencies while preserving the technical robustness of the underlying system. We established five guiding principles to inform our design decisions:
01. Progressive Disclosure
Present information in a logical hierarchy, revealing complexity only when necessary. This approach allowed us to maintain the depth required by engineers while preventing cognitive overload.
02. Consistency with Intent
Maintain consistency with the existing back-office interface where beneficial, but prioritize intention-revealing design where the current system fell short. This balanced user familiarity with improved usability.
03. Error Prevention over Error Recovery
Design interactions to prevent errors rather than relying on detection and correction. This principle directly addressed the error-prone nature of command-line configuration.
04. Visibility of System Status
Provide clear feedback about configuration state and validation status at each level of the hierarchy. This enhanced confidence in the system and reduced verification steps.
05. Efficiency for Repetitive Tasks
Identify and optimize common workflows to reduce time spent on repetitive configuration tasks. This principle supported our 50% time reduction target.
Information Architecture Development
Mapping the mental models
We conducted a thorough content inventory of all configuration data handled by the system, organizing it into a coherent structure that reflected both the technical requirements and user mental models. The resulting architecture consisted of three primary sections:
Operator Management
This section contained all operator-level configurations and served as the gateway to brand management. We organized operators into a sortable, filterable list with clear status indicators and quick-access actions.
Games Management
We structured game configurations to allow both system-level defaults and operator/brand overrides. This is the place for initial/default game setup including game status management.
Currency Management
Similar to game configuration, we designed the currency section to support hierarchical configuration management.
Information Architecture of V1 of Configuration Provider tool
The Information Architecture map above is built around three main pillars that form the foundation of the entire tool. These elements are marked with a (+) plus sign and are briefly described when hovered over with the mouse.
Mockups
An overview of the Solution
Below is a series of mock-ups intended to serve as artifacts for discussions with users to validate the design. These are not the final versions but rather a selection of screens showcasing work in progress, highlighting key considerations I have incorporated to enhance the user experience. Some of these mock-ups were also used in conversations with developers to ensure feasibility and alignment. You may notice inconsistencies between screens, such as variations in button placement (e.g., shifting from the left to the right side in EDIT mode), which were part of the iterative design process.
Main Page – List of all Rubyplay Clients (Operators)
Streamlined Configuration Interface for Operators and Brands
The heart of the Configuration Provider Tool is a streamlined interface that transforms complex configuration tasks into intuitive operations:
Guided Setup Wizards
We implemented step-by-step wizards for creating new operators and brands, replacing the previous command-line process with a guided experience that ensures all necessary configurations are completed in the proper sequence.
Contextual Actions
The interface presents only relevant actions based on the current context and user role, reducing cognitive load and preventing errors caused by inappropriate operations.
Enhanced Search and Filtering
We integrated powerful search and filtering capabilities across all configuration lists, enabling integration engineers to quickly locate specific operators, brands, games, or currencies during complex configuration tasks.
Status-at-a-Glance
The interface prominently displays key status information using color-coding and iconography, allowing users to quickly assess the state of operators and brands without diving into detailed configurations.
New operator – Progressive disclosure – Currencies
Add brand – Game configurations
Operatos page – Brands tab view
Hierarchical Configuration Management
A critical aspect of the solution was effectively managing configurations across system, operator, and brand levels:
Override Controls
The interface provides intuitive controls for overriding inherited settings at each level, with visual confirmation of changes and the ability to revert to inherited values when needed.
Default Template Management
We implemented a system for managing configuration templates that can be applied to new operators and brands, dramatically reducing the time required for standard configurations.
Operatos page – Brands tab view
Games – Edit individual default configurations
Batch Operations for Currency and Game Configuration
To address the time-consuming nature of individual configurations, we implemented comprehensive batch operations:
Multi-select Controls
The interface enables selection of multiple games or currencies for batch operations, with intuitive controls for selecting all, none, or various subsets based on parameters like game type or currency region.
Bulk Enable/Disable
Engineers can enable or disable multiple games or currencies in a single operation, with appropriate confirmation dialogs to prevent accidental changes.
Bulk Edit with Exceptions
For more complex scenarios, the interface supports bulk editing with the ability to specify exceptions, providing both efficiency and precision.
Manage brand – Bulk selection
Confirmation dialog when existing the Edit mode
MARCH, 2025
Update
This case study is still a work in progress and has not yet been finalized. However, I would like to share it with you to provide insight into my approach, thought process, and shart a part of the design. I appreciate your understanding and apologize for any inconvenience.
Kind regards,
Cristi