Workshop
A couple of hours. We settle a question you keep coming back to, using what's already in the organisation.
Products people understand, trust and use.
Hi, I'm Anton, a product designer living in Amsterdam. For 20+ years I have worked with innovators on their product-market fit. Since 2024 I have been developing software too.
01 — Experience
From validating concepts
to building the front-end.
In 2024 I went all-in on learning to develop software and work with AI agents, so I could offer a complete service: from concept to shipped code. The five cases below give an impression of the work I did before.
Cases
-
Ayvens 2022–2024 Aligning three service journeys across 44 countries. Design thinking Jobs-to-be-done Video walkthrough On-site observation
Three million cars requiring maintenance, repairs, and tyre changes across 44 countries, each with its own procedures, regulations, and ways of working. As the only designer on the RMT team, I used design-thinking methods to bring stakeholders with the right expertise into the design process. Together we integrated three user journeys: the customer, the service providers, and the cost controllers. The result was software that could be used in 44 countries, and a service blueprint the organisation still uses today.
Ayvens Design thinking.
The problem
The suppliers of Ayvens needed a dashboard for the jobs they were working on but what this dashboard should look like wasn't clear yet.
The solution
Prioritising what mattered
We solved this by having a workshop with a group of the suppliers the dashboard would be built for. First I asked them what could go wrong during a job, and what would count as success. Then the suppliers prioritised those events on a matrix. Could they act on it? Did it impact them or the organisation? If it scored high on both it would go on the dashboard.
Sketching the dashboard
After the suppliers had decided what needed to be on the dashboard, we asked them to sketch a dashboard that made sense to them. We combined their ideas until they agreed on one design.
Result
The final version became a stylised version of what they had drawn themselves.
Ayvens Jobs-to-be-done.
The problem
The job of a cost controller is complicated, and the regional differences added another layer of complexity. We needed to research this without it turning into dozens of contradicting PDFs.
The solution
The jobs-to-be-done format made it possible to categorise each task and overlay the differences with precision. These differences could then be resolved one by one, until a single JTBD document remained.
Result
That map gave us the clarity to develop a repair, maintenance and tyres system that could be used in all countries.
Ayvens Video walkthrough.
The problem
A good way to demonstrate how software can solve a problem is to click through a simple prototype of your product. But in a three-sided business model it's easy to miss the perspective of the other stakeholders, because not all of them are using the same software.
The solution
To fix that, we made videos that showed how all the stakeholders worked together. We did this by making screen recordings of how software for the different stakeholders was used. Those clips and images became a movie of how the suppliers, and the cost controllers contributed to the experience of the driver.
Result
This movie gave the team a way to show anyone in the organisation how the service would be provided, in under 10 minutes. In addition, this video revealed multiple steps that could be improved.
Ayvens On-site observation.
The problem
We knew our software was only one of the tools our users needed to get the job done. The question was how it all worked together.
The solution
We observed the service providers during the maintenance job, and we saw how the cost controllers got that maintenance approved. Doing so taught us the order in which they did the job, and the other tools, hacks and workarounds that were used.
Result
These insights turned into a more efficient workflow with less switching between apps and fewer workarounds.
-
ING Ventures 2020 Bringing multi-party aircraft financing into one system. Co-creation Workflow optimisation
ING Ventures was the corporate venture capital arm of ING Bank, and they wanted to start a platform for financing aircraft. Through Edenspiekermann I worked on this with a junior designer and a creative director. By working with the specialists and learning how they worked, we were able to design a platform in which several banks and leasing companies could close a deal together.
ING Ventures Co-creation.
The problem
Airlines order aircraft in batches. Each aircraft can have its own configuration, and it can be financed in more than one way. The paperwork is dense. That's why we needed to work together with specialists, but how do you make the most use of their time?
The solution
We started with sketches and the specialists used Excel to show their ideas. This gave us a basic understanding of their way of working, but it was lacking nuance and we noticed that we often got stuck when the specialists weren't around. To solve this we created a design system (toolbox) that made it possible to design the software together with specialists in real time.
Result
This design system became more realistic over time and when the workshops were over, we had not only finished the research, but also a design that was validated by the specialists and ready for production.
ING Ventures Workflow optimisation.
The problem
When researching how the bankers and leasing specialists worked, we noticed an almost endless amount of emails and Excel sheets that were needed to get a deal done. The challenge was to streamline this process, but in a way that felt familiar and easier.
The solution
Taking what they had perfected
Rather than coming up with a completely different interface, we looked at how their Excel sheets were set up, and the keyboard shortcuts they used without thinking. We took that into the product.
Moving the conversation
Then we looked at the communication around the different moments in the process. We moved this into the product as well, in the context of the numbers and terms that were being discussed.
Result
The result was one place to run the whole deal, in an interface that felt logical and familiar.
-
30MHz 2015–2018 Designing an IoT platform in search of product-market fit. Social IoT
30MHz was spun off as an IoT platform from 9apps, an AWS-native cloud-engineering company, and was still searching for its product-market fit. During my three years there, the team explored different markets before focusing on AgriTech. I was responsible for design across all customer touchpoints, from packaging, marketing, and trade-show presence to the software used by clients: a sensor-data platform that growers use to share sensor data with consultants and each other. Working across the entire experience expanded my focus from UX to CX: shaping not only the software, but how the company presented and delivered it.
30MHz Social IoT.
The problem
When talking to agritech growers to learn which sensors they needed, they told us that they wanted to share the data with other growers as well. The question for us was how we could integrate this into the product, while making sure their data stayed safe.
The solution
We started with a platform our customers could use to install, configure and monitor sensors. This gave them the option to create dashboards and explore sensor data.
On top of that we built the social features required by our customers:
- A user rights model, that linked sensors and sensor-data to owners, groups, dashboards and viewers.
- Functionality to write and edit comments in the context of the datapoints that were being discussed.
- Functionality to invite other people to your data and dashboards
Result
We had created a Social IoT platform in which growers could have the conversation they used to have on WhatsApp or Email, alongside the data that was being discussed. As a bonus they would invite other people that got introduced to the platform as well.
-
Hippo CMS 2013–2016 Preparing the pivot from a CMS to a digital experience platform. Customisation Enterprise complexity Preparing for a change
Hippo CMS was already a mature enterprise product, used by governments and Fortune 500 companies, but its interface needed a redesign. At the same time, the company wanted to pivot the product from a CMS into a Digital Experience Platform that would help organisations understand their visitors, personalise customer journeys, and measure content performance across channels.
I brought together expertise from across teams, translated it into a coherent design direction, and communicated that direction throughout the organisation. The result was a redesign that was ready for the pivot ahead.
Hippo CMS Customisation.
The problem
Hippo CMS was used by a wide range of organisations, from Fortune 500 companies to government websites. That meant that almost everything had to be customisable. The challenge: How do you design a CMS that would be customised in ways you could not expect?
The solution
I asked implementation specialists to show me a wide range of implementations, and then I looked for the ones that were modified the most. One thing that stood out:
- Some clients relied on the backend of Hippo and only used a small part of the front-end.
- Other clients used almost everything Hippo had to offer, and even built an extensive amount of functionality on top of that.
Once we understood the extremes, we could put them on a spectrum and fill in the options in between.
Result
This overview made it possible to realise a modular design. The different parts of the CMS were isolated in a way that they could be removed, but also connected in a way that would work as a whole.
Hippo CMS Enterprise complexity.
The problem
One of the challenges with enterprise software is the complexity of the stack. The challenge was to design a system without creating collisions, where all the pieces are working together.
The solution
A Hippo world map
To get an overview of the system as a whole I interviewed different specialists and used a metaphor. Let's pretend that Hippo is a world. Could you map out the countries that make up Hippo CMS? What are they specialised in, and what are their neighbours?
Working on themes instead of features
With a list of the major functionalities, we brainstormed on what they had in common. Instead of working on one feature at a time, we worked on these common themes as a whole.
Result
Working on common themes made it possible to take the broader context into account. The result was that we could merge features, prevent features from overlapping, we could skip steps and be more efficient in development.
Hippo CMS Preparing for a change.
The problem
Hippo had plans to change their CMS into a digital experience platform, but at shorter notice a redesign was needed. These were two major projects with different timelines, that couldn't be separated. The challenge was to create a redesign that was a step towards changing the CMS into a DXP.
The solution
Expanding our horizon
To prepare for the transition we wanted to look as far into the future as possible as we could reasonably do. We did this by capturing the ideas that were going around in the organisation and making click-through prototypes of how they could work.
A shared vision
When we felt confident we had captured most of these ideas, we combined them into a vision of how Hippo could work as a DXP. After this we stripped everything that wouldn't make it into the next version. What was left became the basis of the redesign.
Result
The result was a redesign that went live on time and was a first step towards the transition to Hippo as a DXP.
-
Ultrafris 2003–2013 From freelancing at agencies to redesigning a social network. Redesign at scale Social network Online dating
In 2003 I started freelancing as an interaction and visual designer. My first job was the Playboy.nl website. After that I started working for agencies on brands like NS, KPN, KLM, Philips, and Volkswagen. From there the work shifted from agencies to working for clients directly. Retail, publishers and various startups. One of these startups was Hyves, a platform racing towards millions of users at full speed. While working on Hyves I started expanding my team and we managed to do a complete redesign of what was by then the biggest website in the Netherlands. From there we started working on Pepper, which grew into the country's third-biggest dating site before it got sold. Later we worked on EyeOpen, the first online mortgage advisor in the Netherlands, now part of Knab.
Ultrafris Redesign at scale.
The problem
After three years of fast growth and development, the social network Hyves started to crack on all sides. The site consisted of hundreds of pages with overlapping functions. My job was to untangle the information architecture and the interface without holding development up.
The solution
Creating a pattern database
We built a database of patterns and noted, for each one, on which pages it was used. Similar patterns were linked so they could be merged later. With this overview we started with the patterns that were used the most.
Setting up page structures
We created page structures that showed which element should go where, without waiting for them to be finalised. That way development and design could continue while the structure underneath was being rebuilt.
Result
The last phase was placing the new patterns inside the page structure. By doing so, we had created a design system, years before that was commonplace. The result was a complete redesign of the biggest website in the Netherlands.
Ultrafris Online dating.
The problem
When the broadcast agency RTL asked us to work on the concept development of a new dating site we had two main concerns. How could we offer a better experience than our competitors and how could we get our users to pay for our service.
The solution
Showing people in context
Research showed us that matches were found more attractive when placed in the context of things our test subject liked. Therefore we placed a moodboard at the top of every profile page. There you could see pictures of your match next to images of their interests.
Making it easy to write a bio
When our copywriter wrote the bio, matches suddenly became a lot more attractive, but almost nobody could write a good one. We took inspiration from magazines. Using fun and light-hearted questions.
Not a personality test
From psychologists, we learned that matching two people based on personality is not very effective. Yet users valued personality tests, and they increased users' willingness to pay. Our solution was to match people based on values and social norms, because research showed that these have a strong influence on whom people marry.
Result
Our focus on making matches as attractive as possible worked. Pepper grew rapidly and became the third-biggest dating site in the Netherlands before it got sold.
My portfolio and resume are available on request.
What I build
Live products, designed and shipped solo. See the work →
02 — What I do
Aligning customer experiences with business needs.
Sometimes that's a workshop. Sometimes a day a week with your team, and sometimes four days a week until a project is done.
Design partner
One day a week, or a rhythm that works for you. I work with your team and keep the customer in the room.
Interim designer
Four days a week until the project is done. I research, design and test until the problem is solved.
03 — How I work
Work gets easier when you
use the right tools.
A big part of design is deciding what method to use when. Below are the methods I reach for, what each one is, and why you'd use it.
Understanding your customers.
Build on evidence, not enthusiasm. So I talk to customers, watch on location how they get their work done, and map the job they're really hiring your product for.
-
Understanding your customers. Mom Test method.
Rob Fitzpatrick noticed that a lot of the feedback he got on his startup was suspiciously positive. So he created a method where even his mother would tell him when his ideas were no good.
It works by never mentioning the idea. You talk to potential users about what they actually did, find the problems that keep coming up, and check how much those problems really cost. The goal isn't to convince anyone that an idea is good. It's to find out whether a real problem exists before anything gets built.
-
Understanding your customers. On-site observation.
People are bad at describing their own work. Not because they hide anything, but because routine turns invisible once you do it every day. Watching it happen shows what an interview doesn't tell you. Which programs someone switches between, the spreadsheet kept on the side because the official system is too slow, the steps that are skipped when it gets busy.
-
Understanding your customers. Customer journey mapping.
For customers, the relationship with a company isn't just a website. It starts the first time they hear about you and ends with what they tell the next person. In a customer journey map, all of that is laid out in order: what they compare you to, signing up, getting it working, the moment something breaks and when they need help.
Sales, support and engineering each have their own interpretation of the customer experience. The customer journey map replaces those with one, and the weak spots usually turn out to be the steps that fall in between, where nobody is responsible.
-
Understanding your customers. JTBD Mapping.
Jobs-to-be-done starts from an odd-sounding premise: people don't buy products, they hire them to get a job done. Nobody wants a drill. They want a hole in the wall, and the moment there's an easier way to get that hole, the drill loses.
A JTBD document lists the tasks customers are trying to accomplish with your product. It shows you how important those tasks are and how well they are served today.
Structuring the product.
Designers are rarely the users of the product. So I design with stakeholders, in design thinking workshops or co-creation sessions.
-
Structuring the product. Design thinking.
The knowledge needed to design something well can usually be found in or around the organisation. But it's not uncommon to not be heard and for the loudest opinion to win.
Design thinking uses a couple of principles to prevent exactly that:
- Everyone writes before anyone speaks.
- Ideas are sketched.
- People vote instead of discussing.
- The group has to agree on the problem before anyone may propose a solution.
-
Structuring the product. Co-creation.
Instead of disappearing for two weeks and returning with a design, the designer sits down with the people who know the business and they design the solution together.
-
Structuring the product. Service design.
A product is usually one part of something larger. An order gets approved by someone, delivered by a third party, and repaired by a fourth. The customer deals with one company, but behind the counter it is several parties depending on each other, each working in their own system.
Service design shines light on what the customer never sees. It shows why a promise that was made at the front gets broken at the back, and what it would take to keep it.
-
Structuring the product. User journey mapping.
Designing interactive applications is not about designing screens, it's about the movement between events.
A user journey is a design in which the steps in a process are placed one after another. This forces you to see the process as a whole and exposes the moments when the flow gets interrupted.
-
Structuring the product. Design direction.
A design direction is a set of principles the team agrees on. Some are behavioural, such as "never make someone wait without telling them what is happening". Some are about the visual language: type, colour, spacing and tone. Once it is written down, the question stops being "do we like it" and becomes "does this match what we agreed".
The design direction of this site. Focus on the process, not the output.
Concept
A lot of senior product designers have a beautiful website, with beautiful images that make the work stand out. But at a certain level every designer can make a product look good. What I noticed is that from those images alone I can barely tell whether a design is the right solution for the problem. But because the focus goes to the images, I often skip the text. To me this seemed to be an interesting starting point to differentiate myself from other designers.
Design choices
Images
To keep the focus on the text and to give my site something that sets it apart from websites of other designers, I chose to use no images. They get their place in the portfolio document I send to clients and recruiters later in the process.
Text
Without images, text becomes the hero, but a hero shouldn’t be boring. So I chose short texts. I only explain things when you click on something, and stories start with a clear problem and end with a solution.
Typography
With text becoming so important, I relied on typography for two things: readability, and the look of the site. So I chose big type, lots of whitespace and a clear hierarchy. For readability that meant serif body text and sans-serif headings.
Visual design
The site is about process, and process often happens on walls covered with post-its. I wanted that feeling in the site, without turning it into a gimmick. So it came down to the colours of a whiteboard and online post-its for the backgrounds. For the text I used ink blue, without making it look like handwritten text. The interface elements that were left I drew as if I sketched them on paper. Wobbly enough to feel drawn, precise enough to look professional.
-
Structuring the product. Content-driven design.
Most web design starts with the structure of the website and the words come last. In some cases this is far from ideal. Content-driven design starts with a message. The text and design of the site are developed at the same time with the goal of getting the message across as effectively as possible.
Testing what might fail.
With AI-generated prototypes and in-house user testing, you keep the process moving. To solve issues before they become real problems.
-
Testing what might fail. Rapid functional prototyping.
A clickable prototype fakes everything behind the screens. With agents writing the code, you can now build working prototypes that run on real data. This changes what a test can tell you. A click-through prototype shows whether people understand it. A working prototype shows you how it's being used. And when all the learnings are implemented, it's a smaller step towards the final product.
-
Testing what might fail. In-house user testing.
Research labs deliver high-quality work, but you have to plan it weeks ahead and the budget is substantial. In-house testing lets you put an idea in front of people when you need it. Five people who resemble the real users. An hour each, a prototype and a few realistic tasks will surface most of the serious problems. After five interviews, the same problems start repeating.
Getting it to work.
Design tools linked to AI, agents that write the code, and a human in the loop to keep it on point. The result is working software, not just a design document.
-
Getting it to work. Design system development.
A design system is a kit with default settings for colours, spacing and text sizes, plus the ready-made buttons, forms and tables that return on every screen. It keeps the design from becoming inconsistent every time someone designs a new screen.
-
Getting it to work. Agentic coding.
Agentic coding is programming with the help of AI, and for me this was a game changer. I had learned how to build a front-end myself, but I was much slower than someone who did it all day. When using AI I'm roughly ten times faster than I was on my own, and that is enough to pull building back into the design process. Now, interaction, content and layout can be developed at the same time, and a second version costs an afternoon instead of days.