// CASE 08 · EFM · MYSPOT

An assistant for the boring part of the working day.

eFM digitises buildings and the services inside them. MySpot was its virtual assistant for the small, recurring, low-value tasks people at work do every day: book a desk, a room, a service. We researched, designed the experience and built the design system.

primary action per screen, by rule

items in the bottom bar, the same on iOS and Android

free-text replies in the chatbot: every answer is a guided choice

style guide with documented code, handed to the developers

01

Executive summary

After a round of qualitative research with the people who would use it, we designed MySpot around one idea: the app should disappear behind the task. Navigation in a bottom bar, content revealed a little at a time through cards, gestures kept to the ones people already know, and a chatbot that never pretends to be human. Every screen has one primary action, placed where the thumb is. The whole thing shipped as a documented design system so eFM could keep building without us.

02

Four phases

➔ Qualitative user research on recurring tasks in smart working

➔ UX design: navigation, content model, conversation design

➔ UI and interaction principles: one action, one finger, familiar gestures

➔ Design system and style guide with code documentation

Tools & tactics

Qualitative research

Conversation design

Mobile UI patterns

Design system documentation

Our app is not the only one on the phone.

It is easier to imitate a familiar behaviour than to teach a new one.

03

Issues discovered

➔ Recurring low-value tasks were scattered across tools, emails and people.

➔ Finding a thing fast was the whole job, and the navigation did not make it fast.

➔ A chatbot with open answers generated errors and frustration.

➔ Empty results left people in front of a blank screen.

➔ Without documentation, every new screen drifted from the last.

Five principles for a workplace app

One primary action per screen

One-finger use, thumb zone first

Reveal a little at a time

The bot is a bot, and says so

Document it or it does not exist

04

Results

eFM got an app experience, a design system and a style guide detailed enough for developers to build from without asking. What I cannot show: adoption numbers inside the client companies stayed with eFM. What went wrong, in a useful way: the guided-only chatbot limits freedom, and we chose that on purpose, because a bot that answers a little worse but always correctly beats one that answers brilliantly one time in three. What stays: it was my first design system delivered as code documentation rather than a Figma file, three years before Ekitai made that the default.

05

Lessons learned

➔ Familiar patterns beat clever ones when the goal is speed

➔ Constrain the bot and you free the user

➔ An empty state is a design decision, not an absence

➔ A design system is finished when the developers stop asking

// Building a workplace app

people should barely notice?

Let's design the flow around the task, not the feature list. Reach out for product design, or book an Ekitai Sprint and get the first screens in five hours.