Reworking text-heavy user-generated content
- Text heavy pages (think BBC or NYT or any newspaper)
- Virtually no photos in the content
- Identical visual treatment for 3 different types of content
- 3 types of content where blogs looked like Q&As looked like off-topic discussions
- Huge user base and frequent visits (over 3 million registered users and more than 250k daily visits)
- Massive amount of user-generated content (i.e. blogs posted at a rate of at least 4 per hour, 24/7, and questions asked at a rate of at least 20 per hour) by users of SAP's community who are predominantly tech-savvy
- Identification of and agreement on principal user flows through site (there were three; #1 quickly in & out for questions vs. #2 enough time to dive into a topic for blogs, and vs. #3 time for a distraction in off-topic discussions)
- Identification of items, sections & content types where inconsistancies are most jarring, and usability suffered (low hanging fruit, verified through user feedback)
- Improvement of filtering to allow quick & easy drilling down into huge amounts of content
- Daily changing showcase of content at top of SRPs (automated, obviously) for a more newspaper-ish feel
- Use of colour to differentiate different types of content (think colour-coded sections)
- A clearer text hierarchy within entries
- Creation of a more consistent template for detail pages
- Grouping of related items on each page, and decisive use of white space to let those groups "breath"
- Highlighting of snippets to personalise SRPs and information streams (visual clues for logged-in users to explain why certain content is pushed to them)
Tourists with the best intentions and their holiday perspectives
Get Your Guide
- Tourists struggled to find a suitable activity
- Info & pixel overload on all screen sizes
- Disturbingly high bounce rate
- Endlessly long lists causing fatigue
- Lack of transparency for users
- Filtering accessible but unusable for users
The gory details of the challenge
Things to do on holiday
GetYourGuide is a platform offering various activities for tourists to do on their holidays.
They worked very hard to get tourists onto their website and they listed the activities under cities (e.g. Paris) and, where appropriate, under POIs (e.g. Eiffel Tower) and/or type of activity (e.g. a Segway tour).
Willing but unable
Their SEM was quite sophisticated and they bid cleverly on a PPC basis on specific search terms on Google (e.g. "things to do in Paris" or "tickets for the Eiffel Tower").
Those tourists were looking for things to do on holiday, and were considered to be far along their purchase decision (jargon: they demonstrated high intent).
Although tens of thousands of visitors visited the website each and every day, the bounce rate was way too high at over 54%.
Not very helpful metrics
Everything was tracked that could be tracked and frequent a/b tests were run, yet no one knew why so many visitors were leaving.
Data-driven is not the same as evidence-driven and although large amounts of click data are important, they seldom reveal the why of users' actions.
So why were so many visitors leaving?
- Reduction of elements on all screens
- Clear labelling to increase transparency
- Filters used by system to create lists
- Creation of automatically generated "curated" lists
All the details of the solution
Testing with users
The solution which lead to the high bounce rate was the listing of all activities on a very long page (duh!).
GetYourGuide's algorithm highlighted one activity at the top of the long page with a "Top Pick" label.
Testing made it clear that no visitors knew why GetYourGuide's "Top Pick" was indeed top, exasperated by the fact that it didn't look any different to all the other activities on the page.
As a consequence of the lack of transparency, everyone I interviewed felt they had to look at every single possible activity on that page.
It's all blurry
It turns out that scrolling up and down a long page full of similar looking results requires a great deal of mental effort (jargon: cognitive load) and is hard work for all users, irrespective of their age or savviness with technology & screens.
The key word here is similar.
Where too many things are similar looking, there's a natural tendency to blend all of them into one big blur.
More tests & interviews
Further research, interviewing and tests revealed a consistent need & desire and even a mental model, amongst almost all participants.
Having performed more-or-less all of the research, I was in an advantageous position to suggest a solution.
At first I suggested smarter up-front use of the existing filters.
Then I refined the filter idea further and came up with an automated curated list.
Finding the needle in a haystack
I found some pictures online (cheekily ignoring copyright issues) to demonstrate why similar presentation of similar products means hard work for those viewing the list (jargon: cognitive load).
I talked about signposts… used to help indicate the best way to reach something.
And I presented a reworked page with an automated yet, apparently, curated list which was easy to read, inspiring in its presentation and which was found to be highly positive by all test participants that I tested with.
Talking to real people
A further test round confirmed that I was on my way to cracking the bounce rate problem.
At the time of writing, this brilliant solution for the various landing pages was yet to be implemented.
Shopping cart & checking out with a 6m long steel beam
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.
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?
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!
A behemoth of the steel industry finally enters the online world
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.
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.
The parallel and really very strange world of SEO
Immobilien Scout 24
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.
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.
The mentor and his design olympics are host to too many egos
Immobilien Scout 24
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.
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.
Reserve an online viewing appointment for a place to stay
Immobilien Scout 24
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?
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.
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.
Turning land into property and the ensuing gold rush
Immobilien Scout 24
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.
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.
Global navigation and matching responsive solution
Immobilien Scout 24
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.
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?
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.
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.
Shopping cart for virtual products & checking out
Immobilien Scout 24
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.
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?
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.
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.
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.
Separating siamese twins into a single platform strategy
Immobilien Scout 24
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.
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?
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.
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.
iPad app to search for residential property
Immobilien Scout 24
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.
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).
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.
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.
iPhone app for commercial property
Immobilien Scout 24
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?
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.
Truly single single sign in as centralised service
Immobilien Scout 24
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?
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.
Typical frequently asked questions on any big portal
Immobilien Scout 24
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.
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.
A "sexy" way to show recent searches
Immobilien Scout 24
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?
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.
When interaction pattern libraries are were all the rage
Immobilien Scout 24
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?
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.
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".
Spend more with easy booking of on-top products
Immobilien Scout 24
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.
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.
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.
iPad app as mobile portfolio for real estate agents
Immobilien Scout 24
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?
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!
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.
- © 2011-today
- All rights reserved
- Made with TLC in Berlin