Why MDPI needed one brand across eight initiatives

MDPI had operated for 25 years without a brand. Each of its eight initiatives had developed its own look. There were no shared UI components, no colour system, no typography hierarchy and no style guide. The brand felt fragmented across print, digital and dozens of publications.

The raw material was a challenge too. MDPI’s main visual asset was scientific imagery, often at very low resolution and unusable at scale.

Design system process: from scientific imagery to Figma components

1. Visual language

   Experimented with low-resolution scientific images until a pattern emerged: rendered as halftone, they became a texture that works the same in print and on screen.

   

2. Testing

   A perception survey linked from the MDPI website collected 80+ responses. Alongside it: logo abstraction studies, typography readability tests and accessibility testing.

   

3. Approval

   Presented the findings and the brand direction to all management stakeholders of MDPI worldwide, including the founder. MDPI approved a consistent brand for the first time.

4. Building

   Built the foundations in Figma first: typography, iconography, colour and grid. Layered halftone component sets on top, backed by design tokens, with master templates each initiative extends.

   

5. Rollout

   The system was implemented across all eight initiatives, first in print, then in digital products. MDPI Books, Scilit and JAMS came first; the other initiatives followed on the same master template.

Results: one design system for eight initiatives

All eight initiatives now share one master template and one component library. Only each initiative’s own colour was kept from the old components. Marketing and leadership described the brand as calmer and more structured, and teams gained a clearer sense of what they were building toward.

Reflection

This was my longest project: four years, from the first print materials to the full digital rollout. At the start, many at MDPI were sceptical. Design was seen as a way to make things look pretty, and part of the work was showing that it could do more. We began as two people, the project sponsor and me. Along the way, a new front-end team joined, and later a UX department.

Looking back, I would bring each department in earlier, stage by stage. That would have helped us avoid duplicated work and made onboarding across locations smoother.

If I started this project today, I would use AI for the groundwork: auditing components across all eight initiatives, checking accessibility as the palette evolved, and drafting documentation alongside each component. An AI assistant built on the system’s documentation could also help teams across 17 locations get started in their own time zone. What it wouldn’t replace are the conversations that turned sceptics into supporters.

After 25 years without a shared identity, seeing MDPI look and feel consistent was a real pleasure.

Why readers could not find books on MDPI Books

The Books team had no dedicated design or UX role. The team took on the redesign alongside daily work and expected a visual refresh.

User interviews showed the problem went deeper than visuals:

Baseline: 83% landing-page drop-off · 60.51% site-wide bounce rate · 0.87% conversion rate · 3.38 minutes on site

‘… I couldn’t figure out how to actually finish the order and so I emailed someone and they helped me do it.’

Researcher, user interview

Product design and product management, end to end

Product Designer on the project from first research to launch: UX research, the component library, prototyping, stakeholder management and handoff to development.

With no fixed deadline and little spare capacity on the team, I also took on product management at the start: setting the scope, running alignment and keeping the work moving. The wireframe stage had no front-end developers. Two joined for the prototype stage, hired for this redesign.

UX research process for MDPI Books

1. Research

   Collected the team’s assumptions, then ran 7 moderated interviews with academics and researchers to test them. Together with the Marketing team, collected metrics on how people used the site.

2. Alignment

   The findings gave the team one hypothesis: a more visual, better-structured site helps readers find books. A cross-country stakeholder workshop confirmed it.

   

3. Wireframes to Prototype

   Restructured the information architecture, designed discovery pages around what users could not find, rebuilt the flows and simplified payment. Tested the high-fidelity prototype with colleagues outside the project, as the budget did not allow a second external round.

   

4. Building together

   Moved my desk to the front-end team, followed their builds in weekly streams and ran weekly sessions so design and code stayed aligned. Together we built the tokens for the Books design system.

5. Launch

   Launched with SEO support from Marketing.

Three design decisions, each from a research finding

Decision 1

Explore first, then search

Finding

7 of 7

academics couldn’t find the books they needed. Hotjar heatmaps showed that most first clicks went to the homepage slideshow, not to the search form.

Decision

Let people explore books first, with one search in the top right. The split into Open Access Books and Reprints appears only once you click into it: progressive disclosure, the detail shows up when someone needs it.

Why it works

The filter shows results immediately, so people see what exists before they have to know the right search term. The trade-off: no separate title, keyword and name fields up front.

Evidence · Hotjar heatmap of the old homepage

Components · new on the left, previous on the right

Decision 2

Make the offer visible

Finding

5 of 7

didn’t know what resources existed. The old carousel showed a few books but never said what else there was.

Decision

Narrowed the navigation to the essentials: Library (All Types, Open Access Books, Reprints, Book Series) and Publish with Us.

Why it works

Readers see straight away that there are two kinds of publications, and authors get their own entry point.

Before

Open choices

Decision 3

One-step buying

Finding

Most users

clicked on the currency (CHF / USD / EUR), as the tracking showed. It wasn’t clickable: its colour made it look like a link.

Decision

Replaced the cart form (copies, currency, add to cart) with one button that shows the price: “Buy for 85.25 CHF”.

Why it works

One clear action for the most common case, and nothing looks clickable that isn’t: the price sits inside the button, in one colour. After adding a book, a notification offers two clear ways on: continue shopping or proceed to checkout.

Before

After

Purchase flow after the redesign

Find and add

1. HomepageChoose a book
2. LibrarySearch
3. Add to cartBuy for 85.25 CHF
4. NotificationContinue shopping ↺
   or proceed to checkout

Checkout

1. BasketReview the order
2. Shipping informationEnter data · place order
3. OverviewProceed to payment
4. Transfer informationAgree to T&C · enter credit card
5. Payment confirmationThank-you page
6. E-mail confirmationSent to the reader

Figma · shipping, invoice, payment and confirmation

Key decision: from visual refresh to strategic redesign

The team asked for a new look. The interviews showed deeper problems: books were hard to find, and people did not know what existed. A visual refresh would have made these problems look better without solving them.

The research reframed the work as a publishing platform redesign around structure and flows. Because the new direction came from the team’s own assumptions, tested with real users, the team supported it. That shared direction carried the project through 14 months to launch.

Results after launch: traffic, drop-off and revenue

• Fewer email complaints reached the Books team after the relaunch.

Reflection

This was my first project at MDPI. The brief was simple: give the website a facelift. There was no budget, and work across teams was largely siloed. Over time, it grew into a long-term project, and colleagues from other locations asked to get involved once they saw what it was becoming.

Without any increase in marketing spend, Books quietly grew into MDPI’s second-highest revenue-generating product, which came as a surprise to many in the company.

For the future, I would use AI to analyse interview transcripts and search behaviour faster, and to prototype layout variations for testing. The decisions would still come from talking to the academics who use it.

Looking back, I have rarely had this much freedom: to shape a website’s structure and tone based purely on how people actually used it.

Why users left MDPI’s submission system after login

MDPI wanted to unify user accounts in one dashboard. The work started with Susy, the submission system that generates the most revenue and where every user has an account.

Satisfaction looked reassuring: Marketing’s 2024 author survey, with around 37,000 responses, showed an NPS of about 50, and 95% rated their experience good or excellent. Usage data from the second half of 2024 told a different story:

No one owned the full picture across Editorial, Support and Product, so no one could explain the gap.

Lead UX researcher, with a Product Owner and a developer

Ran the research from the first questions to the first wireframes, together with the Product Owner and a developer. The Product Owner helped recruit participants.

The Editorial and Support teams, who work in Susy daily and handle users’ questions and complaints, contributed their knowledge as input.

UX research process: customer journey, user interviews and synthesis

1. Questions

   Defined what we needed to know: who the users are, what they try to do, what brings them to Susy, and whether they use their account beyond one submission.

2. Customer journey

   Combined metrics, survey data and team insights into a journey map with two personas. The early-career persona came from internal insights.

   

3. Interviews

   Refined the questions in three rounds with colleagues in Basel, then ran 7 moderated interviews with authors, reviewers, guest editors and editors.

   

4. Synthesis

   Clustered findings on an affinity map with 200+ notes and ranked pain points in a matrix. Top two, each raised by 4 of 7: changing an email address, and logging in from a journal page.

   

5. Wireframes

   Turned the findings into low-fidelity wireframes and reviewed them with stakeholders.

   

Six patterns emerged:

• Users are goal-driven and want to submit in 30–60 minutes.
• Mixed terms and a dated look cause disorientation.
• Repetitive manual fields reduce satisfaction.
• Login and navigation friction hurts first impressions.
• Users want one role-aware dashboard.
• Optional features like cover letters are mostly ignored.

Key decision: start with one product and one dashboard

Unifying accounts across every MDPI product at once would have been a large change that was hard to approve. Instead, the work started with Susy, the product with the most revenue and the one every user has an account for. We proposed a single dashboard as the first step, without major changes to the submission system itself.

A dashboard was concrete and low-risk, which made it easy for stakeholders to say yes. That support opened the door to look deeper: into the metrics, the NPS and, through the customer journey, the evidence for why users left.

Results: six validated patterns and a dashboard direction

The UX research reframed User Hub from a UI refresh into an evidence-based redesign. For the first time, MDPI could explain why satisfaction scores and usage data disagreed: the survey measured the overall publishing experience, while the interviews showed where users lost their way in the platform.

The wireframes cover a dashboard with submissions and activity, a simpler profile, self-service support and personalised newsletter interests. My part ended after the research and first wireframes, when I left MDPI. The next phase builds on this direction.

Reflection

This was my last project at MDPI. I was responsible for the research part, from the first questions to the first wireframes, and it became the foundation for MDPI’s dashboard. The next phase builds on it.

What stayed with me was the gap between the numbers and the conversations. An NPS of 50 suggested there was little to fix. Sitting with authors, reviewers and editors showed where they lost their way, often in small things like changing an email address.

What surprised me most was how willing users were to help. People gave us their time and their honest frustrations, simply because they wanted the platform to work better.

I’m glad I brought the Editorial and Support teams in early. They deal with users every day and listen to them in detail, and they stayed with us through the whole customer journey, from validating the interview questions to confirming our hypotheses.

If I started this project today, I would use AI to cluster interview notes and cross-check them against usage data faster. The interviews themselves I would still run in person.

I left before the dashboard was built, but it felt good to hand over a direction grounded in what users told us, not in what we assumed.

Why the lower Old Town of Bern attracts fewer visitors

The lower Old Town is home to small, independent shops, studios, galleries and craft businesses. Tourists pass through, but few stop. Shop turnover and empty retail space had grown in recent months.

The question: which simple measures could make the area more attractive, while respecting the people who live there?

UX research in a team of three

A case study for the CAS in Usability and User Experience at FHNW, in a team of three with a supervising lecturer. Working mostly in digital design, I wanted to understand human behaviour beyond screens.

My part was the second round of street interviews. It validated the findings from the first round and followed up on the open questions it had raised.

UX research process: observation, street interviews and a customer journey

1. Questions

   Narrowed the core question to: which measures can make the lower Old Town more attractive? Two hypotheses followed: experience-based wayfinding and regular events.

2. User groups

   Mapped all user groups, then focused on visitors and businesses, with residents alongside.

3. Observation

   Observed places and people in two periods, February to March and May to July 2025, to see the area across seasons.

   

   

4. Street interviews

   Ran guerrilla interviews in two rounds: 6 open conversations first, then 9 with a structured question grid, on the same weekday and time.

5. In-depth interviews

   Talked with the president of the local association and two shop owners.

6. Customer journey

   Mapped touchpoints and pain points per user group, then prioritised measures by dot voting.

   

What the research showed:

• Visitors like the small shops and personal advice, but find closed shops and unclear opening hours.
• People walk through the lanes but rarely stop. A shop that already looks busy draws people in.
• Shop owners lack foot traffic and visibility, and mostly work alone rather than together.
• Residents want calm, neighbourhood life and less car traffic.

“I’ve lived here my whole life, and I still don’t understand why no one comes to Postgasse.” Resident, street interview

Key decision: listening to people before planning from the map

Urban planning usually starts with plans, standards and building measures. This study started by listening. Talking to visitors, residents and shop owners surfaced details a spatial analysis would likely miss: unclear opening hours, the rhythm of events and the need to be seen together.

The first six interviews already showed the main barriers. The second round confirmed them.

Results: three priorities for the lower Old Town

• A fixed calendar of regular events, such as every first and third Saturday.
• A shared digital presence with an interactive map of shops, opening hours and events.
• A pop-up system that opens empty shops for temporary use.

The plan starts with a test phase together with the local association in 2026–2027, followed by shared branding and digital tools. The study could not test the measures: in a city, prototypes need time, permits and many people. With more time, the next step would be a digital prototype of the event calendar and map.

Reflection

Bern was my first project beyond the screen. Coming from digital product design, I wanted to see whether the same methods hold up in a street instead of an interface.

They did, just differently. There is no click data in an arcade, and no one fills in a form at a shop door. Observation and short conversations had to do the work that analytics usually does.

My part was the second round of street interviews. Hearing the same barriers again, from different people on a different day, gave me confidence that we were onto something real.

I worked on this with two other members: one an architect, the other an engineer. All three of us were rather introverted, which is not the obvious profile for stopping strangers in the street. But we all believed in trusting the process, and we are happy with the result.

It reminded me that good UX starts with listening, whether people are on a screen or in a lane in Bern’s Old Town.