TRAKTOR KONTROL S4 is a Dj hardware controller that lets you connect with your tracks using motorized haptic jog wheels that spin and react to nudging, scratching, pitch-fading, and backspins.

My Role

I led the UX efforts for the design of the new Traktor hardware controller starting from the very beginning of the project in early 2015 until early 2017. 

Stage 0:  The initial team consisted form 1 product owner and 1 UX designer (myself) 

Stage 1:  During the incubator we were joined by 1 additional product owner and 1 tech support manager.

Stage 2:  We became a fully functional development team formed by 1 Product Owner, 1 UX designer (myself), 1 industrial designer, 1 CAD engineer, 1 mechanical engineer and 1 electrical engineer.

1. Planning & Coordination

I prioritized the research tasks together with the product owner balancing the customer expectations with the business needs. I reached to other teams and synced with other departments for coordinating our work in order to avoid double efforts.

2. User Research & Insights

I have organized user research sessions in various locations gathering user feedback both in person or remotely. I partnered together with other product owners and other UX and UI designers for executing the research rounds and I led synthesizing sessions.

3. Concept & Ideation

I created new concepts based on user input, both on my own and also in brainstorming sessions with my team. For better communicating the new ideas I created prototypes (cardboard to 3D renders to interactive).

4. Validation & Sharing

I validated the newly created concepts both internally with the team, and externally with the users. Shared the findings within the company by presenting to various internal stakeholders and documented the results.

Stage 0  The kickoff

The Initial challenge

I was tasked to create the next STEMS controller and improve on the design of the Kontrol S5.

Everyone in the DJ market was trying to offer something unique:

  • Pioneer had the embedded CDJs
  • Algoriddim just added Pioneer HID support in their Spotify powered dJay Pro
  • Denon was attempting on taking on Pioneer with a new dual deck media player
  • Numark had a controller with 3 screens, was known for motorized jog wheels and introduced a new hardware full of capacitive controls
  • Roland was entering the DJ market with a new unit that included a step sequencer and was working with Serato.
  • Ableton and Octatrack took over the live act/performance market

Traktor was betting on STEMS. The Kontrol S8 was designed for STEMS so our challenge was to create the next STEMS controller. The goal was to push the innovation even further by offering unprecedented sound control to every DJ around the world.

The pivot

The Jogwheels

STEMS were a unique value proposition. We knew from our surveys that users want to develop more advanced skills.

I started exploring ideas and there was enough room for improvement, but there was one big question keep bugging us. “do we need jog wheels?“

I started looking deeper into this and gathering user feedback from forums and blogs. There was enough of it in order to consider the risk. I studied our sales figures and our competitor’s products. There was enough data to make the point for user testing jog wheels.

User Insights

Manual beat-matching is essential for DJ-ing and sometimes a life-saver


Even beginner DJs


need to feel secure and respected that they can manually beat-match


because many of the tracks can have beat-grid issues and there is not enough time to prepare every track in advance.

Manual beatmatching needs a jogwheel and a pitch fader as a unit


Users that know how to manually beat-match


need to control both pitch bend (via jog) and track speed (via pitch fader) at the same time


because this is the most intuitive way to do a beat-match. For usability reasons these two controls need to be in close proximity.

Jog wheels are used for more functions than just beat-matching


DJs that use hardware controllers


need to perform more things like scratching or seeking


this has made the Jog Wheels so important over the years, creating an emotional link for many users. Jog Wheels are associated with the image of the DJ.

Touch-strips do not have proper tactile feedback and are INACCURATE


DJs that do manually beatmatch


need to receive direct precise tactile feedback through their fingers when they perform


so they feel secure that the action is performed even if the loud environment greatly affects other senses. Touch-strips have no moving parts and therefore you don’t have a proper feedback for your actions while being less accurate.

Stage 1  The New Challenge

Design a new hardware that brings unique value to the market.

Designing from Scratch

The clear user feedback made it possible to redefine the challenge. We started anew with a clean slate that could be defined by our users. Together with the product owner we managed to convince our internal stakeholders about the importance of having a “user first” approach.

How did we do it.

I made the case for this project to be included in the new incubation effort that the company just started. It was also an ideal candidate for using the Design Thinking framework.

Another product owner and a technical support manager joined our team. We also had one r&d developer helping us part time.

The aggressive schedule forced us to re-think the way we work. We naturally left aside the long design debates and we replaced them by user sessions. We ran 3 complete cycles in 2 months.

The Plan

We knew that jog wheels are important but in order to really find out more we needed to observe our users in their own environment.

I worked on: prioritizing our questions based on risk, user questionnaire and prepared for the first round of user visits. 

The Users

Following the user interviews, we identified three main user groups/personas. Ir became clear that the first user group was the most numerous and demanding. If we manage to satisfy them, the product would be a success.


Uses his system controller only at home. He does not have any club gigs, but he is maybe doing small parties with his buddies.


Uses a system controller on stage only if he has to provide his own gear. He would rather prefer to take a USB stick instead.


Actually prefers to use a system controller when he goes to a gig. It gives him confort as this is the same hardware he uses at home to prepare.


People have certain expectations and my first goal was to find out the “must carry” functinality. I was hoping for overlaps betwen our personas. This way I could design with confidence that we are not missing an important feature.

I worked on finding out what would the users see as optional for this device.

Card sorting was the most efficient way to group the “must carry” features and also a good opportunity for gathering insights along the way.

For the remote interviews I resorted to Trello.

The Footprint 

Another challenge was to asses if there is such a thing as a perfect size for the new device. For this I needed to find out a couple of things:

  • do users preffer a modular or a all-in-one solution?
  • what is the size?
  • is there a weight limit?
  • is there any bias towards a certain shape?

The first question was easy to answer as most users opted for for convenience and ease of setup which basically means all-in-one.

For the rest of the questions I got hands-on and I build a number of cardboard prototypes to mimic the real size and shape. 

To make it more realistic I worked together with our CAD engineer and 3D printed the jog wheels. The knobs and faders were simply glued to the surface.

Improving the Visual Feedback

The most important feedback from our users was that they needed to feel secure about their actions. They needed to feel informed and just adding screens to the S4 was not enough. This was not an easy task so I had to try a couple of things.

My goal was to see what information is needed and where. I then investigated if we can use alternative means of visual feedback like LEDs or distributed mini displays.

I did a co-creation exercise using a puzzle game approach. The scope was to find out what is the most natural way to display informations and where is this information expected. For this I experimented with different layouts.

The results were quite a surprise for me and my team. I was expecting that users would simply go for the big screen.

This wasn’t the case. It turned out that people would rather offload some of the information to the laptop in order to have a smaller hardware device.

For the “off-screen” visual feedback I worked on a LED ring to be wrapped around the jog wheel. Plenty of information can be offloaded from the screen with such a simple solution.

I worked on defining the use cases, explored the possibilities and evaluated their potential in user feedback sessions.

I paired with our r&d developer for building a proof of concept prototype and used it in further user testing.

Stage 2  The Actual Development

After the project was out of the incubation/exploration phase, in April 2016, the exploration team returned to the normal duties. The development team was formed and we became a fully functional team. 

The process went from a Design Thinking to a Lean UX model that was more suited for product development.

For the most part it was a cyclical process.

1. Prioritize the features and define the concept/s (usually the responsibility of the product owner and UX)

2. Communicate internally and sync with other teams (product owner and UX designer)

3. Build the prototypes (UX, CAD engineer or r&d engineer depending on the prototype)

4. Recruitment, user testing and data gathering (UX with support from Customer Insights and sometime another available team member)

5. Draw conclusions, prepare next steps and communicate findings  (product owner together with the people involved in research)

At this stage the confirmed features went into development while the UX went into the next loop. In paralel UX would also support development.

I worked on the design of the effect units, haptic jog wheel interactions, sampler functionality and helped with BOM estimation.

I left the project in early 2017 to join the one of the software teams as the new Traktor software started being developed.

What I Learned

What Worked Well

  • Talking to the user. Yes it can be time consuming and costly, but the cost of doing the wrong product is even higher. 
  • Involving the PO and even developers in the actual user interview process helped getting the buy-in for the concept and lowered the amount of design related meetings later in the process.
  • Recruiting people directly via facebook was effective as an emergency measure.
  • Getting out of the Berlin techno “bubble” was a good strategy. I conducted interviews all around the world remotely. I also organized face to face user sessions in the US.
  • UX designer acting like a communication HUB. Can be intense at times, but in the end it provided better alignment.

What Would I Do Differently

  • Isolating the project during exploration had two effects: the first one one was a speed-up of the design process. but the second one was a massive increase in the communication effort so that everyone is kept up to date with our progress. I would consider running the exploration phase inside the company even if it might be slower. 
  • Recruiting people could have been better handled by having a pool of users readily available
  • Considering the amount of effort it took to bring the industrial designer up to speed, I would consider involving him/her earlier in the process