The 3 symptoms of a Mickey Mouse project

With DO’s and DON’Ts

A “Mickey Mouse project” in our team became the slang for projects where many aspects just don’t “make sense”. While there can be many levels of “Mickey Mouseness” in a project I’ll give it an UX-twist here in this post.
When I started working in the public sector – the IT department to be precise – 12 years ago, the user was this famous “problem between the chair and the keyboard” – this annoying person calling the help desk with “hilarious” problems and being told to “create a ticket” or “introduce a change request”.

Like Alice in Wonderland I was discovering strange creatures of huge and complex projects under every tree.

These projects had big teams, steering boards, their own language with lots of acronyms and many many many meetings… They all had good reasons why things worked as they did, often times because of a long history behind and the multitude of stakeholders involved.

The more time passed, the more difficult it was to explain “why are we doing it this way” and “why are we doing it” at all.
Besides the inexplicable user interfaces with “parents” and “children” fields which made me flip through a 50-page-long user manual to understand how you can just do the thing you need to do, there were other questions that needed an answer:

Why do we need a 2-day training to use an interface?
Why do we have a separate portal for suppliers and customers with a totally different design and structure, managed by two different teams?
Why do we believe that some abstract people we never talked to will just download this software and use it?
What is it that our users don’t understand and what are we doing about it?…

The list is long but if I have to choose looking at it from a UX perspective, Mickey Mouse projects share at least 3 common features. The good news is that these issues can be fixed if you give them the attention they deserve.

1. Who asked for it?

Or in other words “Whose life are we improving and how?”…
In the public sector, projects often arise from a political agenda, a program backed by a regulation, some kind of rationalisation strategy… None of these are coming straight from a real user and an explicit need. Hence the exercise that we often need to do is to find these people who use our product and talk to them. They are the ones who can tell us and show us how our product is helping them with their tasks.

In the public sector we generally love open source. As we also like to share what we develop with the EU Member States, we published the code of our electronic invoicing software, hoping that the countries will download it and use it too. Despite of our communication efforts for years, the page was still showing 0 downloads… Why? Reasons can be many, however it would have helped if we only knew who our potential users were and talked to them. It would have gotten us closer to understanding if they needed such a software and if yes, what they needed to start using it.

DO’s

User research to understand your user – how they work, what devices they use, what is important for them, what their pain points are…
Formulate needs, your lean (quick) personas and put them in the center of your work.

DON’Ts

Assume that you know your users and what they need. Project leaders are often surprised how many things they learn in a (properly conducted) user interview.
Ask your users what they want. They will often have good or bad ideas for how to solve their problem, but usually they are not designers and what they can describe best is their pain point, not how to fix it.

2. How do we know we have succeeded?

Do we measure success and and how says a lot about a project. If it doesn’t show an obvious link with our user’s needs, does it take us closer to where we want to go? But where do we want to be? What is the outcome we want to achieve?…

Colleagues have nightmares when they hear “KPIs” and one of the reasons is that it usually involves heavy reporting and all this work is not gratifying, because they don’t see a direct benefit or impact. This is because their KPIs look like any other project’s KPIs such as “number of users”, “number of downloads”, “number of comments”, “number of attendees”. All these numbers end up in a report and very often… that’s the end. No wonder everyone hates reporting just for the sake of reporting (also true for reading those reports).

DO’s

I learned a very simple yet powerful framework at the UXLX conference (my favorite UX event) of defining meaningful metrics. It is starting from finding the meaning by linking “people-problem-solution” – choosing your focus, identifying your users and a key use, i.e. what will they be able to do when they are using the product, that they couldn’t do before. This is a good basis for establishing a key metric – what will tell us if the solution really works.
Track over time and tell the story.

DON’Ts

Start with “what can we measure?” but with “what metrics will tell us if we succeeded?”. It sounds obvious but this is often they way we end up by doing it. It’s better to have few meaningful metrics than a long list of generic ones.
Be afraid to question and review your success metrics because some of them might not make sense anymore and some others deserve their place on the list.
Do nothing with the reports. The results might lead to a fruitful workshop with your users, to redefining priorities or to start a new project of improving an aspect of your product or service.

3. Can we admit that we failed and that now it’s time to pivot?

If the answer is always “no” then you might be seeing Mickey’s ears showing on the horizon. Sometimes projects are in the Never-fail-land because they are “too big to fail”. Others because they don’t know that they failed (hence it’s important to set point 2 right). Even if we don’t have a “failure” as such on our hands, questioning things and keeping an open mind is a healthy practice. It can help us get much better if we just admit what doesn’t work and take another direction.

My organisation decided to create an innovation lab. We had no idea how to go about it so we decided to learn first from the best. We interviewed labs from big organisations such as MIT, the World bank, the French Government… Our interview with MindLab was particularly insightful. Thomas Prehn, its former director, shared some thoughts about failure(1). For him failure is giving up a project. All problems have a solution, even if it’s not the best one. As long as you are working with real needs and not starting with solutions. The question is “Are we really working with the right problem?”

DO’s

Before something becomes too big to fail, using prototyping might help to understand quickly if you are on the right track of answering your users’ need.
A prototype can be “quick and dirty” like a simple sketch or storyboard – just enough to validate some assumptions with a small group of your users. What is beautiful is that you can prototype anything – it can be just a small new functionality of your software. Scrapping an idea on a piece of paper feels much safer than scrapping a whole new development.
Plan the “questioning” part. Even if complete pivot, i.e. change of direction, is not necessary, what could be useful is to set “stop and reflect” milestones that open the door for sometimes bold decisions. This can be an opportunity for a cool rebranding or a “spin-off” project to emerge from the ashes (after all, without The Bachelor, we wouldn’t have had The Bachelorette).

DON’Ts

Hide your head in the sand and stick to the initial plan no matter what. Sometimes you need a “sense and respond” strategy, i.e. agility to set a direction and let solutions emerge, rather than follow the initial recipe, where at some point we will have to admit that people found too salty.

These three points of attention are simply some thoughts about how to make our projects better from a user perspective (and beyond), based on experience in my context of work and my sources of inspiration. There are many more out there and I would be happy to read your thoughts on this. What are your top tips?

My sources of inspiration on this topic:

The Lean Startup by Eric Ries
UXPodcast hosted by James Royal-Lawson and Per Axbom
Various talks and workshops from UXLX Lisbon