Aureka UX case study


Aureka's core business is user referral to online poker rooms. They have the best online poker content platforms in Spanish –a school and a magazine/community– which required constant feature creation, update and tweaking.


My role as a UX designer and front-end developer touched many different areas where I had to coordinate with stakeholders and developers:

  1. From early feature conception to HTML+CSS frontend code.
  2. From desktop only to responsive design.
  3. From landing pages to newsletters.
  4. From R&D to production design and code.
  5. From performance audits to copywriting.

The Design Department included two other designers which focused in graphic/aesthetic design: Javier Sánchez and Ana Ascorbe.


  1. The staff had a close relationship with our community of users (some of them even became part of the team) research was mainly done with stakeholders.
  2. The stakeholders initially kept a close eye to what our competitors were doing; thus some requests came biased.
  3. The biggest pain point came from the complex affiliation system with 3rd parties, critical to the business.

Work done

A product can change a lot in 5 years. Below is a highlight of the improvements added to EducaPoker.

Its design grew old

But we're not talking only about trendy trends

The stakeholders were worried about the look and feel of the site, which was becoming obsolete. After analysing the site, we came to a conclusion that we needed a cleanup and to optimize for readability since the main feature of the the site were articles and forum discussions.

Some of the changes applied include:

  1. Removing distractions and noise from the GUI, specially from the forum threads.
  2. Increasing the base font size from 13px to 16px.
  3. Using a grid for vertical rhythm to increase reading comfort.
  4. Making a styleguide for promotional images; Including image size (that fit in our vertical rhythm) and aesthetic style (each picture from any promotion of a poker room had a different one).

The mobile web came to stay...

More than just a media query

In those years, western mobile browsing was starting to rise. By then our analytics didn't show a big mobile use from our users, why? Maybe the site was unusable in a mobile device? Maybe our product wasn't suitable for such devices?

After research we concluded that our users did want to read our articles and watch our videos on the go. But we didn't just write a media query to make the layout single column at some resolutions. We optimized for mobile:

  1. Adjusted font sizes.
  2. Made interactive elements bigger.
  3. Crafted retina quality assets.
  4. Optimized assets (images and video) for retina displays and 3G connections.

After the update set down, our users gave very positive feedback and our analytics showed a steady increase in mobile daily users. By the end of 2014, +50% of the visits came from mobile devices.

... and brought even more challenges

Design is never done

Like everybody else, we were learning on the go. Supporting hi-res displays meant blurry or bigger-and-heavier images. We had two ways of dealing with this issue.

We initially switched icons to custom-fonts, but we quickly changed to SVG assets because they were:

  1. More compatible.
  2. More accessible.
  3. Easier to align to the rest of the components.
  4. Easier to optically adjust vectors to pixels, avoiding blurriness at small sizes.

With photo-pictures we followed two approaches:

  1. Promo images had been standardised and consisted in just a big size short text with the background brand color. We had the idea of making a fake-image builder with those two inputs: text and brand color. The output was an HTML snippet which presented no problems in resolution.
  2. For images consisting in more than just text: responsive images. But its support was low. So research went on and we found a technique known as compressive images for providing a hi-res low size JPG that provided a good tradeoff for retina displays.

User adquisition, support and retention

You are nothing without your users

Login forms are the most common system for identifying users but are a wall nonetheless. We implemented the now widespread user access via social media account with two objectives:

  1. Making the access as easy as possible.
  2. Avoiding userbase pollution (e.g. spam bots) since we delegated the validity of the data to Facebook or Twitter.

But the registered users metric actually meant nothing. Our major pain point was the dual-register system: in order to access the content you have to register on the site, but you also have to register in a poker room with us as a referrer and play in it.

The user-flow for referring users was the most challenging issue we undertook. To make things even more complicated, each poker room had a different system for their referral linking:

  1. Register after visiting from a specific URL, set with a cookie.
  2. Register after visiting from a specific URL, with a referral code in the URL.
  3. Introducing a promo code during register. We had to be careful with this option since each poker room labeled the code differently.

We ended up with several complementary solutions:

  1. A Help section with a promoted link in the main navigation. It answered the most frequently asked questions. This meant an enormous relief for our Support staff.
  2. Cleaning cookies was one critial requiremen, so we designed a new outgoing funnel with customized information according to the poker room criteria for referral –described above– and the user's browser and OS via user sniffing. Bear in mind that the GUI and shortcuts to clean cookies differ for each browser and OS combination, thus the possible combinations can grow exponentially.

User growth per se isn't important as long as your users don't come back. Monthly Active Users metric was also a major concern. The stakeholders developed several systems to reward the user from using our services and collaborating with the community, strengthening the bond between users:

  1. Gamification: the whole site was designed to make the users aware of the progression they were making in their poker abilities. Once they reached a milestone they got a congratulation and upgraded tools.
  2. Rewards: we had several reward systems for interacting like awarding useful answers to other users in the forum; a sort of shop; or even the possibility to buy tickets for live poker tournaments.
  3. Retention: email communication was also part of user retention, but they were sent in plain-text. To improve the perceive experience, we customized the emails to have the same look and feel as the site.

Copywriting, usually forgotten...

Copy IS the interface

When a product grows, its labelling must too. With each new feature we checked:

  1. If the labelling was constrained by previous features (e.g. similar names for different actions).
  2. That automatic emails felt human by tailoring the text.
  3. The text was short and clear, communicating the most with the least number of words.

... but the BIG forgotten are internal Staff tools

Out of users' sight, out of mind

Since the CMS was only seen by the staff, it was the part of the site that took less care from the stakeholders. But we shouldn't neglect updates to it, since bad CMSs can cost you money (time wasted, unclear flows and UI, etc).

Even though, we managed to apply several improvements to it:

  1. Easy quick-wins such as fixing a 10s load of a heavily consulted page
  2. Improved flows and UIs.
  3. Dashboard design. Real dashboard: no bullshit pie charts, big numbers, flashy colors or below the fold data.


The subprojects listed above were part of a constant work in progress; the way we faced each sub-project was different according to the subproject needs but they usually included:

  • Interviews and documents for:
    • Feature definition.
    • Labelling.
  • Sketching and wireframing for:
    • Information architecture.
    • User flows.
    • Information design.
    • Interaction design.
  • HTML+CSS production-ready prototypes.

Learned lessons


We backtracked often redefining features in an advanced stage, at the additional cost it means. Agile was sometimes used as an excuse to not define properly.

Features requests must have a KPI, even small experiments. If not, you might be wasting resources, solving trivial problems with low return.

Micro optimization can be appropiate when it applies to a huge percentage of your income. In this case, a simple detail such as differentiating how a label is written for every affiliate; or describing complex steps such as the combination of different browsers and operatives systems.

Don't forget that your audience is global and state localisation-sensitive data. For live streamings we were dating them assuming Spain's timezone, but millions of people speak Spanish around the world.


Users don't usually like big changes; know when to make incremental or disruptive changes.

Even small changes can affect greatly the rest of the system. We introduced vertical rhythm to increase readability comfort but we lacked a styleguide. Thus borders, paddings, margins, line-heights, image sizes had to be redefined. It helped us to think of the product visual design as a whole.

Control all your assets. Poker rooms have very creative marketing departments that made our news section look a bit chaotic. The change to in-house promotional pictures provided a more cohesive style.

Browser support was a concern, but we ended up following the de facto standard of supporting the latest two major versions of browsers. This helped us limit adding scripts and polyfills, which penalized up-to-date users (thankfully most of our user base).


Prototyping. Mobile web made us definitively realise it made no sense to render mockups of a "mobile" and a "desktop" version for each subproject, the layout can break on any screen-width. We needed real prototypes to test on any device. We created a styleguide.

Constraints are good. We were always asking for removing meaningless blocks without a KPI in every screen. People suffer horror vacui, specially marketing people. But the transition to mobile (in addition to some analytics) helped them realise that less is better. This new point of view was reflected in the desktop version as well.

Keep it short! We featured some extremely long articles (+5000 words). We reach a two sided solution: rewriting (more concise text) and article splitting.

Asset optimization. Over-optimizing is not a thing. Mobile networks present many problems:

Use vector assets whenever possible. We switched to SVG even for medium-complexity assets such as poker room logos. This produced heavy SVGs, but once gzipped was worth it: you could rescale the logos without problem!

A checklist for projects comes in handy. So you don't forget to style your print CSS and emails!

Have a writing styleguide. I believe users can overcome bad user flows as long as the copy (e.g. the instructions, the buttons) is excellent. Avoid the use of synonims or similarities, it creates confusion.

Give your employees good tools. If you have sloppy tools, you'll have sloppy results. The more employees working with mediocre tools, the more money the company might wasting.