So, you started working and investing your time and money in the application that will eventually help humanity not go extinct. That’s cute. And you already identified some of the most stringent issues: impact of deforestation, saving coral reefs or Adélie penguins. Whatever the issue, you’re very confident you can do it — and that’s great.
But hey! What if you start this potentially humanity oriented application by diving into the development phase and create that fancy My Account page: the magic place where everyone could upload their profile picture, change password or switch the application theme from white to dark. And you have already created the Facebook page for it and re-tweeted some of the @Greenpeace messages.
Just hold your horses.
Regardless of the application you want to build, keep in mind that it needs first to solve a problem. If the application does not solve a problem its chances to survive are close to 0. Through the key experience (Jaime Levy) — or the core interaction — the user is supposed to dive straight into the problem and solve it. The key experience is the single most important reason why someone would chose your application. The reason you’re using Airbnb is to book or rent a convenient place fast; the reason you are using Twitter is to spread the news in an easy-to-digest format; the reason you’re using WhatsApp is to send and receive messages and so on. Whatever the application you might be using on a regular basis, it is for sure solving a problem for you. Again, these applications in turn have multiple capabilities too. But the reason you are using them is not to change the password of the account or customize the cover photo. Those are some nice to have features that complement the key experience.
First, You Validate
Solving a complex problem, requires everyone to get out of the building and do their research. You then need to validate assumptions. You can also employ some nice Design Thinking methods and call on designers’ sensibility to understand users. You also want to get into the build-measure-learn (Eric Ries) loop as soon as possible. Go back, research again, narrow it down and brainstorm a potential solution that will eventually help humanity.
Ain’t nobody got time for that. . — Kimberly “Sweet Brown” Wilkins
Sure, even if you do your job right, there’s no guarantee you’ll succeed. Point is, you still have to do all that (unless you patent a method of solving problems by simply avoiding them).
Law of Triviality
I had never resonated more with a law or a principle, during the last decade to say so, than the law of triviality. This act of wasting time on trivial things has been beautifully documented by C. Northcote Parkinson’s.
In short, when a committee of engineers gather to approve plans for a nuclear power plant, they found themselves talking the majority of time about minor and easy to understand issues, such as what materials and colours to use for the bike shed next to the power plant. The applications of this law in UX process are countless.
“The amount of discussion is inversely proportional to the complexity of the topic that has been around for a long time” — C. Northcote Parkinson
It is in our nature to embrace cognitive ease. We will always prefer to bring into discussion familiar topics. During design meetings, when presented with a complex problem, there’s this general temptation to deviate to more trivial topics. Suddenly everyone gives feedback on colours to be used and everyone becomes subject matter expert in typography. In the end, we postpone the complex things until they get solved by themselves — since that’s how the universe works, right?
Faced with the real issue, teams prefer to start developing, designing, singing, writing poems or any additional things that will give the sensation of moving forward. It is a matter of time until things get fuzzy because of a poorly articulated problem from the beginning. And all you’re left of is a My Account page that will end up in the dark corners of the /failed_projects folder.