Geert Brookman is R&D manager at Repak, a Dutch manufacturer specialized in thermoforming packaging.
Their robust packaging machines are renowned for their reliability and versatility, especially in the food industry.
Geert, what brought you to 6’4” design manufactory?
In a very short time, we had to tackle quite a sensitive topic: the software of our packaging machines. It is already more than 15 years old and continuously improved over time.
Because of its history, we wanted to get to the bottom of it all from different perspectives. The software is used for and by several disciplines. And each discipline has its own way of accessing and using the software.
The users are accustomed to how it is working now, and it is the tool for many. You do not want to lose that when developing a new, innovative way of operating the machine.
How did you intend to solve this initially?
The original plan was to work with a time-movement diagram. By determining who uses which process when, we wanted to match what the user would want to see or be able to, and how to visualize this in an effective manner.
That was the plan, or so we thought. In the end though, we spoke mostly about how the machine works and not about how the user would like to use it. Eventually you are not solving problems for your customer anymore, but only looking at what you as a Repak employee would want it to do.
In my opinion, you lose sight of the goal. And that is not only to satisfy your customer’s needs, but to turn him into a fan of your machine interface.
You ultimately chose to have a sprint week. What was your experience?
Intense! (laughs) It felt incredible being able to gather and bundle so much information in such a short time.
And here lies the trick – how to bundle and make sense of it all. I was immensely proud to see the results on Thursday morning: the essence of what we have, what we want to achieve and what is best for everyone.
For what kind of projects would you do a sprint again?
We have done it now for the new software and the visualization of the HMI. I think a sprint is a perfect tool for that.
We also have applied parts of its process when we stumbled across a problem in our everyday work. For that it is an effective tool as well. The sprint question in that case would be: “I got this situation, what would be the solution for this acute problem?”
You then organize a day to investigate what the actual problem is, what could be the cause. Days two and three, when you really go deep and make quick choices, you can bring that back to one day. Then you try, build and test. This way, you can propose your proven solution to the customer really fast.
That is pretty much the process that you would use in a sprint week.
So you’ve adapted this new process already to your company’s workflow?
For this specific point, yes. It comes in very handy when dealing with service issues. In my opinion, the challenge for certain mechanical development processes lies in being able to make a proper prototype on short notice.
Still, the first two days of a sprint week are incredibly valuable. And they are applicable for almost any project. The first two or three days are ideal to kick off a project. You gather a lot of useful questions and topics to investigate further.
We used to develop a lot based on a client’s inquiry. If you do it that way, most of the time you end up with a solution that only fits one particular situation of one particular client.
The question is whether you can scale such a solution. It needs to be robust enough so it can serve other clients’ needs as well before you can add it to your company’s portfolio.
This is one of the things we got confirmed during our sprint week: We always need to take the time, even if we think there is none. The sprint model works great under those circumstances. To help you to explore “What would the ultimate be like?” How might we address more than just this one client? And can we with whatever we define still serve our original client?
Who would you recommend doing a sprint week as well?
Engineers, for sure. Their typical dilemma is to innovate purely on technology, and not much else.
Too often it is about a clever solution; simple, but superior. However, you do not come up with a superior solution by simply making it complex or clever. It is the user who needs to experience your solution as being smart and reliable.
During the sprint week, you start right away on day one with figuring out who to interview on the last day. In most cases, that would be the end user. It might be a service engineer on their way with a new tool kit. Or it is a worker from the factory floor who needs to assemble a module and you want to supply him with new instructions.
That is why it is important to start from the user’s perspective instead of just looking at technology alone.
What was the outcome of your sprint week?
We delivered a UI concept at the end of the week, which guides the user in a much more intuitive way through our machine.
By doing so we created a very useful mock-up. With it, we were able to talk to all sorts of stakeholders about the UI and its visual aspects. That was actually one of the big questions at the beginning: What’s the look and feel of the future? What will work with our brand in mind? Without getting rid of everything old, but by keeping essential elements and delivering a fresh and new design.
What strikes me most was the effect of the visuals. With each interview, we stressed the fact that it was only a prototype, what matters is the functionality and the logic of the UI. Still, the first impression is determined by what you can see. That was a very important lesson for me personally.
It is the same when you work on a physical product: The first impression is about what you perceive, thus also what you can see. Only after that comes how you use a product. Once that was successful, you have created a positive base to build on.
That is the perfect moment to talk about the functionality of your concept. And with such feedback you are able to design a solution that turns your users and clients into fans of your product.
Read in part two Geert’s tips on how he set up his innovation team and what happened then.