Helios Kliniken

Challenge

Solution

Get Your Guide

Challenge

Solution

Klöckner

Challenge

A shop without a cart

Klöckner, of course, required a shopping cart & check-out as part of their online eCommerce solution.
Their new online customers were their old offline customers.
Only later would there be newly registered customers.

You need to sign in

Although customers didn't need to be logged-in to place products in their shopping cart, only logged-in customers could access the check-out page.
As a matter of fact, the logging in to the site was pushed quite aggressively on all pages, on the homepage, the SRP, the detail page and the shopping cart.

Personalised prices

The main reason that signing-in was required was that it was the only secure way to disply the individual prices for each registered customer (each customer negotiated their own prices, primarily based on frequency and quantity of purchases).
So what does a simple check-out look like?

Solution

Fast check-out preferred

This is not the first shopping cart and check-out that I've worked on.
My views haven't changed on what makes a simple & fast check-out process, which may or may not be a good thing.
And because everyone who sees the check-out page is logged-in, I knew it was easy to show all the necessary details.

Yet another one-pager

Analogue to my check-out for Immobilien Scout, the Klöckner check-out is on one page.
At the top, there are editable snippets or modules of info.
The one-page checkout shows; who's buying and who's receiving the goods, when they're being delivered, how it will be paid and, of course, which product and how much it costs.

Convoluted is good for cross-selling

I'm sure that a convoluted purchase funnel à la Amazon makes sense in some cases, e.g. for up-selling of stuff.
But what on Earth could you upsell to someone who has just ordered a 6m long steel beam?
The answer, of course, is not a matching 4m beam in pale blue!

Klöckner

Challenge

Digitalise the dinosaurs

The business consultancy etventure asked me to help them with the B2B shop for their customer, Klöckner.
Klöckner is a huge steel manufacturer, making steel sheets and various types of beams in various thicknesses.
etventure had convinced Klöckner to digitalise their business, i.e. to start selling those huge steel beams online.

Good to know your customers

They had also targeted a particular group of users - buyers at small steel shops and architects & builders.
When I was called in, they already had a first shop online which was an out-of-the-box eCommerce solution from hybris.

We're nearly finished, could you look at it?

They wanted to know from me what should be changed in that out-of-the-box solution to achieve a good eCommerce user experience.
It soon became clear that any front-end changes would induce costs (duh!) yet there was simply no budget for that!
Yet more proof of why you should first validate, then code.

Solution

You call this a shop?!

The first thing was a heuristic evaluation to identify what was OK, what was good & what needed to go.
This was followed by a quick and dirty sketch of how I thought it could be improved.
The next thing was a quick prototype in Axure to show how much better it could be "with those tweaks".

Coding then validating is the wrong way round

Ugly discussions followed about how much more everything would cost and lack of budget and all that.
I talked about showing it to some buyers at small steel shops to get real feedback. The results of that round of usability tests confirmed most of what I had pointed out and were sufficient justification for a substantial reworking of the shop.

Let's get moving

Everything was tidied up and loads of superfluous content was removed (or pushed out of the way or down into the footer area).
The homepage was tidied up, the filtering on the results page was simplified, the number of products was dramatically reduced by grouping the beams & sheets into variations of a product (different lengths, different thicknesses etc.) and such things.

Test fast and often

A further test round confirmed that we were well on our way to having a very easy to use shop.
At the time of writing, the Klöckner shop was still a closed beta.

Immobilien Scout 24

Challenge

The SEO team asked me to look at their layout for their new results list.
They were planning some front-end changes.
Up until that point, I had assumed that the SEO team had been helping the Search team with organic traffic from Google.
But no! the SEO team had been working for years on their own separate search and results list.
And their key metric was the contact rate on the detailed listing page.
But that was also the Search team's key metric and a high contact rate was the main reason why people advertise their property at Immobilien Scout.

Comparing apples to oranges

I was shocked.
It turned out that a highly paid team of experts were basically sabotaging the company's own results list.
They had been holding back Google traffic for their own purposes.
And had been for years. There followed some hefty discussions.

Solution

Nobody questioned the value of the SEO team.
Everyone agreed that the first part of their job was to generate loads of traffic from Google, i.e. to make sure that potential consumers looking on Google would find our portal.
The SEO team agreed that the second part of their job was passing that traffic along to the Search team but added that their key performance metric measured something else.
So, I questioned their key metric - I suggested that there could only ever be one key metric for any SEO team: ranking on Google's pages.
I also questioned their refusal to pass along the organic traffic to the "real" results list (where Immobilien Scout made its money).
I talk about "good" links vs. "bad" links: the good links would pass the consumer along to the real results page with one more bit of search information... for example, a max. rent of €1000
The SEO team remained adamant that their hands would remain tied until their key metric was changed.

I can't live like this

I had no choice, I raised the entire issue with senior management.
They were shocked.
At the time of writing, senior mamagement was defining a new key metric for the SEO team.

EDIT: Four months after I wrote this, the company confirmed my findings and asked the head of the SEO department to leave.

Immobilien Scout 24

Challenge

One of those things that happens in any large agile organisation with several big simultaneous projects, is that the UX designers loose touch with each other.
They were spread throughout a fairly large building.
As mentor and coach to all designers, I heard from several that they were dissatisfied with the situation.

Solution

So, I invented a regular meeting where the designers could work together and review each others work.
I called my meeting series the Design Olympics.
Once every few weeks, we'd meet up and, using a real problem from a project, evaluate and evolve the work of the particular designer.

That weakness known as ego

When a group of designers discuss things, there tends to be loads of opinions, gut feelings and lots of egos involved.
But my aim was to abstract the problem & solution and pass on valuable skills, knowledge and insights.
I didn't want a design pattern because, as I wrote in "interaction pattern library", patterns don't support how UX teams actually work.
We assessed various projects and sub-projects; the filtering of results, a search based on commuting time, the detail page for a listing, a mortgage calculator, onboarding and so on.

Immobilien Scout 24

Challenge

At the time of this job, it was becoming the norm to book appointments online. There were things like Open Table for restaurant reservations and Salon Meister for visits to a hairdresser/massage parlour etc. And if you live a digital life, then you've most probably been booking your holidays online for years. Yet it was not possible at that time to book a property viewing appointment online.

Piggy in the middle

Life is not always easy in the real estate business... for restaurants or hairdressers or hotels there's always been a list of daily time slots waiting to be filled. And that list rarely changes. Either the table is free and can be reserved or not. The same goes for the hairdresser or the hotel room.
But the real estate agent was caught between the seller or landlord and the potential purchaser or tenant. His planning needed to remain flexible.
The question was, could we get a suitable software tool online?

Solution

It so happened that ImmobilienScout24 was a giant in the internet business and like all giants, financed an incubator lab where budding start-ups tried to convince us in their 3 month stint that the world needed them. One of the start-ups, Timum, came to us with an online appointment booking tool. It was rudimentary, crude and hardly usuable. But it was in the right place at the right time and had a huge amount of potential.

Burning at both ends

Booking an online appointment in the real estate business involves 3 groups of participants but only 2 groups of users.
The participants are the property seeker, the real estate agent and the property seller.
The users are the seeker and the agent.
The agent communicates more-or-less secretly with the seller and adjusts his viewing calender appropriately.
To get some clarity into this chicken and egg situation, we decided to ask 3 fundamental questions: #1, would property seekers like to book an appointment online? and #2, would an online booking calender help or irritate real estate agents? and #3, where and how do real esate agents organise their viewing appointments?

Front-end's the easy bit

Since more-or-less all property seekers liked the idea of booking an appointment online, we decided to go with it and inserted an easy-to-use appointment chooser into the contact form.
We didn't promote it in any way, holding it back for seekers who had decided to contact the real estate agent.
We argued that if we promoted it, the agent would be inundated with requests from not-really-so-interested seekers.

Another complication

The real estate agents had their own appointments systems (ranging from Outlook through Google Calender to full-blown eCRS systems depending on their size). They were not happy at the prospect of writing their appointments a second time in the back-end.
But many of the smaller agents were prepared to abandon their own "amateurish" methods and adopt this calender since it appeared to decrease their workload - always a good thing.
So, we started with the small fish, arguing that the bigger agents had their own system anyway. And that to help them, we'd need to import from their system which meant all sorts of API discussions.
Not what we needed at the time.

This saves time

Currently, real estate agents who use the system type their appointments into the back-end.
The back-end is still messy and needs tidying up.
But at the time of writing, the adoption rate among real estate agents is impressive.

Immobilien Scout 24

Challenge

The financial & bank crash of 2008 led to a fall in asset values and rather perversely, in Germany, to an inflated intererst in property ownership. More and more listings appeared on ImmobilienScout24 for developments. Those projects where developers would buy land and erect several town houses or an apartment block with 30 or so apartments. I was asked if the portal could become more attractive for the many developers who were building all over Germany.

Solution

As always, I looked at the current situation and compared it to the user flow of a prototypical purchaser. I was indeed surprised to discover that many of the pages which I thought necessary already existed. Yet somehow, they were all of a low quality. And even worse, they didn't fit into a typical user flow.

Less but better

I drew up a page flow for discussion purposes. Many in the team were surprised to learn about the existing pages. I argued that the fastest approach would be to improve what was already there. Only a few minor alterations and adjustments were necessary. Then I started some layouts to show what I meant. It seemed that most team members "got" it. Critical to the whole success of the developments, was the fact that they should be recogniseable within a typical results list which normally consisted of individual listings. Each development then received its own project page on which the individual listings were showcased.

Immobilien Scout 24

Challenge

Like many online portals, Immobilien Scout had grown over many years. The header and navigation that was still being used stemmed from the original portal.
Its aim: To be the biggest collection of online property advertisments.
The primary navigation contained just three items "domestic", "commercial" and "offer property".

Wind of change

As of 2012 the business of property advertisments had flattened out. Roughly 90% of the available objects in Germany were on the portal... that cow had been truly milked. Something else would need to generate money.
Although the portal had a vast range of products and services, most of them remained unvisited - except where the SEO team bought visitors from google.
Somehow everybody knew that the old header and navigation didn't even hint at the wide range of products and services offered by the portal.

Pocket-sized internet

The mobile web site saw a constant rise in mobile traffic... but it consisted solely of the core functionality, namely "Search" and a "Watch List".
There was no navigation allowing access to other pages or content.
And to make matters worse, there was no clear statement (read: strategy) on mobile content, i.e. should all content be available on all browsers (read: tablets and smartphones).
Could I deliver a silver bullit?

Solution

There were many other features and products on the portal but they were easily overseen. Some of them were already succesfully making money.

Music in the air

I'm not a musical person but I started referring to the valuable, money-making products in the secondary navigation as 2nd violins.
That metapher of an orchestra helped many of the parties involved to understand what I was trying to achieve, they realised that I intended to name some new 1st violins.
The time had come to get those 2nd violins out from the back and get them up-front.
The premise was breathtakingly simple... the more money a 2nd violin turned over the higher its chances of becoming a 1st violin.

Looking for violins

Three possible navigational structures were shown to users. Collegues from User Insights organised different card-sorting sessions. The user feedback combined with card-sorting insights revealed a clear winner.

Politics

The final decision about who would be a 1st violin was/is a huge political debate, which required/requires a consensus within upper management. As of middle of December 2013, the decision was still to be made.
I had completed my work on a navigation concept with 5 or 6 items in the primary navigation, a breadcrumb "trick" to swallow intermediate levels and to allow more room for the contextually important navigation.

You get what fits

And per CSS it was easy to adapt the appearance for PCs, tablets and for smartphones. I worked with designers to finalise the look.
User Research tested both the desktop and smartphone versions.
The great news is that users found both versions easy to navigate and they like the look. The header module (as a SSI) really just has to be built. If only we could agree on the information architecture.

Immobilien Scout 24

Challenge

Like many online portals, Immobilien Scout sells products online.
Those products range from the initial contractual agreement with real estate agents to inserting a listing to evaluating a property to booking an on-top-product etc.

Vive la différence

Different products are owned by different teams which in turn means different product owners. Each product owner has the freedom to implement a shopping experience that seems to them to be most appropriate. This in turn meant that users saw very little consistency between the purchasing flows.

Buying freedom

For historical reasons (read: legacy issue) all users need to be fully registered and logged-in to buy any of these products.
The time had come to revisit the concept "checkout".
Would it be possible to find similarities between products and the purchasing flow?
Would product owners consider changing their version of the shopping experience? Was there anything to be rationalised?

Solution

Three of the most frequently used shopping flows on the portal were investigated; the evaluation of a property, the insertion of a listing by a private person and the insertion of a listing by a professional real estate agent.
Yes! as of 2011 normal people and real estate agents list properties using two different processes.

Gradual abstraction

Back to the frequently used flows; The next thing I did was to abstract the steps which made up each of these flows. This allowed me to recognise common denominators.
I separated the product selection & user description from the registration and both of those from the checkout & payment.
I also noticed that the more conventional purchase funnel à la Amazon with dedicated pages for each step was too long, i.e. contained too many steps.
The question remains, do you really need to know where someone lives when he/she is buying a virtual product?
The correct answer is no, but address information is often required for legal reasons.

One-pager

In a flash of inspiration I realised that Immobilien Scouts checkout should be on one page.
A summary page with the editable snippets or modules of info.
The one-page checkout shows; who's buying, how it will be paid, who's receiving the bill and, of course, which product and how much it costs.
In the world of virtual products, users should be able to purchase products online with no unnecessary steps or pages.

Immobilien Scout 24

Challenge

Over time, Immobilien Scout had developed two separate platforms for logged-in users: one for people who were just looking for real estate or who privately offered real estate and a different one for professional real estate agents.
This in turn had led to an unacceptable work load with two separate teams of product owners, each with their own team of developers.

Double up

More often than not, one team would adapt and rebuild for their platform, whatever was successful on the other platform.
In short, the situation was double of everything: people, concepts, tests, time, costs, bugs and so on.
The question was, could this legacy situation be in any way rationalised?

Solution

An analysis of both platforms to find the "bits" which were good and the bits which just had to go, those bits which were more of a legacy than anything else. Then those good bits were improved where necessary. Then the magic of modular building: one platform modularly built so that different modules appear for different logged-in users.

Enchiladas

Logged-in users who were professional real estate agents received all the modules, the "whole enchilada". Those users who privately offered real estate received only the basic set of real estate agent modules. Those who were just looking for real estate received the basic set of modules/pages.

Immobilien Scout 24

Challenge

Any big property portal needs to be available on all of the new media channels.
Immobilien Scout was no exception.
The iPad was no exception.
It was well over 18 months since the company's first generation iPhone app for residential property, to which I had contributed and which was hugely successful with around 1 million downloads.

Go with the flow

Could there be an equivalent success for an app which was specially conceived for the iPad?
The company wanted a map-based search which could be augmented with local information and POIs.

Solution

We considered ourselves to be a startup for this app.
I was UX.
There was also a product manager and two developers.
We had a new agile environment at Immobilien Scout.
This app was the first one to be developed inhouse - Immobilien Scout finally had their own iOS developers (all others iOS apps to that date had been outsourced to developers).

Headless chickens

Our little "startup" liked the idea of a minimum viable product.
But that's hard to find and the ensuing confusion is not always helpful.
It it was obvious that the first version could not possibly replicate all functionalities of the iPhone app, nor of the portal.
We agreed what was essential for the first version.
The pieces of the puzzle were a map (maybe even a multi-layered map), a list of results, a detail page for each result and a watch list.
There was an incredible buzz of excitement, it really felt like being in a startup.
Loads of people had loads of ideas.
The developers were chewing at the bit and wanted to start coding immediately.
But I needed to bundle and edit the ideas... and show them the solution.

Speed

The app was conceived in one day.
I placed the list between the map and the detailed page.
The list showed the results on one side and the watched items on the back side.
The iPad's visible area moved like a cut-out over these areas.
It was planned as a very fluid movement.
At the end of the day I had a fully interactive paper prototype.

8 ½ weeks

I tested my prototype with three people.
Three days later, there was a working elementary, interactive app which fetched real, live properties per API from the portal.
The designers were skinning the thing and the developers were updating the first version on an hourly basis.
Almost nine weeks after we started, the first version was available in the app-store.

Immobilien Scout 24

Challenge

Immobilien Scout had identified a new target group: the one-man office, the small business man, the person setting up his own business.
The type of property search that happens overtly on the high street.
The company wished to reach out to those newly found users with an iPhone app.
The starting point was the hugely successful first generation iPhone app for residential property.
The question was, should we rebuild it but with different property attributes?
Or had the time come for a second generation app?

Solution

It became apparent very quickly that this app should look so much better and be able to do so many more things than the first generation iPhone app for residential property.
This app should transport the brand, it should save searches, save favourite places, measure loudness, calculate how big a café needs to be for 20 guests and so on.
It became equally apparent that the previously used and conventional tab navigation wouldn't scale.

Grids and conventions

We decided to go with a grid structure which was unconventional in the app world.
Branding and marketing were heavily involved.
To maximaise the available screen space I appealed for a clever and innovative combination of page name and view change (switching between list view and map view).
Sadly, I was not convincing enough.
Almost inevitably, not all functionalities made it into the app in the end.
But I am glad to say that this app was the last app that Immobilien Scout outsourced to developers.

Immobilien Scout 24

Challenge

The central sign-on page for Immobilien Scout should be clear, focused and transport the brand.
It did not fullfill any of those requirements.
Several different sites required their users to log-on using the central sign-on page.
Was there any way to create a clean solution?

Solution

After a quick analysis, it became clear that almost all traffic (more than 95%) came from the portal.
I aimed for the lowest common denominater.
I tried to remove disruptive elements and reduce disorientation.
I removed all the superfluous stuff.
I made sure that the logo and the claim sit in the same place with no disturbing jumping.
This was a case where Mies van der Rohe's famous quote "less is more" could be used.

Immobilien Scout 24

Challenge

The FAQ section of Immobilien Scout's portal was so old it wasn't even web 1.0.
It had never been updated.
It also seemed that it had never been visited.
The department for customer support dealt with all questions personally: they answered calls and they wrote eMails.
Customer support had their own list of typical questions and standard answers.

Too many questions

Unfortunately, they were overwhelmed by the abundance of customer questions.
They needed to drastically cut down the number of eMails.
Mostly, they were asked about billing issues.
The number of phone calls was less of a problem: if a line was engaged the customer had to wait.
The questions was, how to get all of that FAQ knowledge available and findable on the website.

Solution

I gathered all of the available questions and answers from customer support's list.
I grouped them into categories and sub-categories.
I used a quick and dirty version of card-sorting (User Research explained the basic principles).
Then I sketched the solution on a white board.
A designer finished a styleguide conform layout and front-end built the xhtml-prototype.
It went live two months later.

Immobilien Scout 24

Challenge

Searching for a property is an activity that takes quite some time.
Over time, most people refine their searches down to one or two or maybe even three searches.
They then repeat those searches until they buy or rent.
The question was, was there a "sexy" way to show recent searches?

Solution

The first thing I did was to confirm my mental model of searching.
Step one in any search is always criteria, step two is always results and step three is always a detail page.
As a consequence, "recent searches" needed to be placed on the page where the criteria is entered.
The second thing I did was to raise the question of synchronisation: if a user searches on his PC at work and later on his PC at home, not to mention his iPhone, should he see the same "recent searches" on all of them.
He expects to.
In order to do this, I proposed saving and synching the last five searches that a user performs, automatically.

Immobilien Scout 24

Challenge

The challenge was tricky: would it be possible for me to digitalise my interface design knowledge so that all the UX-Leads could have access to it.
Pattern libraries are all the rage.
It seems that Immobilien Scout also wanted to have one.
The question was, how?

Solution

Doubt overcame me.
I asked myself, would I turn to a library when faced with an interaction challenge.
The answer was a resounding no.
As an architect I have learned many governing principles of design, gestalt & interaction, which I can apply to any problem.
So I sketched and prototyped in Axure my version of an interaction pattern library.

User needs

As expected in user centered design, I turned to the users for their opinion, in this case my UX-Leads.
The answer was a resounding thanks, but no thanks.
I decided to drop the project.
Why build a library that no-one visits?
Maybe another day.

Don't mention yahoo

More out of curiosity than anything else, I visited quite a few online pattern libraries, including the meanwhile very famous yahoo pattern library.
It was originally made by developers for developers.
It spits out snippets of code.
These prefabricated blocks of code make me think that the developers who started yahoo's pattern library simply didn't understand what Christopher Alexander meant with his guiding principles in "A Pattern Language".
At no point in his book, does Alexander say "this is the solution".
He does, however, elaborate his principles and uses examples to demonstrate his principles in action.

Generation copy and paste

But in every library I found pre-defined solutions to problems, I hardly ever found principles.
Or more correctly, I found examples of successful solutions to specific contextual problems - many of which were copies of copies.
Unfortunately, too many members of Generation Copy and Paste (Alex B.'s own term) are unable to distinguish between successful solutions and failures.
Inevitably, there is a proliferation of poor libraries.
And so the triumph of poor solutions continues.
Still today, I don't know why a thinking designer requires an interaction pattern library with prefabricated solutions.

EDIT: Two years after I wrote this, some smart people at boxes and arrows confirmed my view and wrote an article, saying that "design patterns do not support how UX teams actually work".

Immobilien Scout 24

Challenge

Like many advertising portals, Immobilien Scout offed the possibility of purchasing on-top products to their advertisers.
These on-top products improve visibility, which in turn reduces the time to purchase or rental of a property.
For most real estate agents that means a shorter time before they receive their commision.
Such on-top products seem like a good idea.
Unfortunately, they were more-or-less unbookable online.
My job was to make them bookable online.

Solution

An expert review (aka heuristical evaluation) was the first thing.
I understood very quickly why very few people booked online.
It was a labyrinth of clicks and mis-clicks and confusion.
Even I was frustrated and I was only reviewing it.
It was a case of making the user do the work.
I had to change it.

Friction

I prefer the system to do the work and to reduce friction for users.
I wanted to help a purchaser of an on-top product.
The question was, what would make his or her life easy?
It was a relatively simple case of restructuring, clever filtering & matching of properties combined with more than obvious wording on a selection button.

Immobilien Scout 24

Challenge

After the success of the company's first generation iPhone app for residential property, it was time for an app for real estate agents.
It was more wishful thinking than a concrete project.
I was given 3 days to think of something that might be useful to a real estate agent.
A solution for the iPad would be preferred.
The question was, was there a viable product?

Solution

I had the good fortune to talk to a real estate agent who consulted Immobilien Scout.
Through him I learned that the best thing that can happen to a real estate agent is to be involved in a conversation with potential customers.
That way he can find out the true needs of the customer.
And maybe even show suitable properties.
That was the moment where the light over my head went on!

Eureka

What if I allowed the real estate agent to walk around with his portfolio.
What if the portfolio contained every single property he had on offer?
My idea was a visual version of an iPod full of properties, which could be arranged into the equivalent of playlists.
Each "playlist" could be particular types of properties or for specific customers.