UX/UI
Design Systems
Digital Publishing
UX/UI design of article tile & group components for a digital publisher
A crucial element of the publisher's design system, the article tile component ended up being incredibly versatile, with 110 different variants. The article group component was a bit more straightforward, comprising 32 variants to suit common grouping patterns.
Client
GAMURS Group
Timeline
Several months over 2022–2023
Team
Creative Director
2x UX/UI Designers
3x Developers
What I did
I played a key role in the design of these components—conducting a feature audit, exploring structural and functional needs, and delivering a robust, adaptable system for multiple sites and use cases.
Context
Embarking on a quest to unite 17 disparate sites into one cohesive network.
GAMURS Group is a digital publisher that produces written, video, and social content for 46M monthly readers across its network of 17 gaming, esports, and entertainment websites. Each site had its own codebase and component library making it difficult to manage the network at scale.
To address this, a design system initiative was launched in late-2022 to unify the network. It had three key objectives: streamline processes, ensure design and experience consistency across sites, and enable scalability of the network.
Five examples of how the original sites felt too disparate.
Project Summary
As part of this quest, I played a key role in developing flexible article tile and group components alongside 2 designers and 3 developers.
This took place over several months and three main phases.
1-Product Audit
• Audited site features, breaking each down to its core information and component parts.
• Reviewed how and where article groups were used across 7 sites in the network.
2-Experience Design
• Explored flexibility and functionality needs for article tiles and groups.
• Explored how article tiles would form article groups, and how groups would form page templates.
3-UI Design
• Designed the article tile and group components, which had variants based on breakpoint, background, colour, image position and ratio, and use case.
Product Audit
To kick things off, a network-wide audit was completed to capture each individual feature.
We needed to have a concise overview of what common features existed across the network, which sites they appeared on, how they were displayed, and what interactions or behaviours they had. We also needed to know what information they contained.
As part of this audit, I broke each feature down into its individual elements. This helped us determine what elements were shared across sites, or were unique to certain sites, and what components we would need to design.
Article Tile breakdown highlighting which elements to keep and delete, as well as design considerations.
I also reviewed 7 of the sites in the network to get a rough idea of how and where article groups were typically used.
As these were amongst the most prominent features, it was important to understand the types of article groups used and where they appeared on each site (e.g., in the sidebar, in the main container, above the fold, etc.).
This review showed that a limited set of article groups were used, but with differing layouts and positions, which would need to be accounted for.
Experience Design
It became clear that article tiles & groups would require the most flexibility, so I began to explore how these features might work alone and together.
Not only did the tiles need to be flexible enough to show different amounts and kinds of information, they also needed to be grouped in different ways to suit multiple use cases. Plus, they had to function across different breakpoints.
To start with, I did a high-level exploration of how article tiles could become article groups, and how article groups would then form page templates.
My initial thinking was that there’d be a mix of tiles based on visual style, orientation, and size. These would then be mixed and matched to form a variety of article group styles and uses, which would then form non-article-based page templates.
With this flexibility in mind, I began exploring the design of article tiles.
I focused on composition and experimented with different orientations, sizes, and amounts of visible information.
Some of the initial wireframes I did for the article tile.
Translating some of these wireframes into rough UI designs in Figma.
UI Design
Once I had the UI designs, I realised that while my general approach worked, there was room for improvement and changes.
For example, I had assumed that the tiles could be compatible across breakpoints, but that wasn’t the case. We needed to account for different type sizes, spacing, and layouts.
The option of a full-bleed image on the tile also wouldn’t work. How the tile looked would be highly dependent on the image used, and that was out of our control as the editorial teams chose the images.
Visual example of why a full-bleed image tile wouldn't work because it would be highly dependent on the image used.
Once these changes were made, we were able to “finalise” the design of the article tile and group components.
Some of the "final" article tile and group variants.
But I soon learned that nothing is ever truly “final” or “done”.
For example, as more stakeholders were informed of the design system initiative, requests from editorial teams started to come in. One request was to be able to show multiple authors, both on article pages and on article tiles.
This necessitated the need for an article metadata component, which I designed, and which would display slightly different information depending on its location (i.e., the article page head or article tiles) and how many authors contributed to the article. This was then nested inside the article tile component.
An article metadata component was created to show when an article had multiple authors (a stakeholder request); plus, examples of how this component displays in the article tile.
Testing the tiles in page templates also revealed issues with type sizes.
Mainly, that having one type size for the tile's title and subtitle, per breakpoint, was kind of boring and actually didn't work that well.
We wanted to have more flexibility with the typography in order to create hierarchy and visual variety. But it was also important to have different type sizes that could work with the different sizes of tiles.
For example, a two-column mobile tile looked unbalanced with a 26px title size (left), while a desktop featured group, where all tiles have the same title size, lacked visual hierarchy (right).
To address this, we introduced 3 different type sizes per breakpoint.
These were turned into their own component and nested inside the article tile component.
The title and subtitle component; plus, an example of how a desktop featured group might look using this component (where the middle tile uses a large title/subtitle, and the outer tiles use a small title/subtitle).
Outcomes
In the end, the article tile component consisted of a whopping 110 variants.
Its variants were based on breakpoint, background, colour, and image position and ratio. The component also had several boolean properties, so elements could be hidden as needed, as well as the previously mentioned nested components.
Showcasing how one article tile could be displayed in multiple ways; plus, the different properties and in-built customisations available in the article tile component.
By comparison, the article group component had a more manageable 32 variants.
Its variants were based on breakpoint and use case. There were 16 different types of groups based on style and location on the sites (e.g., well groups, list groups, row groups, etc.). And, like the article tiles, it had nested components and boolean properties for flexibility.
One thing we chose not to do was to surface the nested tile component properties in the group component. We felt this would add to the component's bloat and make it confusing to use. So, if there were customisations needed to individual tiles, we'd have to manually select them within the group to make the necessary changes.
Showcasing a selection of populated article groups; plus, the different properties and in-built customisations available in the group component.
Lessons
Designing the library wasn’t all smooth sailing, but it gave me valuable insights into effective workflow practices.
Lesson 1: It's beneficial to establish processes, guidelines, and checklists in a multi-contributor environment, and ensure they're easily accessible.
In this project, three different people were designing components in Figma, each with their own approach and skill level. This led to inconsistencies in component structure and behaviour.
To address this, we put together a checklist we could each refer to when designing new components. And while this was good in theory, it didn’t work that well in practice. Mostly because the checklist was in Confluence and we were working in Figma — we had to remember to refer back to it, which we didn’t always do. A better solution might have been to have the checklist in Figma itself, so it was within easier reach.
Lesson 2: It's important to involve developers from the start, and to test new designs as you go.
Another misstep was the fact that, initially, the design team proceeded without developer input and without iterative testing. We simply crossed our fingers that components would translate to code as intended. And while most did (luckily!), some components needed late-stage adjustments. A better approach would have been to involve the developers from the start and test components as they were designed.
Lesson 3: Exploring and assessing practicality and feasibility early in the design process will save you a lot of time and headaches.
Finally, we wasted a lot of time trying to create interactive components that would work with design tokens, which ended up being a lot more fiddly than we first thought. We wanted interactive components for future prototyping needs, but we didn’t assess whether they were actually needed. In the end, we decided they weren’t needed yet. If, later, we needed interactions for prototyping, we would address it then.
Time Machine
Looking back on what I achieved with the component library, if I had a do-over, I’d approach it much differently.
This was my first experience designing a component library from scratch, and while it was a great opportunity to learn and develop new skills, I found myself wanting to learn more. Since working on this library, I participated in a design system bootcamp, which opened my eyes to better, more effective ways to design components.
1-I'd design smaller components rather than large, complex ones.
For this design system, we tended to have large, complex components with all possible variants (e.g., the article tile component). If I was designing the library again, my focus would be on breaking up the large components into smaller and simpler ones, even if that meant having more components overall.
2-I wouldn't design all components to be as flexible as possible.
We also designed components with flexibility in mind. We wanted to be able to make as many customisations as necessary when using the components, but that can sometimes lead to decision fatigue. In my do-over, I’d balance flexibility with rigidity. Not every component needs to be flexible. Some components can have limitations in what can be customised.
Key Takeaway