We have joined other fellow Go users at GoLang meetup Prague. Here is slide-deck for our short lightning talk.

Tomorrow, we are migrating our website to the Showmax.Engineering  domain. We are changing hosting, administrative framework, and the overall look & feel. To make the website easy to manage for our back office and talent acquisition teams, we chose to build it on Prismic.

For RSS subscribers, just change the link to: https://showmax.engineering/feed/ (the original link https://tech.showmax.com/feed.xml will be redirected to the new one).

Some time ago, along with the migration of the platform from an on-premises solution to AWS, we migrated almost all of our git repositories (one project, one repository) into one git repository (monorepository/monorepo) that contains everything. As Showmax is built on a microservices architecture, we had a lot of repositories so it was a dramatic change. In this post I'd like to capture in a few lines some of the pros and cons from my perspective as a Ruby backend developer.

To begin with, I would note that when the migration to monorepo was announced, I was skeptical about this change. My first experience with the monorepo approach was from about 13 years ago. Back then it was in SVN, which works a bit differently than git and the workflows were arguably worse. Simply, with SVN, the monorepo approach didn't work very well. Today, I can say that the change to a git monorepo doesn’t differ significantly from the one git repo per project approach. Let’s see the changes:

`git pull` takes a few seconds longer because the repository contains many more tags.

All IDE instances share one underlying source code repository, and so:

it gets more complicated to work on multiple tickets at the same time – you need to stash, shelve, or commit split changes (my colleague pointed out that there is a git-worktree command that could be used to manage multiple working trees in one repository. I personally never worked with this so perhaps I’ll write more about it in the future);

it is necessary to check if there isn't something unfinished in another IDE of another project.

Boundaries of big changes through several services are not obvious and are sometimes so large that when a merge request is created it needs to be split before the code review can start.

Merge requests can contain multiple services and so the code reviewer sees the feature as a whole package.

All changes through multiple services for a given feature can be seen in `git log`.

It only takes one pull for everything to be up-to-date.

Let’s have a practical example of the positive and negative scenarios of creating a merge request through multiple services and how to split a big merge request. This demonstration will be using only standard `git` commands. At the end of the article, I share a simpler solution that uses JetBrains products.

All examples are demonstrated on a simplified monorepository. To create the example repository and simulate the changes, I wrote a quick script mrsc.rb that you can use.

We will use a standard linux distribution with `git` and `tree` commands that should be already available to you. The `tree` command is used to visually display file structure.

#sh#
~$ uname -a
Linux 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) x86_64 GNU/Linux

#sh#
~$ git --version
git version 2.35.1

#sh#
~$ tree --version
tree v2.0.2 (c) 1996 - 2022 by Steve Baker, Thomas Moore, Francesc Rocher, Florian Sesser, Kyosuke Tokoro

First we create the structure of the future monorepo:

Then we create a git repository from it and stage the created structure:

#sh#
~/monorepo$ git init && git add . && git status && tree .
Initialized empty Git repository in ~/monorepo/.git/
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   gems/gem1/gem_file1.rb
	new file:   services/service0/app/app_file1.rb
	new file:   services/service0/service_file1.rb
	new file:   services/service1/app/app_file1.rb
	new file:   services/service1/service_file1.rb
	new file:   services/service2/app/app_file1.rb
	new file:   services/service2/service_file1.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   └── app_file1.rb
        └── service_file1.rb

9 directories, 7 files

Let’s commit changes and show the change in git:

#sh#
~/monorepo$ git commit -m "init example repo" && git log --stat
[master (root-commit) d96dc0d] init example repo
 7 files changed, 23 insertions(+)
 create mode 100644 gems/gem1/gem_file1.rb
 create mode 100644 services/service0/app/app_file1.rb
 create mode 100644 services/service0/service_file1.rb
 create mode 100644 services/service1/app/app_file1.rb
 create mode 100644 services/service1/service_file1.rb
 create mode 100644 services/service2/app/app_file1.rb
 create mode 100644 services/service2/service_file1.rb

commit d96dc0db07383d25c70414b97223747a98b94a35 (HEAD -> master)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:34:25 2022 +0200

    init example repo

 gems/gem1/gem_file1.rb             | 3 +++
 services/service0/app/app_file1.rb | 5 +++++
 services/service0/service_file1.rb | 5 +++++
 services/service1/app/app_file1.rb | 5 +++++
 services/service1/service_file1.rb | 1 +
 services/service2/app/app_file1.rb | 2 ++
 services/service2/service_file1.rb | 2 ++
 7 files changed, 23 insertions(+)

Now that we have the monorepository prepared, let’s demonstrate the advantage of the monorepo approach. In this example we will make a change across multiple services. Thanks to the monorepo approach, the code reviewer will have a better overview of what has changed across the whole architecture and how it works together.

First we create a feature branch, simulate the changes, stage, and commit:

#sh#
~/monorepo$ git checkout -b feature1
Switched to a new branch 'feature1'

#sh#
~/monorepo$ ruby ../mrsc.rb example1

#sh#
~/monorepo$ git add . && git status && tree .
On branch feature1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service0/app/app_file1.rb
	new file:   services/service0/app/app_file2.rb
	new file:   services/service2/app/app_file2.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   ├── app_file1.rb
    │   │   └── app_file2.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   ├── app_file1.rb
        │   └── app_file2.rb
        └── service_file1.rb

9 directories, 9 files

#sh#
~/monorepo$ git commit -m "feature1" && git log --stat -n 1
[feature1 8913d49] feature1
 3 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service2/app/app_file2.rb

commit 8913d49209d443e3f9a3b3584d52a8ce6a60ed4d (HEAD -> feature1)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:44:40 2022 +0200

    feature1

 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)

We see that the change is small and ideal for one merge request. Let's assume the change has been reviewed and approved, and so we merge it into the master branch and delete the feature branch. Success, everyone is happy.

#sh#
~/monorepo$ git checkout master
Switched to branch 'master'

~/monorepo$ git merge feature1 && git branch -d feature1
Updating d96dc0d..8913d49
Fast-forward
 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service2/app/app_file2.rb

Deleted branch feature1 (was 8913d49).

For the second example, we will demonstrate a disadvantage of the monorepo approach. The starting steps are the same as in the previous example but the change is considerably larger than expected. Since each service is changed as a project in its own instance of the IDE, we may not even realize that it's so big until we actually create the merge request.

It’s very difficult to review big merge requests. Without a “pair code review session” with the one who created the merge request, it may sometimes be simply impossible to correctly understand the overall concept of the change.

In this example we will show how to revert the big commit and split it in a way that every impacted service can have its own merge request.

First we create a new git branch called feature2. Then we stage and create the big commit with all the changes.

#sh#
~/monorepo$ git checkout -b feature2
Switched to a new branch 'feature2'

#sh#
~/monorepo$ ruby ../mrsc.rb example2

#sh#
~/monorepo$ git add . && git status && tree .
On branch feature2
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb
	modified:   services/service1/app/app_file1.rb
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   ├── app_file1.rb
    │   │   └── app_file3.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   ├── app_file1.rb
        │   └── app_file2.rb
        ├── lib
        │   └── lib_file1.rb
        └── service_file1.rb

10 directories, 10 files

#sh#
~/monorepo$ git commit -m "feature2" && git log --stat -n 1
[feature2 b4077d1] feature2
 9 files changed, 130 insertions(+), 9 deletions(-)
 delete mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service0/app/app_file3.rb
 create mode 100644 services/service2/lib/lib_file1.rb

commit b4077d1926a5729911fa9c85ad84f8b8c3442247 (HEAD -> feature2)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 13:42:26 2022 +0200

    feature2

 gems/gem1/gem_file1.rb             |  1 +
 services/service0/app/app_file1.rb | 26 ++++++++++++++++++++++++++
 services/service0/app/app_file2.rb |  4 ----
 services/service0/app/app_file3.rb | 13 +++++++++++++
 services/service1/app/app_file1.rb |  8 +++-----
 services/service2/app/app_file1.rb |  1 +
 services/service2/app/app_file2.rb | 45 +++++++++++++++++++++++++++++++++++++++++++++
 services/service2/lib/lib_file1.rb | 39 +++++++++++++++++++++++++++++++++++++++
 services/service2/service_file1.rb |  2 ++
 9 files changed, 130 insertions(+), 9 deletions(-)

#sh#
~/monorepo$ git status
On branch feature2
nothing to commit, working tree clean

In practice the change can often be even larger, however, for this demonstration it is enough. Every time I create a merge request, I look at it myself before assigning someone to review it for me, and in this case I would notice that it is just too big. It would be better to revert the commit and split it into multiple smaller merge requests. Now that we know what we want to achieve, let’s see how to do it.

First we need to "uncommit" the changes. This is done simply by setting the git HEAD reference to the previous commit with the `git reset` command. In our case we will use a soft reset, which will leave the changes from the last commit as that is exactly what we need. If we used a hard reset, the changes from the last commit would be removed from the working tree.

#sh#
~/monorepo$ git reset --soft HEAD^ && git status
On branch feature2
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb
	modified:   services/service1/app/app_file1.rb
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

Now we have the working tree in its pre-commit state. The `HEAD^` part means we want to go back one commit. It's the same as `HEAD~1`. We can use `HEAD~2` or `HEAD~5` if we want to go back 2 or 5 commits respectively, or we can directly specify the commit hash we want to get to. This can be viewed using the `git reflog` command, which is a log of all the actions that have been performed in git.

#sh#
~/monorepo$ git reflog
8913d49 (HEAD -> feature2, master) HEAD@{0}: reset: moving to HEAD^
b4077d1 HEAD@{1}: commit: feature2
8913d49 (HEAD -> feature2, master) HEAD@{2}: checkout: moving from master to feature2
8913d49 (HEAD -> feature2, master) HEAD@{3}: merge feature1: Fast-forward
d96dc0d HEAD@{4}: checkout: moving from feature1 to master
8913d49 (HEAD -> feature2, master) HEAD@{5}: commit: feature1
d96dc0d HEAD@{6}: checkout: moving from master to feature1
d96dc0d HEAD@{7}: commit (initial): init example repo

In this example, the `git reset --soft HEAD^` command would have the same effect as `git reset --soft b4077d1`. Thanks to the `git reset` and `git reflog` commands, you basically don't have to worry about "screwing up" something in git, like a bad commit or merge, because you can get back to any previous state.

Let’s finally split the big merge request into, let's say, 3 merge requests, service0, service2, and service1 + gem1 because these two were closely related.

First, we `git stash` everything and find out the stash number.

#sh#
~/monorepo$ git stash push -m "feature2" && git stash list
Saved working directory and index state On feature2: feature2

stash@{0}: On feature2: feature2

The stash number is 0. Since we are in the feature2 branch, which is in the same state as the master, we can rename it to feature2_service0. We unstash the changes related to service0 using the `git restore` command and then we stage the changes:

#sh#
~/monorepo$ git branch -m "feature2_service0"

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service0 && git add . && git status
On branch feature2_service0
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb

We then commit and update our big merge request with this change.

#sh#
~/monorepo$ git commit -m "feature2 for service0"
[feature2_service0 ea8057e] feature2 for service0
 3 files changed, 39 insertions(+), 4 deletions(-)
 delete mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service0/app/app_file3.rb

Next, we create a branch and merge request for service1 + gem1 in the same way.

#sh#
~/monorepo$ git checkout master && git checkout -b feature2_service1_gem1
Switched to branch 'master'
Switched to a new branch 'feature2_service1_gem1'

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service1 gems/gem1 && git add . && git status
On branch feature2_service1_gem1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service1/app/app_file1.rb

#sh#
~/monorepo$ git commit -m "feature2 for service1 and gem1"
[feature2_service1_gem1 aca2003] feature2 for service1 and gem1
 2 files changed, 4 insertions(+), 5 deletions(-)

Now we just need to make changes for service2.

#sh#
~/monorepo$ git checkout master && git checkout -b feature2_service2
Switched to branch 'master'
Switched to a new branch 'feature2_service2'

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service2 && git add . && git status && git commit -m "feature2 for service2"
On branch feature2_service1_gem1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

[feature2_service2 9e641ff] feature2 for service2
 4 files changed, 87 insertions(+)
 create mode 100644 services/service2/lib/lib_file1.rb

Finally, we delete the no longer needed stash (which is at position 0) and switch to the master.

#sh#
~/monorepo$ git stash drop 0 && git checkout master
Dropped refs/stash@{0} (1c0d783c065a2b45365102ad9c9b1b6719164a5c)

Switched to branch 'master'

Just to check that everything looks as it is supposed to:

~/monorepo$ git log --all --stat
commit 9e641ff098084dd329f8731ccf04a6db9cb293cf (feature2_service2)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 15:08:15 2022 +0200

    feature2 for service2

 services/service2/app/app_file1.rb |  1 +
 services/service2/app/app_file2.rb | 45 +++++++++++++++++++++++++++++++++++++++++++++
 services/service2/lib/lib_file1.rb | 39 +++++++++++++++++++++++++++++++++++++++
 services/service2/service_file1.rb |  2 ++
 4 files changed, 87 insertions(+)

commit aca20037700ab9e820fe2c2d1a53a241a2165287 (feature2_service1_gem1)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 14:36:41 2022 +0200

    feature2 for service1 and gem1

 gems/gem1/gem_file1.rb             | 1 +
 services/service1/app/app_file1.rb | 8 +++-----
 2 files changed, 4 insertions(+), 5 deletions(-)

commit ea8057e50de93c7ae8defdee0d4b0841f4d1dc3d (feature2_service0)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 14:31:11 2022 +0200

    feature2 for service0

 services/service0/app/app_file1.rb | 26 ++++++++++++++++++++++++++
 services/service0/app/app_file2.rb |  4 ----
 services/service0/app/app_file3.rb | 13 +++++++++++++
 3 files changed, 39 insertions(+), 4 deletions(-)

commit 8913d49209d443e3f9a3b3584d52a8ce6a60ed4d (HEAD -> master)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:44:40 2022 +0200

    feature1

 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)

commit d96dc0db07383d25c70414b97223747a98b94a35
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:34:25 2022 +0200

    init example repo

 gems/gem1/gem_file1.rb             | 3 +++
 services/service0/app/app_file1.rb | 5 +++++
 services/service0/service_file1.rb | 5 +++++
 services/service1/app/app_file1.rb | 5 +++++
 services/service1/service_file1.rb | 1 +
 services/service2/app/app_file1.rb | 2 ++
 services/service2/service_file1.rb | 2 ++
 7 files changed, 23 insertions(+)

In the end, switching to a monorepo approach was not a big change. One just needs to keep an eye on a few things. I only ran into the situation where I needed to split a large merge request once and it was related to renaming a payment method in all the services that use it. If you analyze the feature a bit in the beginning, you're very likely to break it down into smaller merge requests that make sense on the first try.

The ability to make merge requests across multiple services seems great to me. As the person doing the code review, this gives me a lot more insight than having separate merge requests for individual services, and perhaps with more time delays. Often I don’t have a full understanding of what exactly my colleagues are working on and so seeing the changes as a whole gives more context.

At Showmax, the vast majority of Ruby developers use Rubymine, which simplifies many operations, especially by making them easier to understand than the terminal.

For me, it's a great tool that saves a lot of time in many areas, including the situation of splitting up large changes. In a git window, in local changes, you can create a shelf from selected files and folders and then unshelve it at any time to any change list. You can also use Git to work on several features simultaneously, which is radically shorter than a pure terminal and git procedure. Nevertheless, it is good to know both because it may come in handy in the future.

Almost everybody in the tech world knows the term “design system” these days. There are many articles around the internet and there are also special websites like this one which accumulate various design systems from around the world.

Here at Showmax we had a historical problem with inconsistency not only across all the platforms we support, but even within one platform itself. This problem caused many issues like dropping brand awareness, inefficient work on the designer and developer level, slower execution time as we didn’t have coherent and standardized design foundations and components.

How did the company get into this situation?

The first full-time designer was hired after 2 years from the time that Showmax was born. The company used different design agencies with different mindsets and guidelines. As Showmax grew, there was a need to build and establish a product design team in house. This is where it all began and the idea for creating our own design system came to light.

The first attempts ended even before we started. We realized very quickly that how designers talk and name several elements is very different from how developers see it. We couldn’t find where one element ends and the other begins. We tried to separate the effort into different teams with dedicated designers for mobile apps and for web & Smart TV teams (btw, we are hiring) and work on two streams. The idea was to gather the results and see where we match in our thinking. We had several sessions, discussions and workshops around the basics but without any progress – everybody was super frustrated about the result and we had to put it on hold. Total failure.

Some time after the first attempt we hired more people into the team and the need for design rules and standardization was even higher. We knew that we were going to slow down the whole design and development process if we did not have the design system in place. The system can decrease the time to deliver and experimentations within a team significantly. This put pressure on us to reopen the topic again. This time we agreed on a dedicated designer who would work purely on the design system with all frontend teams. They started with an audit of all the components we had on every platform. The team had weekly sync meetings, workshops and other activities, but after some time the team was tired and unmotivated as they didn’t move fast enough. The energy and the setup of the team was not right and instead of constructive feedback and progress they challenged each other on almost everything. Total failure…again.

After all the experience from the past, we made a complete pivot in the journey. We established an internal “design group” consisting of product designers that are working on each platform - David Lengyel, Matouš Jemelka, Lukáš Podhola and Daniel Valčík. We also asked for support from a project management (yes, we know Design system is not a project, but product itself) to handle our operational, organizational, and tracking needs. So Pavla Safronov joined our group. The fun began.

We knew that we would have to gain the reputation and trust back from the failures that had happened in the past. First things first – we mocked up the structure of how we want our design system to work in Figma (the main design tool we use) and we started to write a solid business case for our C-level management to convince them, so that they will give us the time to build it. After the presentation to our CEO (Yolisa Phahle), COO (Barry Dubovsky), Head of Product and others, where we demonstrated how many shades of gray there were (not 50 but 39 – only on iOS platform!!) and how the design system impacts costs to build anything frontend facing for the company, we received the time we needed. But … we had to work on our daily agendas and tasks as well.

Equipped with the right team, the motivation, approval from the senior management, and a clear time limitation, we mapped out what components and foundations we needed. This gave us clarity on how high the mountain was. To manage expectations we created a timeline (roadmap) where we applied all the foundation blocks and components and divided them into design work and implementation development work. This set an expectation for our stakeholders. Each Friday we have jumped on our weekly DS sync and updated each other on the status of our respective design system tasks. There have been many topics where we have opened Figma with our exploration file and showed each other different approaches and techniques and made conclusions.

Our product is not complicated, but what complicates it is supporting many platforms and teams from landing pages and payment secure pages where our acquisition teams are working via mobile apps (iOS and Android - smartphones and tablets) to leanback experiences such as Smart TVs, tvOS, and Android TV.

With such a diversity of development teams, we had to create strong foundations that are shared across whole teams and act as the basics for component creation. Those components might differ based on the libraries linked to each team. As you might expect, native mobile apps use different patterns, approaches, and goals than, for instance, a Smart TV or the acquisition part of the product. A component that works on one platform (e.g. the bottom bar) will not work on a Smart TV. For this reason, the libraries contain components that are usable on a specific platform or part of the product only. Our development teams have created their own code libraries with the same design tokens and naming convention that we use in Figma. Expect an article already being written by Zachary Rowden on how our acquisition team implemented our design system for their code base.

Doing everything remotely and asynchronously

The Covid era opened our mind to how to work, even on complicated tasks and activities, fully remotely. And across continents. All the work we have done on the design system was built from our homes via video calls and Slack channels. We have got familiar with this setup and it helped us to introduce a means of communication with other departments within the company. We use several channels in Slack:
For any update or announcements from our side about design system changes (just recently we refactored Table Row for the iOS team). This channel is for announcements only.
For any discussion between designer, developers, product managers, or anybody else from the company.
For “design group”, we have a private channel where we discuss day to day progress, iterations, ideas, feedback, and more.
In case you are interested in working asynchronously, Matouš Jemelka (one of us) wrote a really cool article about it – check it out here.

Building a design system is just the beginning of a long-term journey. Count on that before you build your own. We want to focus on usage and its analytics in Figma and in the code. Luckily, the Figma Organisation plan has the ability to measure each library and component.

Our plans are to integrate more teams into our design system, we have already started to talk with our Marketing department and CMS team as we can involve other parts of the company and establish many more synergies. We are also working on our Copy system which will cover every corner of how we communicate within the product to our customers and visitors. But we will write about this part in another article.

Check out our first version of design system documentation created in Supernova and send your feedback or comments to design@showmax.com.

Earlier this year, Šimon Koudelka, Showmax Product Manager, presented our approach to continuous research at the WebExpo conference. For a while now, continuous research has been done at Showmax by non-researchers – product managers and designers – who are helping the regular UX research team by collecting some insights on their own. This alternative approach, though it might seem risky or inadequate, helps us develop our apps faster and respond quickly to customers’ needs, act on hiccups in the user journey, and more.

The talk that you can watch in the video below introduces examples of how we collect insights, create opportunity maps, and why we think it’s important to involve developers in the research. You can learn how to adopt our approach at your organization if you find it helpful.

<div id="presentation-embed-38984442"></div>
<script src="https://slideslive.com/embed_presentation.js"></script>
<script>
  embed = new SlidesLiveEmbed("presentation-embed-38984442", {
presentationId: "38984442",
autoPlay: false,
verticalEnabled: true,
});
</script>

Compared to evaluative research, which answers specific problems often related to usability, continuous research belongs to the field of generative research, where you explore broader topics. Generative research helps to better understand users and is great at finding weird patterns; things the users do which you wouldn’t expect. For example, we‘ve learnt that users used the continue watching row as a substitute for the Watchlist. Users simply hit the play button and immediately exit the player to find the film later in the continue watching row. It works, but it’s a bit complicated and it reveals that there is probably something wrong with the Watchlist feature.

At Showmax, we work in a hybrid model, which means even though we have the UX research team, there are more people who can conduct user tests or customer interviews. Each product team talks to two users every week. Interviews are conducted remotely as our users are located in Africa, while product development takes place in Europe. Product teams usually have a stable script, which is related to a business objective they are currently focusing on. Quite often developers attend these interviews as well, as they enjoy watching users tinker with our app. We always do a debrief, where we discuss the learnings and takeaways and discuss the potential next steps.

Thanks to the frequent customer interviews, we’ve discovered the topic of rewatching. Some of our users rewatch the same films or episodes many times. This is particularly true about the kids’ content. For example, one of our young users watched a single episode of Peppa Pig nineteen times within seven hours! We dug deeper and found out that seventeen percent of our users rewatched something in the past month. When you learn such an insight, then you can place it onto the opportunity map (a concept lately championed by Teresa Torres) and start investigating what potential the topic has to help you reach the company goals.

We move fast thanks to the frequency of the customer interviews. Product teams learn something new every week. The credibility of product managers and designers increases as they can now easily show how well they know their users. Furthermore, the involvement of developers helps them get better context for their work.

Our approach takes time as it requires training of product managers and designers, so that they can conduct the interviews independently. However, product managers and designers can help researchers, who wouldn’t be able to cover all the opportunities themselves. With product teams involved in the process, researchers can finally free their hands of the day-to-day operations and focus on the high-value strategic deep dives.


Are you eager to join our Product management team and would you like to keep people engaged on the Showmax web and SmartTV apps? Read more and apply.

Continuous Research: When Non-Researchers Take the Lead

Go in Showmax

You might be interested

WE ARE MIGRATING THE WEBSITE

Backend Developer’s Guide to Monorepos

Showmax Design System: The Precious

Continuous Research: When Non-Researchers Take the Lead

WE ARE MIGRATING THE WEBSITE

Backend Developer’s Guide to Monorepos

Showmax Design System: The Precious

Continuous Research: When Non-Researchers Take the Lead