Style normalisation and System design in Ticketbis

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.

Multiple typeface styles live together in one page, making harder to focus on the relevant spots

• 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.

Within the same stage of the checkout process we find the “Pay” button in two different formats, differing in shape, size and colour

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.

The “Information” and “We’ll call you” buttons and the red shape in the stadium’s blueprint make any error message to be hard to perceive.

• 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.

The “requirements and limitations” buttons work as checkboxes, but who could tell without testing them?

The “Tickets” and “Groups and companies” tabs don’t work as such, but rather as links that take the users to different pages

• Iconography: There isn’t a defined system, hierarchy or visual consistency in the used icons throughout the site, in either shape or use

Just looking at the Home page we can spot 3 different iconography styles

Icons designed to work in small sizes are used as illustrations

• 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.

There isn’t a common treatment between the images we use in the featured events

Are we sure she’s our target?

• 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.

In some cases, it’s impossible to identify Ticketbis with a quick look in our communications.

Beyond the logo, there’s no uniformity between our site and our emails. How is this affecting the perception that the users have of Ticketbis?

• Inconsistencies between devices: The experience in desktop and mobile of our site, beyond the particularities of each device, is clearly unequal.

Elements such as the header and the “Search” and “Sale” buttons change arbitrarily in each device.

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.

Atomic Design according to Brad Frost

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:

Here’s an extended information on Di Nardo’s adjustments to Frost’s “atomic” methodology

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.

“Craft” by Invision allow us to create stylesheets in a quick and comfortable way.

• 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.

Different views of the tickets in the proposed process of uploading etickets. The shapes evoke A4 papers, the typical format for a PDF ticket.

• 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.

Normalised “Address” page inside the Checkout process

• 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.

Aspirational designs for “Sales” and “Delivery reminder” emails

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:

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

To then investigate how it grows…

Partial study for the Home page corresponding to the main block. Using the header as a featured event in the Home page as an example of a large-scale event block, with same content and functionality as the original block.

And how it shrinks…

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:

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:

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.