Sarai Sánchez

UX & System designer

Hello there! 👋🏻My name is Sarai, and I'm a product and system designer with 9 years of experience.

Experience

I'm really lucky to have experienced a broad-spectrum professional journey. I've been involved in projects within the three main categories of software design: client/ contract, product and in-house development.I moved from working with big clients in a corporate environment to being embedded in a cross-functional product team in a SaaS start up. I later joined the exciting world of mobile gaming to participate in the redesign of a huge platform to centralize internal game operation tools. Most recently, I joined a non-profit organization, where I started pursuing my favorite design specialization: system design.

November 2019 - Present, Berlin

I originaly joined Wikimedia Deutschland to drive the creation of a design system for Wikipedia's nerdy sister project, Wikidata.After a year of existence, this initial library – WiKit – is in the process of being deprecated in favor of the creation of a new unified system for all Wikimedia projects: Codex.
I played a key role in planning and executing the alignment efforts needed to set the foundations of this new library. Since its creation, I've been supporting the Design systems team at the Wikimedia Foundation as a UX designer for Codex.
My main tasks as a system designer consist on creating the full visual and interactive specifications of new components (considering UX standards, accessibility, and internationalization), defining our design tokens' architecture and visual guidelines. All while supporting our adoption strategy, establishing our governance model and aligning with our users and stakeholders to understand their needs.In parallel to my role as a system designer, I'm currently the UX designer at the Wikidata team. There, I'm supporting the implementation of several projects, such as the creation of a new search solution for Wikidata or the complete redesign of core Item pages.


November 2018 - October 2019, Barcelona

In November 2018, I was offered the opportunity to join the gaming company King. I simply couldn't turn down their invitation to collaborate on quite a challenging project: the development of a huge platform that will centralize all of King's internal game operations tools.As a designer in the Game Operations team, I lead the conceptualization and accompanied the development of two main tools to support King's game teams: the Game Operaitions Manager (or GOM) and the Stereotype Manager.Both tools were designed with and for data scientists and marketing specialists, and aimed at making in-game campaigns more easily manageable.


June 2016 - November 2018, Barcelona

I left Everis' corporate environment to join Typeform's small Product Design team as an intern in June 2016. I quickly felt comfortable and thrilled to belong to such a talented start-up family.Being embedded in a cross-functional development team taught me important lessons on how to be a lean UX designer: I enjoy sharing and iterating quickly, as well as making collaborative design decisions together with members of the product and engineering crafts.Some of the most relevant projects I took part in or lead as a designer were the release of the v2 version of Typeform, and the conceptualization and launch of Typeform Connect 🎉


December 2015 - June 2016, Barcelona

I joined the Experience Design team at Everis as a UX research intern in 2015, while I was still studying a Master’s degree on Digital Content Management at the University of Barcelona.Throughout my career at Everis, I was involved in the discovery and conceptualization phases of all sort of design projects. I planned and conducted user research to inform the redesign of the digital experience of the customers and employees of big companies such as CaixaBank, Banc Sabadell or Allianz, or institutions such as the European Commission.

Education

2014-2016
Master's Degree in Digital Content Management
University of Barcelona

2009-2012
Bachelor's Degree in Literary Theory and Comparative Literature
University of Barcelona

2004-2009
Bachelor's Degree in Translation and Interpreting
Autonomous University of Barcelona

Portfolio

⚠️ This section is work in progress. Case studies are being actively added ⚠️


Creating WiKit, Wikidata/Wikibase's design system

Where: Wikimedia Deutschland (WMDE)When: Nov 2019 - Oct 2021

I joined Wikimedia Deutschland (WMDE) to drive the creation of a design system for Wikidata. Wikidata is a multilingual, machine and human-readable knowledge graph project that is part of the Wikimedia Foundation product suite.

Diagram of the Wikit's design system's workflows

Background

Wikidata and the Wikibase products are built with quite a complex and outdated front end technology.Almost every engineering project at Wikimedia Germany is hindered by the technical and design debt accumulated throughout the years. In lack of reusable components and utilities, or clear standards, the teams experienced constant duplication of effort and slower development cycles.The main goals envisioned for the system were to optimize the design and implementation of new features for Wikidata and Wikibase, using new ready-made Vue components; as well as allowing our team to provide a renewed and consistent UI, aligned with the Wikimedia design standards, which would improve the experience of Wikidata's editors and readers.The solution was fully supported by developers, who identified the adoption of Vue.js as the new Front end framework for Wikimedia as the perfect opportunity to explore the creation of a modular library of shared components that will replace and improve the current front end of the Wikidata and Wikibase applications.WiKit (Wikidata/Wikibase's design system) was the result of over a year of close collaboration between the UX team and the engineers of the Software development department at Wikimedia Deutschland.Now deprecated, the WiKit library served as a strong prototypical foundation for Codex, the now official design system for all Wikimedia projects.

Check out WiKit on 🤖 GitHub – 📖 Storybook – 🎨 Figma

The process

1. Discovery: Understanding the context & motivation

As a system designer, my priority early in the project, was to familiarize myself with the core motivations of the design system initiative: What are the problems that designers and developers experience when tackling the creation of new user-facing features? How do the teams organize their work at the moment? What are the technologies used? What levels of standaridization are already there? Were there any previous initiatives systematize UI design/development?
Understanding the context and the needs of the system’s users (with their own help) was essential to assess the dimensions of the challenge, understand its perceived value and start tailoring the most convenient solution.

Problem statement

Data collected from the Wikidata and Wikibase team members (engineers, designers, and product managers) through stakeholder interviews allowed detecting the following problems:❌ Existence of multiple sources of truth for design (OOUI, Style guide, production) complicate design decision-making❌ Faulty communication and handover processes between developers and designers: uncertainty complicates the creation of exhaustive specs, which impacts on design and development efforts.❌ Low reusability and scalability of UI components across domains and products❌ Visual inconsistencies between Wikibase products (accumulated UX debt) and between Wikidata and Wikipedia (lack of ecosystem consistency)

Vision

The Wikidata/Wikibase team expected that the system would allow us to optimize design and engineering processes and achieve overall consistency in the Wikidata/Wikibase platforms by replacing the current Front End with modular, reusable Vue components that are based on a single visual source of truth (common to all Wiki projects).The expectation was that a design system will help our team...✔ Consolidate conflicting resources into a single source of truth for design✔ Base component implementation in a set of predefined, centralized and traceable design decisions✔ Improve communication between design and development for a clear and effective handover processes✔ Ensure the reusability of UI components across feature teams✔ Provide a more consistent, better user experience

2. Setting the foundations: Defining the system’s workflows and design principles

The discovery phase revealed some key unknowns, such as the unclarity regarding the scope of the project, and the uncertainty around the way in which the WD/WB team were going to organize design system work to execute the system’s vision. Already during that early phase, we jumped to discuss solutions that were later documented and discuss as the foundations of the service were set.

Diagram of the Wikit's design system's workflows

Contribution model: How might we tackle system work in our department?

During the discovery phase, developers from the Wikidata/Wikibase team were invited to participate in ideation sessions where the infrastructure and the processes involved in the creation, maintenance and distribution of shared system components were discussed.One of the recurrent conversations held was related to the way in which we prefferred to organize and tackle the creation of a design system: should we designate a core team (which would centralize decision-making and the creation of components), or support a decentralized model (in which all developers are owners and contributors of the system)?Those discussions culminated in:1. The decision to the creation of the system following a distributed approach: In this preferred model, instead of relying on a core team to centralize design system work, developers and designers embedded in feature teams follow system guidelines and standards to work as direct system contributors.In this organizational approach, team members are at the same time the creators and consumers of the system.Components are built on demand: they prioritized, designed and implemented depending on feature teams’ needs, and ultimately on Wikidata/Wikibase’s planning.

2. The creation of an initial “Workflows and rules” model for the system, outlining all the steps and environments involved in the creation of new components that we could envision at that point in time:

Diagram of the Wikit's design system's workflows

Consolidating and documenting the visual foundations of the system

Discussions on the early stages of the project made it clear that our UX team needed to be the driver of change: If we wanted to create truly consistent and reusable components, we had to start designing with a system mentality, solidify our design source of truth and find a solution that allowed us to propagate centralized design decisions (i.e., ✨ design tokens ✨).

With that in mind, the following activities were carried on, in order to establish a design foundation for our system:1. Perform an inventory of Wikidata's UI components, to document the elements that make up our ecosystem and their different instances.
2. Variables consolidation: collecting and comparing the styling values applied to components in different sources.
3. Start documenting and transforming into Figma styles, the Wikimedia Foundation’s Style Guide Visual guidelines & principles
4. An initial set of components are made available UI components Kit (Figma library)
5. Define the approach to design tokens: Can design tokens help us document that consolidated source of truth? What would be the best format to store them? How should our token architecture look like?

Diagram of the Wikit's design system's workflows

Scope: Does creating a design system equals a redesign?

We went through the original discovery phase without actually defining a clear scope for the system project: What are we creating components for? In case we wanted to migrate Wikidata and replace the project’s front-end, a redesign project (paired with the design system initiative) was required. Is the system necessarily paired with a redesign?Here's what we decided:We'd focus on the creation of system components to enable the reusability of code and optimize the implementation of new features, and then use those ready-made, consistent atoms to design and implement future UX improvements in Wikidata. New Wikidata features will be the consumers and the source of system components.

3. Materialization

Once there was clarity regarding our scope (components will be created in the context of new features), our implementation model (distributed/decentralized) and we had defined a set of foundational design guidelines that we wanted to try to propagate using design tokens, we could start materializing our product.

First prototype

Between June and August of 2020, the design system project received the support of three dedicated developers, and a feature team was formed to set the first stones of the Wikidata/Wikibase Design System (aka WiKit).The goal of this trailblazing team was to put in place and evaluate our predefined workflows, set up the system’s technical infrastructure and create a couple of first components that will be styled applying our approach to design tokens (our design source of truth). All while thoroughly documenting everything.With infrastructure, tools and documentation in place, the system comes alive. The main resources of the system's ecosystem are created:

Design components Library (Access in Figma)The WiKit components library contains foundational styles, a kit of reusable UI components (symbol variants), specifications (using tokens as a language for handover) and documentation.

Diagram of the Wikit's design system's workflows

Code repository (Access on GitHub)Where the components’ code, tokens and solutions, like testing tools (e.g. SauceLabs, and Chromatic – for visual regression testing) are hosted and enabled.

Diagram of the Wikit's design system's workflows

Storybook (Access the library)Contains all the system’s guidelines and processes documentation (including our component design process and contribution guidelines), a structured visualization of the design tokens used to specify and style components (our centralized design source of truth), and demos of the components themselves.

Diagram of the Wikit's design system's workflows

4. Adoption

With its infrastructure in place, and all its processes and guidelines documented and shared with the department, the system is ready to start incorporating and distributing the components needed by our feature teams. As mentioned before, those development teams working in new Wikidata applications and tools will be, at the same time, the creators and consumers of WiKit components.

Onboarding

Since the system was owned by all the members of the Wikidata/ Wikibase team, and all engineers were eligible as contributors to the system (depending on their involvement within feature teams). A set of technical onboarding sessions were conducted to get everyone familiar with the system’s infrastructure and standards.As the system designer, I conduct design-oriented onboarding sessions to the system, to make sure that the component design and specification processes are fully understood and accommodated to designers’ needs.

First system-built tool: Wikidata Query Builder

A "hike" team is formed to implement a new tool built with Vue.js: the Wikidata Query Builder. The product is set to provide users with an interface that allows them to query Wikidata in a simple way.The team leading the implementation of this product was the first to consume and contribute components to the system. They were in charge of implementing a first set of UI elements to be reused by their own new application. This was the first real-life run of our decentralized contribution model.

Diagram of the Wikit's design system's workflows

As a system designer, my role now consists on aligning with the designer assigned to the feature team in order to understand which components are needed, and what’s their nature (core or project-specific). It is my responsibility to (co-)design, symbolize, document and fully specify components using design tokens, and to provide support and validation during their implementation phase.I’m very lucky to count with the support of a dedicated system developer (with limited availability) that helps with the technical validation of design specifications, and provides advice to the feature team’s developers on the implementation approach and scope, all while gatekeeping the system's standards.

Second system-built tool: Wikidata Mismatch Finder

Diagram of the Wikit's design system's workflows

Given the success of the first WiKit-based project, a second feature team starts benefiting from the central component library and is set to contribute new elements to it in order to create a new data quality tool for Wikidata, the Mismatch Finder.

5. Deprecation

Already at the early stages of our design system project (back in March 2020), our team at WMDE discovered that the Wikimedia Foundation had also identified the need to create a library of Vue components, and that a team was planning to work on developing their own system.Our first inkling then was to try to figure out the way to combine efforts in the creation of a library of components shared across organizations. This was, of course, in order to avoid duplication and for preemptive deprecation.A formal collaboration proposal was drafted, but discarded in favor of deciding that the Wikimedia Deutschland and Wikimedia Foundation teams would work on independent prototypes.The teams agree to hold knowledge sharing sessions, and to ultimately set the foundations for a future, common design system, based on our combined learnings.

Converging development, aligning design

After developing our individual design system prototypes for over a year, key conversations and proposals finally started redirecting our front end strategy towards the creation of a unified design system.Through a series of workshops and exchange sessions during the spring and summer of 2021, designers and engineers from both organizations finally joined forces to define the foundations of our new, shared design system.A core Design Systems Team was formed in the Wikimedia Foundation to centralize the effort of implementing a design system for all Wikimedia projects.

Design Workshop: Leading the creation of a design-first design system

In collaboration with a Lead UX engineer, I planned and facilitated collaborative design sessions with the design teams in both our organizations.The goal of the sessions was to collect feedback regarding the new system’s governance model, the system’s environments and ecosystem, the component design process. We also addressed the strategy, and areas of concern that would benefit from design input, such as design tokens, iconography or typography.

Diagram of the Wikit's design system's workflows

You can access the workshop planning document, and the FigJam board used to facilitate the session.

Task Force & Decisions week: Technical building blocks of the Codex Design system

A mixed Task force of developers and designers (including myself) dedicated a week to work together on forging further technical decisions and implementing the building blocks of the Wikimedia design system: the repository, demo site and first components were created.The new, centralized design system for all Wikimedia projects was born and given the name Codex.Designers used pairing time during this phase to design a design tokens architecture that suited the complex needs and context of the new unified solution. WiKit served strongly as an inspiration.

The endless pursuit of consistency

With WiKit approaching its deprecation, it was decided that my system design experience and the domain knowledge I accumulated would be specially useful if applied to the new, unified design system.I joined the new, core Design system team at Wikimedia Foundation in November 2021, and dedicated my full-time effort to plan and executing the early design stages of the new design system for all Wikimedia projects.Still today, in my role as UX designer in the Wikidata team, I'm an active collaborator of the Codex design system team. My latest additions to the system have been a proposal to embed responsiveness in system components, and the full specification and guidelines of Codex's Table.

Diagram of the Wikit's design system's workflows

At the end of 2023, I also started planning and leading the migration (T327532) of the tools built using the now deprecated system to Codex.