This is one of these days, after a tough meeting with a partner or a customer, when you hear that little inner voice that keeps asking:” Why, for god’s sake, should I have to wake up this morning and get out of the bed”. You thought the job was done, that all was properly set to convince that sharp dressed business man, but it seems that you failed. “You know, mr. UX, we’ve have been making some additional tests on our target users, and it seems that your design was too ambitious and just simply don’t work. Thanks for the work, you’ve done so far, but I will ask to my own team to finish the job. You’ve been amazing, very inspiring”. Get back to bed is all you’re asking for.
This is typically the worst fail type you can encounter because it happens during the final meeting. But be comfortable with that: you need to fail because you’re an UX designer and failing is a part of your job (and only a part).
I will not make your application look nice.
Well may be, I will try to, but it is only a small part of the business of the UX designer. We’re not paid to make a stupid app that does nothing (and does that in a weird manner) to look nice, with glamourous icons. We are there to make it runs fine and smoothly, find the exact scenario, the best user context, the pragmatic way of deliver the information, match all that with the identity of the customer, and so on. And if we achieve all of those bullet points, we will ask to our artist to complete the mission, bring it’s own universe, insert his own ideas Inside the project to obtain a nice and polished finish. That’s the role of the UX design process, and most of the fails lies beneath the perception of the customer’s needs, or of the misunderstanding of what is really the real purpose of the UX design duty. If the sharp dressed guy you have on the opposite side of the desk was waiting for a great color set and a new definition of the typography used there, well, he is (and you are) probably partially wrong.
Innovation is failing, failing again, and failing ‘till success.
What is innovation? There’s is a big misunderstanding of what innovation means. Innovation means “Something new introduced”. IN-TRO-DUCED. This has nothing to do with invention, which is an act of pure creation. Innovation is related to your ability to interpret inventions all around you, and use them to create original content. For example, an UX designer will try to implement the touch capacities of modern devices to create new experiences. That is innovation. One cannot ask to an UX designer to create a new pointing device, but to imagine ways to interact with it.
And because we’re walking on a slippery surface (you don’t know how the invention will finally be accepted or why it will be rejected), because you know that you will not have that good idea alone (a lot of competitors are already thinking on the same project), and because your idea does not perfectly match the customer’s specifications (hey, you’re far ahead of what have been already made, aren’t you?), you will experience failure.
For example, Microsoft was very proud to be the first company to release the first PC with a tablet form factor. In 2001, we launched the first Tablet PC product on the markets, with the help of HP. It was the” dreamed of” PC that a user can possibly buy. But, because it was too innovative, the software Inside did not had time to evolve to fit the technology gap (no dedicated apps, no direct touch, partial handwriting recognition…), even if the product, finally, was absolutely gorgeous, at that time. We’ve got a sentence for that, in France that can be translated that way: One is often wrong to be right too soon.
And by default, if you think with disruption in mind, you have great risks to fail, sooner or later. Because it’s the way disruption is made.
See this article for more : http://www.techhive.com/article/113375/article.html
Guidelines that make you fail
As I have been deeply involved in the validation process this year for the french applications on the Microsoft Store, I can easily say that sometimes, too much guidelines lead to uniformity, kill creativity, and finally lead to less fails (well, it was supposed to work that way). But, on the other hand, many guidelines in our spec sheets can easily sink you under waves of misunderstanding. Don’t get me wrong, properly explained, these guidelines are crystal-clear. But a lot of small businesses developers are not fully aware of the Modern UI guidelines, because, they are coming from another ecosystems. Or different platforms. For instance, the semantic zoom, which is, to me, a fabulous innovation, was clearly misunderstood, poorly used, or, most of the time, not used at all.
Fails of yesterday…
…might be the success of today. You can always have a look down to the fails that occur 3/4 years ago and try to convert them in success. The best image that comes to my mind is Aero. Do you remember Windows Vista? I think that we can know consider it as a well-done-semi-fail. It came with blurred and transparent windows and panels, and that was so cool. Until you try to drag and move that window. In spite of the fact that Aero was very dependent on the performances of the graphic board, drain your battery so fast, make your PC so warm it was constantly breathing for fresh air, even in winter, it made all the UX slow. It was a good fail experience, at that time. When I see Apple switching to blurred and semi opaque panels with success, I think each time that IOS 7.*.* is the new Vista (graphically, I mean), without the fail side (with a consequent hardware).
Failing fast to success sooner
Convince that you need to fail, now? Ok, but you do not necessarily need to fail on the last obstacle. To say that differently, you have to fail on the early stages, to success later on. This is where the UX process gives you tools and processes to fail soon. Prototyping for example, is a good way to fail, fail, fail again and fail once more to finally success. While iterating with your Partner, on wireframes, trying to figure out how make that application work, is a process of failure, until both of you and your partner give mutual agreement.
User interviews, A/B testing, trying to be always explicit, mockups, iteration, 5 whys, personas, focus groups, Fly on the wall method, all those things are to me failing machines that helps you decide what to keep and what to trash.
Typically, you can learn over the internet how failing soon was the key to the success of the Xbox One controller. Hundreds of mockup had been realized to finalize the concept: Integration of a touchpad, speakers, even smell emitters! Failing during these integrations results in a great, cheaper, heavy duty straightforward controller. And even after getting rid of those useless specifications, there were numerous attempts to obtain the perfect gamepad, just by moving the buttons, the grips, the handles, and so on.
Involve your Partner/Customer at the very beginning of the project. First, you will fail together and share the weight, and as he has the best role to define its own job, he surely can bring answers that are out of your sight. Plus, it can build strong relationship to work on a tricky problem, and you may even take an advantage in telling the whole story in some conferences.
Practice multi-disciplinary yoga. Play games, go to the local museum, read technical briefs, draw something, whatever that opens your field of view. A closed dead end can often be opened by something you had recently read, or seen. Practice TTT (time to think), an open hour subject you decide to work on. Something very different from the apps you’re stuck into.
It is always hard to point the finger on failures from our ecosystem, because these guys are really close to us, sometimes became friends. And in fact, all these guys really know how it works. They simply fail on a specific topics, or on a tiny part of the application. I launch every single day the Kindle Modern App on my Windows 8.1 device. Great app, very light, clean, very close to the one hosted on the Apple Store. Perfect. Except the way you turn the pages. Simply no feedbacks. No animations, no changes at all, except the text itself. Ok, Modern UI is explicitly anti-skeuomorphic, and we don’t need a realistic page turning from the right side to the left side. No. Only a little slide effect, during half a second should be fine, just to improve the confidence of the user. How many times did I read the first sentence of the page and asked myself if I did not have already read that sentence?
Another fail? The new paradigms of the search function in Windows 8. It was brilliant. You were able to search through all the apps installed on your system, whatever was the query you were typing. For instance, if I typed “Hangover” in the centralized search box of the Windows 8 Charm bar, I could search for that query inside the Bing App, the IMDB database, or inside some dictionary app. It was gorgeous. But it fails. Due to the complexity to discover the action (find the charm bar, find the button, click on it, input your query, browse through the apps to find the one that matches with your query, and so on…), because of the disturbing centralized-multi-app paradigm, it was not used at all. We fail to implement a good idea. And we decided to put the search function back to where it belongs (and where people find it), in the layout of the applications.
There are so many good applications with no UX weak points. I personally love Cocktail flow, for the concept, the functionalities, and the overall look & feel. The first version of the app was great but there were some tiny mistakes on how was organized the information flow inside the product page. The second version (interesting concept here: versioning means failing ‘till you succeed?) is much more mature, clean and useful. It tells a great story with fantastic graphics.
I love the BNP Paribas application for Windows Phone, because it’s fresh (for a bank app it’s very fresh), it’s “gamified”, never boring, smoothly animated, colorful, practical, clear & clean, well branded, plus it has a demo mode. I’ve been seeing so many bank apps that were just a sum of several boring charts. Failing is learning and I’m pretty sure that the fail of your competitor boost your capacity to success, if you analyze accurately the reasons of the fail.
Failing is a story you can never be far away of for too long, in UX process. Failing is the way to learn, to innovate, to grow up and to success. How many time did you fall prior to stand on your legs? How many times did you redo the same boss, at the end of that game, again and again, until you finally find out the weak point and get rid of the villain? Same thing for UX design. By failing, you question the usage, the audience, the device, and the job of your app, until you find the right answer. Consider failing as an opportunity to experiment something really new. And, of course, always aim to success.