The project

Eezylife is a London based startup, building a recommender app that’s able to match the user’s personality and current mood with locations and activities around the town. Compared to other City Guides, this app radically limits the number of choices why the user ideally will save a lot of time.

The app follows the assumption that many people are overwhelmed with the multitude of possibilities and therefore have no desire to discover new places or even to completely refrain from going out spontaneously.

Responsibilities

Visual Design, UX support

Including

user flows, high fidelity design and prototyping in an agile context, user interactions and animations, frequent design iterations based on user feedback

Working in FlintoWorking in Flinto

The project is moving agile and lean, I design features in short sprints, create interactive prototypes in flinto or principle and hand them over directly to the product team in London which goes into user testing. Based on user feedback we do up to 5 iteration cycles before the feature finally goes into development. Have a look at one key screen, presenting the best matching venue to the user. After starting with a smaller preview card – almost like a normal chat bubble, that would lead to a secondary detail screen –

we found that the suggestion had to be integrated directly into the chat flow so that if the user liked the venue he’d be just one tap away from adding it to his plan for the evening. 

At the same time, the card had to present the user with sufficient information and multiple actions to validate the decision: check availability via open table, call, get diretions, go to website, visit venue’s instagram (optional). 

Oh my chatbots…

I want to give you a bit of context because chatbots are special. Hearing about chatbots for the first time, I thought it was just another idea to quickly launch new apps with little money. 

You can deliver many features through a chatbot dialog, saving hours of time you’d otherwise need to design a set of usable screens. No need to conceptualize a structured user flow, as long as the user flows with the bot, chatting along while booking flights and shopping for shoes. The problem: Chatbots often are annoying. They fail, they make you try and wait. 

It’s not their fault.

When you look at how chatbots were introduced – as all-knowing FAQ engines — you get the idea of what went wrong. To fulfill that role, an enormous amount of (industry-specific) data and training are needed. And in many cases that didn’t happen. Instead, companies deployed chatbots using off-the-shelf frameworks with built-in Natural Language Processing (NLP) tools, assuming it might be just another small step to add specific needs with some training and a solid data set. However this step is anything but easy or small and companies have underestimated just how much work it is to implement dynamic, useful chatbots.

Users got presented with chatbots that were simply not equipped to deal with the many possible inquiries. When the bot failed, users got frustrated and shifted away.

C’mon, now give it a chance.

However I did not really know a thing about chatbots and how they may become useful some day. What I found intriguing was the idea of a little companion which will learn how to sift through a large amount of data to provide you with the most relevant results.

Because learning works so well through interaction, I figured that an environment of permanent thought-sharing between man and machine would be a good opportunity to train the machine efficiently. So I let myself in on the chat idea and happily started with speech bubbles and input fields.

@