eMagiz Integration Platform

For the last 4 years I have been doing work for eMagiz, the company making an integration platform of the same name, eMagiz Integration Platform as a Service(IPaaS). The platform itself is built using the low-code platform Mendix, which was acquired by Siemens more than a year ago.

The eMagiz platform is used by many enterprise level companies, National and International. Notable names are Royal BAM, PostNL, and Komatsu.

When I started the platform already had its own visual branding and many user task flows. These were not to be changed, but the platform did need to be extended with new features and user task flows. I created these user task flows, then designed and co-implemented these extensions.

However, let’s start with what I am most proud of: A concept redesign based on my own vision.

My vision

Over the years I developed a vision of my own. A vision of how eMagiz should work, incorporating all the feedback and observations I had gathered over the years. This resulted in a redesign that I made on my own time.

The reason? There is no elegant way of phrasing it, so I will just come out and say it: eMagiz is very powerful and also very ugly. Aesthetically it is antique at best, largely caused by the choice for a bright green and deep blue as its brand colours. The usability of the platform is also far less than it could be. The user task flows are consistent, but rigid and unintuitive. This makes the platform difficult to adopt for new users, who need to invest a good amount of time learning.

Changes have not been been made because of what the current users are familiar with. My own preferences notwithstanding, this was the interface language and task flows the users were intimately familiar with, and the risk of a full redesign was considered too great.

My redesign

In terms of aesthetics it is cleaner, clearer, even though it is just an unbranded blueprint. This new eMagiz supports the user every step of the way with a smart help function and a guided tour for new users to get started. The visual picture of your integrations takes center stage and each step looks through a different lens at the same reality. The interface itself feels warmer and more personable and high-tech due to interaction supporting animations.

The mock-up itself begins with a new user, Dev Danny(persona can be found further down), logging in. The platform welcomes him, offering a tour to get to know the platform.

Login screen of eMagiz design concept
The user is welcomed and told how to start

Dev Danny takes the tour, and is shown how to get started. Each of the 4 main steps is introduced and explained.

Dev Danny sees that ‘the bus’ is the foundation the platform
The 4 main steps are introduced.
Collections are explained.
What to do in Plan.
Build is for tweaking and building custom integrations.
Launch is shown and explained.
Context-aware help is always available.

After the tour, Dev Danny makes his first collection. In doing so it will be a lot easier in the following steps.

The Collect panel slides open and Dev Danny creates a new collection
Dev Danny drags a bunch of files and eMagiz recognises Systems, Specs, Message Types.
The first collection is finished.

With the first Collection finished, Dev Danny can start sketching integrations in Plan.

The Plan panel slides open and the bus on the canvas become small. It has no real role now.
Dev Danny opens the collection he made earlier, showing components ready to be dragged onto the canvas.
First SalesForce is dragged onto the canvas.
SAP follows as the second system.
Dev Danny Draws a line, indicating data runs between these systems.
A spec is dragged from the collection and arrows indicating the direction of the data appear as drop zones.
A spec contains multiple message types, and Dev Danny adds all of them.
The spec shows up as belonging to SAP, and SalesForce shows it receives data from SAP.
Dev Danny is done with the Plan for sprint 1.
A group component is dragged onto the canvas from the Do It Yourself palette.
Dev Danny names the group ‘Sprint 1’, using the group for work planning.
The group is done, time to select what goes into it.
Dev Danny draws a rectangle, selecting all inside it.
Then Dev Danny Drags the selection into the group.
Now all the work is placed into the ‘Sprint 1’ group, and Plan is complete.
Upon closing Plan, the main screen changes to reflect the sketch Dev Danny just made.

This is where Dev Danny’s journey ends for now. From here Dev Danny could go to ‘Build’ to tweak things, or go straight to ‘Launch’ if he doesn’t need anything custom.

To really experience the interaction, check out the mock-up here.

Who is Dev Danny, anyway?

When I started working at eMagiz many features did not have a well thought-out user process, let alone a visual design. Before I could work on any of that I first needed to get to know the users and capture them in a persona.


I got to know the users by letting them walk and talk me through their daily process, recording their screen for further analysis later. Additionally I had them do my Super Short Personality Test(SSPT) consisting out of 16 statements they could either agree or disagree with. Their answers revealing where they fall on the Myers-Briggs Typology Indicator(MBTI).

All the input I combined into two single-page persona’s, Dev Danny and Support Steve. While similar people, their goals and circumstances are distinctly different.

This is Dev Danny
This is Support Steve

These persona’s were then taken into account when designing for new features, and as a tool for making users more real. Instead of saying: “Our users will like this” it becomes: “Dev Danny’s life will be a lot easier with this”.

Persona Cards

To create more user awareness and help user-oriented development I made a small card for each persona.

Dev Danny persona card
Support Steve persona card

These cards are designed to be small enough to stick onto a developer’s screen without being to intrusive for their daily work. Before working on a feature the developer can quickly check the intended persona and keep in mind as a first technical prototype is being made.

Written Scenarios & Service Blueprints

Part of the UX toolbox is writing scenarios of how a given persona could use the product, and also making abstract models of interaction. At eMagiz these steps were not taken for every design, but there are examples of both below. There is a PDF describing scenarios about Cloud Architecture and a related Service Blueprint.

Service Blueprint of a user deploying a Cloud Slot for the first time

That’s all(of the selected work)!

I hope you’ve enjoyed reviewing the selection of work I did for eMagiz. Should anything be missing please let me know and I will add it as soon as I can.