Hi everyone! We're the UI team for Rakuten Gora, the golf course search and reservation service. Today we want to share our experience building GRX (Gora ReX, from Rakuten Experience) — a design system we built from the ground up. It's been a journey of learning, challenges, and growth.
What is a design system
First, to make sure we're all on the same page, let's talk about what a design system actually is. A design system is a set of standards, components, and rules that define how all company interfaces look and work. Imagine this: instead of deciding every time what a button, form, or table, and their margins should look like, you have a ready-made "LEGO constructor" with clear instructions on how to build with it.
It includes:
• Design tokens: a set of basic properties (colors, fonts, spacing, and so on) that are the same across all products
• UI components: buttons, forms, tables, modal windows — everything ready and reusable
• Patterns and rules: how components work together, when to use which one
• Documentation: so any new person can understand how it works
Why it matters and is useful
Development speed
When components are ready and tested, a developer doesn't write code from scratch. They take a ready block and add it. This is especially important when you need to quickly launch an MVP or test an idea. It makes product development more mature and complete.
Consistency = recognition
A user who has learned one of your products will understand how to work with another one. This improves UX, lowers the entry barrier, reduces support questions, and strengthens brand perception.
Scalability
A new project? We don't start from scratch. We already have a set of approaches and patterns to begin with. A new developer or designer on the team? They don't need to learn the style of each project. There's one common system for everyone.
Less technical debt
Instead of many versions of one component scattered across projects, we have one component in one place. Need to update the design? Change it in one place, and the changes spread everywhere.
Quality
Components are tested once centrally, not separately in each project. Fewer bugs, less inconsistency, which means faster and better product development.
Our journey: how and why we created GRX
Now that we've discussed the main concepts and benefits, we can talk about our experience. The decision to create our own design system didn't happen in one day. It was a combination of factors: team tiredness from mixed-style projects, a need for system and mature processes. Design systems have long been an industry standard in the West, and we're not a startup. It was time to work like a mature company, with common standards and reusable solutions.
Approach: serious from the start
From day one, we weren't building a prototype, but a product. We planned a full set of components: from simple buttons and input fields to more complex elements like calendars and data tables.
GRX is built on Vue 3 + TypeScript. From the very beginning, we set up complete infrastructure: documentation in Storybook, unit tests on Vitest, and visual regression testing.
Why such a serious approach? Because a design system won't work if it's just a set of 3-4 components. If at least the basic elements aren't covered, you can't build interfaces, and products will stay mixed-style — there will be no effect.
Pic: Example of component page in Storybook. It's a single source of truth where developers and designers can check all props and see examples of how components work.
Development reality
Initially, only one developer worked on GRX, which is why the first beta version with basic components appeared after 6 months, and a more complete system with modals, calendars, and comboboxes appeared after a year.
After the first version and proof of concept, we decided to speed up the process and first tried rotations. The idea was simple: each team member helps for a month or two, taking at least one task, like in an internal open-source project.
But it didn't work as well as we hoped. Different levels of experience, workload from main projects, the need to dive into what was basically a new product... all this got in the way. In the end, we decided to assign a second person permanently, and then things moved faster.
And ideally, a design system should have a separate product team with its own processes. This gives more stability, protects from the influence of other projects, and in general, it's standard practice in the industry. We hope to get there one day.
Building design processes
Design systems are not created only by developers — designers play an equally important role. And here we had our first difficulties.
Over the year, three designers changed on the team. Not all of them had experience with design systems, so understanding the principles developed gradually. The biggest challenge? Changing the mindset. Before, a designer could create any component for a specific task. Now they need to think systematically: use existing solutions or explain why a new one is needed.
A separate challenge was the Figma interface. It allows changing component tokens like regular properties even where it breaks the system logic. For a designer not used to design systems, it's tempting to "adjust it a bit" — because it changes as easily as a component prop. But each such change breaks consistency, and in code these deviations don't work so simply. Because of this, we had to go back to mockups and redo them.
In this sense, the main GRX developer with 7 years of experience in design and working with design systems was a big help. He became a bridge between two worlds: explaining technical limitations to designers, and explaining design decisions to developers. This helped build basic processes and establish understanding.
By the way, to strengthen these processes and prevent similar mistakes in the future, we planned an internal training course. It will be useful not only for designers, but for all teams that don't use design systems yet (particularly GRX) but want to start. The goal is to simplify adaptation to the systematic approach and make implementation in new projects smoother. If you're also interested in such training, write to us.
Pic: Example of component page in Figma. Designers document all restrictions and guidelines, as well as assemble all component variants. This documentation is prepared by designers.
The main cultural shift: GRX is a product, not a tool
The most unexpected challenge turned out to be not technical, but mental.
At first, the team saw GRX as a regular tool, something that can be adjusted to your needs in each specific project. "Let's change the corners a bit here," "can we make this component a bit different for our case?"
But a design system is a product. It has its own users (designers and developers), its own logic, its own limitations and rules. And you can't "bend it to fit" without breaking its integrity.
This is a fundamental change in thinking:
- A tool adapts to the task
- A product sets the rules for use
If each team starts modifying components for their needs, we'll return to the same chaos we were leaving. The system only works when everyone plays by the same rules.
This wasn't easy to accept. But once we started treating GRX as a product (with its own documentation, roadmap, feature request process, and bug handling), everything started falling into place. Of course, this hasn't worked everywhere yet, but it's a normal adaptation process that also needs time.
Developer feedback
Some wins were felt immediately:
Using GRX in the project helps us to standardize the design across the application
Consistency stopped being a matter of negotiation, it became built into the process.
It helped me a lot during EOL project and it saved a lot of time by using its components
Time savings became noticeable in the first projects. Instead of creating components from scratch, the team focuses on business logic.
But of course, there were challenges:
Due to early phase implementation, some GRX components have bugs and we need to fix it during the development or QA phase"
A reality you need to be ready for in the early stages. Some complex components (Combobox, Calendar, Datepicker) were created in parallel with projects, in tight deadlines. This led to bugs or missing features that had to be fixed on the go. Not ideal, but it's the price of a fast start.
Sometimes Designer and Engineering team has different perspective how to use the component
One of the most important insights in working on a design system. Different roles look at components differently, and that's normal. The solution? More communication in early stages, involving all roles (including product managers) in discussing complex components.
Maturity comes with experience:
Given it is the first time we use GRX in a project, these troubles are understandable and it gives us the experience to make GRX more stable and mature.
The team understands: this is an investment. The first projects are harder, but the next ones will be much faster.
One of the GRX developers noted the importance of structured feedback from designers, which is what helps the system develop correctly. Also, the need to expand testing became clear: unit tests and VRT turned out to be not enough, we need integration and e2e tests to catch bugs before production. This will also come with time.
Pic: Example of component page in Vitepress Documentation. It contains everything developers may need: props, slots, events, usage examples with code snippets, and more.
Limitations are a feature, not a bug
One of the main feedback points is that there's less flexibility now, which makes work harder. And it's true. Now you can't just take and create a new version of a component "as you want." You need to use existing ones or explain why a new one is needed.
But that's the point. Limitations work for the business:
• Less time spent on arguing about details
• More focus on solving real user problems
• Each solution scales to all products
• New projects start faster because the foundation is ready
Yes, it's harder at first. But it's always like this when you learn to work with new tools. The first attempts are the hardest, but then speed grows many times.
Where we are now and what's next
After almost a year and a half, we have 50 components, each with documentation and tests. From simple buttons to complex data tables and calendars. This is no longer an experiment, but a complete product. We've already released three projects using GRX: RBS Lesson, OB Line (Intra), and Green Trimming Tool (Intra).
To give you a better idea of what GRX looks like in action, the picture below shows an RBS Lesson page, where we've fully implemented both tokens and components. On this page, we use GRX tokens for typography (title, subtitle, and content) and multiple GRX components such as GrxButton, GrxCalendar, GrxSidebar, and GrxTable.
Pic: An RBS Lesson page built with GRX.
And this is just the beginning — we're planning to expand to many more projects soon. Here are our nearest plans:
Patterns
Components are good, but we're going further. The next step is creating patterns: ready solutions for typical scenarios (login forms, tables with filters, dashboards). So teams can build interfaces even faster.
Scaling to Other Projects and Teams
We're ready to help adapt GRX to other teams within the department and even the company. And not just give access to the library, but help with implementation: train the team, set up processes, help with theming.
Theming
Right now GRX only allows changing theme tokens, but we understand that if we want to scale, other teams and products need more flexibility in changing some things for themselves. So we plan to make more global component configuration at the project level, similar to what Tailwind has.
Mobile devices
We're thinking about adapting GRX for mobile applications, so the user experience is consistent across all platforms.
Other frameworks support
Right now GRX is built on Vue, but we know different teams work with different technologies. The main thing for us isn't which framework we use, it's keeping design consistent and having a single source of truth.
We see two possible paths. We could help teams adapt GRX for their frameworks like React or Svelte, working together to build those versions. This ensures quality and consistency, but needs ongoing collaboration and long-term commitment from our side. Ideally, this is where having a dedicated GRX team would really help. Or we could go framework-agnostic: provide design tokens and guidelines, then let teams adapt independently. More flexibility, but higher risk of inconsistency and teams would need to solve the same problems over and over again on their own. Right now we're leaning towards the first approach, but it's an open discussion.
Want to share experience?
We continue developing GRX and would be happy to exchange experience with teams solving similar problems.
We're ready to:
- Show how GRX works
- Discuss approaches to implementing design systems
- Share lessons and challenges we've faced
Design systems are not just a component library. It's a culture of systematic work that makes development faster and products better.
As of December 12, 2025.
Come work with us!
Commerce & Marketing Company Leisure Product Department (LPD) is seeking talented individuals to join our team in developing new services, managing daily operations, and driving continuous improvements. Recruitment is open for a variety of positions, including engineers and product managers. We look forward to receiving your application!
