How a tap on a “Skip” button killed my dreams… and what happened later.

Here is a story of a failed project.

One time in a company far, far away a group of passionate people decided to add a great feature to their product.

That product just went through a major redesign, and the team behind it deemed it necessary to provide their users with some kind of guidelines on how to get around in a new environment.

To serve that purpose, the team decided to create the most captivating on-boarding experience EVER.

They applied agile principles to their process, or so they thought. They split their work into iterations, estimated their effort in story points, did regular stand ups (same time, same place…you know the drill), even had a nice Jira board to map tasks and their status.

Analysts & PMs gathered market research, designers spent late office hours brainstorming best designs, managers emphasized their great vision and pushed the engineers to write code that would stretch the limits of technology.

After a month the team was almost ready to show its efforts to the world. They just needed to tweak some details, make the infrastructure more stable and get the final “OK” from the CTO.

And then one of the managers jumped in and asked:

• Can we test it first? Can we show it to some users to see how they interact with it?

We felt (surprise, I was on that team too…) like he was that one, mean kid that calls out the teacher and spoils the fun of whole class once they decide to play hooky.

Why waste that precious time? We had done our research already!

But he had the back of our teacher (CTO) and he got his way.

We gathered a group of users and presented them with what we thought was the masterpiece of our life. A series of interactive, beautifully designed animations would take users through a mind blowing, digital journey making them fall in love on the spot with our freshly revamped product…

It was supposed to be that awesome.

And then it happened.

9 out of 10 users decided to close the tutorial after a second or two. Then they would go straight to the main menu and look at us with that puzzled gaze;

“So what is it that you guys wanted to show us exactly?”

These users did not hate the feature, it was much worse than that. They simply ignored it. Almost every one of them.

Our Lead Designer’s face looked like he was just told that his favorite kitten got flattened by a truck. And all of us felt like with each hit of that “Skip” button a part of our soul was taken.

“But the feature is so beautiful! Why??” we asked ourselves in the follow up session, while discussing the results. “Why would almost none of the invited users engage with it?”

Well… maybe, simply, because they did not need it at all.

Later, our follow-up research & customer interaction would reveal that our users preferred to engage in exploratory activities rather than to get our hand-holding treatment.

They were the last ones who would be interested in an animation or interactive video which would tell them “Hey, you can click here, and then here and then the menu opens…”.

The vast majority of them was that type of persona that would toss away instructions booklet when opening a LEGO set, as they loved the thrill of discovering the product on their own.

We wasted a month’s worth of work, but we learned a lot. And it could have been worse, we could’ve wasted another month or even months to finally roll it out live, just to discover the same thing we had learned in that short session. We focused on the software so much that we forgot about the people which that software was supposed to serve.

That story happened a long time ago in a company far, far away. But I always have it in mind, when engaging with our team in the product development process here at tajawal.

It’s easy to fall into that mindtrap, where we think that we know who the users are and what exactly they need. After all, here at tajawal, we are so passionate about travel, so we should be able to relate to our users’ problems right?

Yet, it doesn’t mean that we automatically understand our users’ needs. Discovering that is a continuous effort that has to be an integral part of the software development process (same way as our daily stand ups are or any other activities commonly associated with agile or scrum for that part).

With all these sets of tools we often forget that agile is about mindset, and that this mindset should focus on mainly one thing: how to reduce waste.

And in software engineering — producing something that no one needs is one of the biggest forms of waste. It’s not only misplaced effort but also wasted talent.

So focus on people first, then on your software. Thinking about software makes you think of existing and non-existing features, thinking about users makes you think of real problems & real solutions.

Look into the market, how similar products are being used, and who they address? Look into data, what does it tell you about how your product is being used right now? How does the 80/20 principle apply to your feature set?

But first and foremost look at your users, ideally in a face to face scenario, and see how they interact with your product. What is their experience, is it really what you think it is?

And next time you look at that design, at that concept or that piece of code — think first who and why would use it.

Is it something that will solve someone’s problem and make someone’s life easier?

Or is it yet another “digital masterpiece” that will get killed with one, swift tap on a “Skip” button?