Select Page

Render Node Monitor

Render farm management tool

Computer-Generated Imagery (CGI) is a well known method. Its history goes hand in hand with the history of the computer itself. Nowadays there are no movies made without it in Hollywood, and it has a huge impact on other industries as well such as architecture, product design, or advertisement.

We call the process rendering, while an automatic process is generating an image from a 2D or 3D model.

Rendering a single image by a ”strong” computer could take several minutes. Rendering is a computing-based task. You can imagine how many hours it would take to render an hour long movie that consists of 24 images per second by one computer if the average duration of rendering an image is 15 minutes. It would take exactly 1296000 minutes, or 21600 hours or 900 days or 2,466 years.

However to reduce the duration of this time there is a technique called distributed rendering that allows us to do any rendering job on multiple machines simultaneously. By this method the machines are sharing their available hardware resources that results in faster production. In professional terminology these types of machines are called ”render farms”.

 Companies which have their own render farms often face difficulties managing them. This is how the idea of Render Node Monitor came about.

RNM is a render farm management system, which displays each rendering process in terms of machine performance, threats, warnings, issues or task completion on a web-based dashboard. It can provide remote access to the rendering machines, statistical data about the farm and so forth.

User Experience Research

Journey, and screen mapping

How the project started?

The target user base of the product was small and medium size companies and freelance enterprises, for two reasons. Large companies such as Pixar Studios or Industrial Light and Magic can afford to develop their own softwares in-house.
Besides, we found of the lack of any affordable solutions for small companies.

At the initial state of the project we had numerous interviews with professional CGI studios and freelancers about their workflow.

What difficulties do they deal with?

We found that our interviewees are often deal with difficulties tracking down who is using which rendering machines and for how long. They also find it difficult whenever a render job fails and it takes a while for them to find out what happened. Getting notified when a render is done, sending commands to rendering applications or a machine such as go to sleep when the job is done, or access remotely to any machine because sometimes they are simply not plugged to a monitor also seemed to be important to them.

Sorting out and prioritizing

We got numerous great ideas from our interviewees. Our budget was limited so we had to prioritize the feature requests and only keep those in the concept which seemed to be useful for most of them.

User journey and screen maps

We found that the most important journey users make is the way they add machines and applications to the dashboard. It was extremely important to them to know where they can find the ‘agent application’, that needs to be installed on those machines that they want to control through the RNM dashboard. We designed a multi-step onboarding system which is available from the first login on that shows every necessary step to initialize a machine and an application. Unfortunately we could not implement the onboarding as detailed as we designed originally because development costs were extended the budget, but we created a lighter version of this.

Sketching and wireframing

Rapid and quick ideation on paper


When we made up the detailed concept of the application, our team made sketches about the interface. We were sketched in several variations of each screen, after which our team carried out polls on which solution should be used. Sometimes we were merging each other’s sketches in order to get the best results.


When our sketches got digitalized as wireframes I was about to prepare a fully functional prototype for user tests in Axure RP. At that point it turned out that we hadn’t made up the subscription model yet, and I took personal responsibility for the design afterwards – and I take great pride in this job I finally completed.

Interface Design

Design deliverables

Registration / Login

The registration and login forms are presented in the official first look. (The unofficial one is the on landing page, which is NOT my work.) I wanted to make it similar to Google layouts. Huge white spaces which remind us of paper forms, easy-to-read fonts, and clear texts.


The dashboard was designed for full HD displays. I found it important to note that RNM has not been designed for a responsive layout but desktop only. The dashboard can be personalized by its users. They can rearrange the machine groups by dragging and dropping, and they are also able to do the same by the machines inside the groups.

Groups can be open and closed whether they are in use or not. Also there is a smart feature called paint selection which allows us to select multiple machines or applications by a simple drag.


At the beginning we planned to power our subscription system by the Braintree payment gateway. As time passed we changed our minds and we decided to use FastSpring because they are specialised in selling software licences through their platform and we found their transaction feeses more affordable. While we were designing the subscription model we had to take into account several issues, e.g. that our service offers both prepaid yearly and monthly options, and we are charging from the number of machines the network consisted of, but we also have to tackle issues upgrading or downgrading the number of machines in subscriptions which will alter the fees we charge. It was challenging but I enjoyed every bit of the work.


The settings menu was the most complex interface users interact with, therefore we intended to design it extremely user-friendly.

Our main goal was to reduce the feeling of complexity regards navigation. We thought since people nowadays are getting used to the infinite scroll effects through social media, we should arrange it similarly. So we designed a scrollable menu structure where each sub menu is a tile that is using a toggle mechanism to fragment its content. We recieved a lot of positive feedback on it through tests.

History log and Statistics

We recieved requests by users to provide statistical data bases about the farm usage and also to display error logs in case of render fails, or in case disfunctions in the process of rendering. RNM now supports several different rendering applications and it can collect and display their error logs, as well as basic information about the rendering machines.

 I worked on RNM while I was working at Pocket Solutions Ltd. Since I left this company, there might have been some changes in RNM.

UX team members: Dóra Balogh Szirmai, Gábor Agócs, Bálint Jakab

The landing page of the product was not created by us but the product itself.

Share This