Style normalisation and System design in Ticketbis

Luis Armesilla
May 10, 2016 · 8 min read
Image for post
Image for post

Keeping a straight design and, therefore, a consistent user experience throughout an online marketplace of a company as big as Ticketbis can be quite overwhelming. In this article we’ll analyse the possible improvement areas and the methodology that we’ll follow to achieve this goal.

Using a modular design, system design or “atomic” design (different names for something that, in essence, is the same concept) can be quite useful, both when in need of its replication and transmission throughout the different product teams.

Current UI

The ever growing product, the isolation of the development teams or the lack of a clear design path, can be the reason why along the marketplace we can find many cases of visual incoherence, inconsistencies inside processes and similar interactions or lack of visual hierarchies.

Despite these problems being related, we attempted to categorise them by element type so that the user experience design can be faced in a more or less orderly way:

  • Typeface styles: Too many font styles, sizes and weights and, at times, even different typefaces, other that our corporate Open Sans, live together in the same page. This makes hierarchy to be perceived with much more difficulty, making its reading harder.
  • Buttons: The call-to-action elements (mainly buttons) do not follow a hierarchy, nor they follow a clear logic of position, colour, shape or message.

Colour: The use of colour seems rather arbitrary and seldom used with informative purpose. The perceived significance of colours is not considered, such as the case of red or magenta, normally associated to errors or warning states. This particular case is specially problematic since any error message that the system delivers can be hard to spot or may be even neutralised by the rest of the elements.

  • Shape: There is no clear logic when creating new elements or unify existing ones. In some cases the affordance is non-existing.

According to Don Norman, Affordance is the set of possible interactions immediately perceived by the user, in other words, it’s the intrinsic characteristic of an object to make a user understand the way it’s supposed to be used. For instance, a glove or a watering can, due to their shapes, can easily indicate a user its purpose and how they’re supposed to be used. The affordance in an interface will help us, as users, anticipate its actions, which not only makes using them easier, but also can help reduce uncertainty.

  • Iconography: There isn’t a defined system, hierarchy or visual consistency in the used icons throughout the site, in either shape or use
  • Photographic style: Since there is no defined style in the use of images, there’s no coherence in the type of images used in the entire site (and service). In many occasions there’s no specific purpose behind its usage. For instance, if the site is showing an event, do we want to show a general, colder view or do we intend to get as close to the action as possible, looking for closer shots that help evoke living the experience? it’s important to understand that communication does not only occur with what we say but also with what kind of images we show.
  • Tone: There isn’t a defined way to speak to our users, neither verbally nor visually. Therefore we’re inconsistent in the way we communicate with the users throughout the site, the functional notifications (such as informative emails) or the promotional actions (such as newsletters). We’re not branding. And we have to be able to provide Ticketbis with a particular voice.
  • Inconsistencies between devices: The experience in desktop and mobile of our site, beyond the particularities of each device, is clearly unequal.

Designing a system and applying it throughout the whole product:

There are several models for system designing, though probably the most popular is the one defined by Brad Frost, in which 5 layers are established: atoms, molecules, organisms, templates and pages.

There are other models that fit our needs better, such as the one proposed by Joey Di Nardo in which he exposes that each of those layers can work both as content and container and that, remaining in the “biochemical metaphor”, the coexistence of one element with the others is taken into consideration:

Some benefits of adopting this methodology are:

  • It provides consistency in the user interface, the experience and functionality, providing benefits widely described and known
  • It offers flexibility and efficiency because when working from the “molecule” or “organism” level, rather than the higher levels, we can create a modular and scalable design
  • This modular and scalable design is much easier to apply in the different devices and make them grow or shrink to fit our needs consistently
  • It’s predictable, which means that is easier to use. But it’s also easier to develop, easing the workload of the production teams
  • Focusing purely on the visuals, should we achieve to create a harmonious site, it’ll be more beautiful and therefore more usable
  • In summary, it saves time and money and since it’ll be more usable, it will improve conversion

Since we’re continuously creating new flows and elements, it’s virtually impossible to make a halt and produce a redesign that can normalise all these elements. Therefore we have been creating in parallel certain elements that will allow us in a near future to reach that first milestone, which is visual consistency throughout the service. some of these elements are:

  • Stylesheets. In which the basic elements in our UI, colours, typographic styles and other basic elements are reflected.
  • Simple interactions. Elements such as buttons, forms or listings, and event cards, must remain consistent throughout the product and among themselves. Similar elements must have similar actions.
  • Provide affordance to the most complex elements in our system. Something that can help achieve that is to keep a clear ration between our system and the real world. For instance, a ticket in our site must evoke a physical ticket in the real world.
  • Start defining our “Ecosystem”. Defining styles in a wide range of elements such as forms and icons, defining the use of colours or the interaction styles in complex processes to start weighing how the behave together.
  • Normalisation of the emailing system. Setting up a set of common elements and articulating them according to our needs, while keeping a visual and tone coherence between our site and the emails we deliver.

Next steps:

Once established the first stage, in which every style in every element is normalised and we have removed all the visual inconsistencies in the whole service, the logical next step is to finish building the system that we started to create.

Starting by defining the minimum unit:

Image for post
Study of a possible evolution for the event block (card) in desktop environment

To then investigate how it grows…

And how it shrinks…

Image for post
Proposed view for event listings in notifications for sellers. Event listings are just series of events with similar information and, often, similar functionality

Or how they behave inside the different processes, such as the Checkout, inside the front pages, such as landing pages or even inside our notifications and emails:

Image for post
Depending on the information we are delivering to the user, the content inside a module vary, but the form remains intact so that, with a quick look, anyone can see an event

Until we finally build a system easy to implement throughout the service that covers any known and future needs:

Image for post
Proposed modular design for an event block (Event card). With a few modular elements to portray an event, we can cover almost every need in our site or email

So that it can quickly affect the user experience in Ticketbis:

To conclude, we must remember that the system we’re building, following the biochemical metaphor, is alive and should work as a guideline, but it must also allow to be modified according to the future needs that may come (for instance after user research, or after analysing conversion rates, etc.) and therefore should never be immutable.

Thanks for your time,

and a huge thank you to Daniel de la Rica for providing a much-needed critical eye and invaluable feedback at draft stage.


This article was written as a presentation for the System Design, style normalisation and brand definition project leaded by the UX Team. After the acquisition of the company by Stubhub, this project will never be released.

Originally published at medium.com on May 10, 2016.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store