The Goal

For a this master’s project, I have been working in a team for six months to make a redesign for Ultimaker, a Dutch producer of 3D-printers and fillaments. At the moment, Ultimaker 3D-printers are mainly used in what they call the ‘carpet floor’. The carpet floor consists of offices and homes, where users only have a few printers that are used mostly for prototyping purposes. 
We redesigned the software ecosystem surrounding Ultimaker’s new, future context: the concrete floor. The concrete floor consists of manufacturers with larger amounts of printers, which are used for production, manufacturing assisting and moulding purposes. In this context, factory operators should be able to manage fleets of 10-40 network-connected printers at the same time. Our design goal was:

“We want operators to be able to efficiently manage a fleet of printers with a feeling of control in factory workshops.”

Ultimaker asked us to design something they could implement relatively quickly. Therefore, they did not want us to redesign the printers themselves. We ended up redesigning the software the factory operators would be working with, and with this, we designed and optimized their (future) workflow. The resulting product can be seen in the video below. 

This project was divided into three main stages: the analysis stage, the conceptualizing & testing stage, and the final redesign stage. If I were to go into each stage and explain all decisions make and iterations we did, this page would become too long. Therefore, I will only give a short explanation for each stage with some visuals to back it up. 

 

Analysis

Ultimaker gave us much freedom during the project. Besides the context of the Concrete Floor, we were relatively free in what product(s) we wanted to (re)design and who to design it for. This made the analysis phase even more important than it usually is. During the analysis phase, we analyzed the possible user(s), defined the product ecosystem, and tried to find the main product qualities and problems. Based on this, we made our own design brief and made a list of wishes and requirement. 

The User
Because we were designing for a future context, the actual user(s) didn’t exist yet. We had to create our own vision of what we expected these users to be like. We did do interviews with  some fabrication laboratory employees about their experiences operating multiple printers at the same time. However, we were aware that these people were different from actual factory employees. This meant that our personas were mainly based on assumptions, but we were able to use them as a starting point to base our first designs on. During the entire project, the personas were adapted when we learned more about our (future) users. Below is an example of one of the personas we made: 

The Ecosystem
The main issue we found in Ultimaker’s current design for the concrete floor, was the chaotic ecosystem. To be able to use and connect the Ultimaker S5 printers, you could or had to use three types of software, a desktop, a phone, and the actual printers. Functions were overlapping and it was not clear what you had to use when. We visualised this in the image below. 

Product Qualities and Problems

Based on user testing with ourselves and other students, we came up with four problem areas we decided to focus on:

problem 1

The product ecosystem is chaotic.

The level of (feeling in) control is insufficient. 

problem 3

The depth of feedback is too low: Users are not aware of what the printers are doing when and why.  

The current software does not work comfortably for more than three printers

Requirements

Based on the (user)research we did during the analyisis phase, we made a list of requirements surrounding two themes: working efficiently, and feeling in control. These two themes were the foundation of the rest of our project. 

Conceptualizing & Testing

 

During this phase, we thought of multiple concepts, chose one to further develop and prototype, and tested it with multiple people. We used the results to improve our design. The first design was tested with students. The tests were conducted in a room at our faculty where we had access to three Ultimaker S5 printers. We used paper prototypes for our redesigns for the software on desktop, mobile phone, and the screen on the printers (see image below). 

Based on these tests, we redesigned the task division between desktop an the mobile application (see image below). We eliminated the use of desktop for machine operators and focused completely on software to be used on a mobile device, preferably a work tablet. Because we would rather do one thing right, than multiple things wrong, we decided not to focus on redesigning the desktop and the printer interface. We decided to focus on the center of our redesigned ecosystem: the mobile interface. 

This redesign of the mobile interface was tested with people as closely to the actual (future) users as possible: factory machine operators. Because we were testing a future scenario, we did everything we could to help the test subjects imagine themselves being in said scenario. 

The tests were conducted at the factories themselves, to help the users get into the right mindset. This meant we could not use the actual Ultimaker S5 printer. Therefore, we made cardboard 3D-printers with pre-printed products (see image below). Just like the actual S5 printers, these printers could light up. We built a digital prototype of the mobile interface, so the test subjects could use the app on an actual tablet. 

We ended up with quantitive and qualitative test results, which we converted to something we could use for our final redesign. The results were visualised in the image below. 

Final Redesign

The images below show some of the changes we made to the mobile interface. The last image shows our redesigned ecosystem that our interface design is a part of. To see the product in action, please watch the video at the top of this page. 

My Role

During this project, we were obligated to switch roles every 3 weeks. Every team member had to have each role at least once. Therefore, I had multiple roles: team leader, chair of coach meetings, reviewer, and editor. Besides this, within our group we made sure that everyone was able to be a part of every part of the project: We all did project management, usability tests (with the existing product, paper mockups and digital prototypes), and reporting. 
Looking at the project as a whole, my personal emphasis was on making sure every team member was reaching their full potential, building the physical prototypes, and designing the user tests. 

What I learned

 

  1. I learned how to make a persona for a target group that does not exist yet, and adapt it when more information became available. 
  2.  I learned that clear role devisions and agreements benefit teamwork greatly. 
  3. When working in a team, it is beneficial to start each day with a 5-minute personal update and evaluation. This helps to make sure everyone is on the same page and gives people the opportunity to express potential frustrations.
  4.  Interviewing and testing within the actual context of the user leads to richer insights. It helps the user imagining themselves using the product in the context it is meant to be used in, and it helps us to understand the context. For example, during one of our user tests, we got a tour of the factory. This tour helped the test subject refer their problems to certain locations at the faculty, and because we were actually there, we were able to understand it perfectly.
  5. When you are testing with company employees, it is best to not have their employer there. During one of our tests with an  operator, his manager came in a few times. The manager meant well, but he had a tendency to take over the conversation and talk over the operator. As our design was not meant to be used by the manager, his imput was not useful. Furthermore, his behaviour was actually a bit degrading towards the operator. Luckily, the operator did not seem to be influenced too much by his manager, because we made it clear to him that we wanted his opinion and not his manager’s. 
  6. As a team leader, it helps to start each day with a short and simple presentation in which you evaluate what has been done before and what needs to be done today. Within this presentations should be room for feedback from the team.