Why your startup idea will fail — Design·Develop·Debug
This article is not about design or code. It is about understanding the loop that runs the world of software products — which depends on a harmonious implementation of both. Read on to find out why is it important to understand it at all!
Facebook knows what’s on your mind. Twitter wants to know what’s happening. Probably, Google has already made you feel lucky by telling you that your flight is delayed by an hour — letting you tuck under your warm blanket for an extra hour or spend some extra time in your shower☺.
Information — the currency of the modern age.
Well, there have been more of such “apps”, I am sure, that have had their seeds sown, but were not lucky enough to see the sunshine, probably because of some bug infestation. Wow! how literal that was.
What do you think brought about their fateful episodes? The programmers weren’t competent enough? The designers knew only Photoshop? (or Sketch, don’t want to annoy Mac users). The marketing managers thought, their app was great enough in itself to grow its way into this big notorious world? Not to mention that the night is dark and full of terrors!
I am assuming that all of you who are reading this article right now, have attended at least one (or more) of your history lectures in school. So, you might recall, there was something called the Industrial Revolution that happened in the period from about 1760 to sometime between 1820 and 1840. That, kind of defined how industries (and businesses) should run. Its easier than brewing felix felicis. You get some machines, set up a factory, hire some workers and lo behold — your product is ready! Now sit back and watch it make money for you as it gets distributed to every household. Got a customer complaint? Why bother over some stupid customer who probably doesn’t even know how to tie his shoelaces? Got another complaint? Probably, wait for the wretched customer to curse his life and slit his own throat with the knife that won’t even slice a potato. Got a few more complaints? Well, find out which batch the product was made in and hunt down the worker(s) involved in the malicious act — Fire them! Nobody said they were irreplaceable, given the swelling populations and dwindling jobs.
Every aspect of human life has been touched by this philosophy. So much so, that even the education systems prepare students to become eligible for such kind of work, that is driven by the logic of the industrial revolution. However, times have changed drastically, and so have products and their industries. Perhaps there is no product today that has evaded the kiss of technology.
“It’s cheaper to put an entire microprocessor in your car key, microwave, or cell phone than it is to put in discrete chips and electronic components. Thus, a new technical economy drives the design of the product.”
― Alan Cooper, The Inmates Are Running the Asylum
Most products today have some sort of software involved and most of the functions today in any sector are accomplished using information technology. This has brought in an additional cost of usage of such products — the proficiency in the technical knowhow of the software. It might be argued that training is an inevitable part of any job — operating machines or software.
“Most software is used in a business context, so most victims of bad interaction are paid for their suffering. Their job forces them to use software, so they cannot choose not to use it — they can only tolerate it as well as they can. They are forced to submerge their frustration and to ignore the embarrassment they feel when the software makes them feel stupid.”
― Alan Cooper, The Inmates Are Running the Asylum
However, the disasters of incorrect human-computer interaction have shown us time and again that no amount of training is ever sufficient.
“In September 1997, while conducting fleet maneuvers in the Atlantic, the USS Yorktown, one of the Navy’s new Aegis guided-missile cruisers, stopped dead in the water. A Navy technician, while calibrating an on-board fuel valve, entered a zero into one of the shipboard management computers, a Pentium Pro running Windows NT. The program attempted to divide another number by that zero — a mathematically undefined operation — which resulted in a complete crash of the entire shipboard control system.”
― Alan Cooper, The Inmates Are Running the Asylum
To err is human, to help them is machine!
However, the problem only increases when the hardware or software makes life of the user more difficult, rather than simplifying it.
Let us take an example —
Computer memory works very differently from human memory. That is why you might use a computer (regardless of size, functionally, a mobile phone is also a computer) to store large number of contacts in your Phonebook. However, out of a few hundred or thousand contacts,there will only be a handful of them that you might use frequently. If you had used a manual paper phonebook, perhaps you would have noted them down in a separate page, easily accessible when required. However, the computer doesn’t understand that — all contacts are just bits of data for it in its memory. Now, imagine yourself in an emergency, hunting for your uncle’s number, whose name unluckily starts with an ‘M’. You need to type his name in the search box? What if there isn’t a search feature? You keep scrolling down? What if you are having a really bad day, so much so, that there is more than one contact in your phonebook that matches you uncle’s name?
P.S. Phonebooks these days feature a favourite option on smartphones, which basically shows your most used contacts or chosen contacts on top of the list or in a separate list. Phew!
In terms of technical efficiency, the mobile phone was performing perfectly — it had stored all the contacts you wanted it to remember. It could show you a contact when you requested one. Yet, it was painful to use. You can’t blame the programmers. They did their job correctly! So, what went wrong in the simple system?
“The obnoxious behavior and obscure interaction that software-based products exhibit is institutionalizing what I call “software apartheid”:”
― Alan Cooper, The Inmates Are Running the Asylum
After the above incident, you probably hate your mobile phone. What is the use of such an efficient device if it is so painfully stupid?
“Product successes and failures have shown repeatedly that users don’t care that much about features. Users only care about achieving their goals.”
― Alan Cooper, The Inmates Are Running the Asylum
Enough ramblings. Let’s get serious now.
The world today runs on apps (yes, even your cabs). So, everyone is busy building one! But how do you decide if it is a good app? Obviously, you go by its looks… (come on, it’s human nature)! But over time as you try to build a relationship with it, you realize that you are not made for each other. You get tired of its nagging behaviour (and lagging too, if the programmers worked hard only on the night before release). Finally, you remove it from your device. But you get over it easily and find a new app to suit your purpose. You win anyway! But what about the app makers that made that beauty without brains? They don’t usually get another chance to win your heart back, simply because you are now committed to the next best alternative app, one who understands you and your needs!
Life may give you second chances, users won’t!
Now let us travel back in time and look into the office (even if it exists on clouds) of that app maker — how it all began.
The founder of the company, on one fine night was bit by the entrepreneurial bug, when he realized a problem that he could solve and make money out of it. In no time, he called up his friends and infected them with his idea and motivation (maybe over a couple of beers). They chalked out a beautiful strategy and a pitch to get funding. Now they needed to actually build the app to go with the pitch. So, they decided to start off on it. But one intelligent (well-read) gentleman knew that they first needed to hire a designer to design the app for them. Because, why not? Every good company did that! (and also their pitch read — design centered company). To keep the budget low, they went on Dribble (because Behance is too mainstream) and started looking for “good UI/UX designs” and contacted their designers. The designers were interviewed about their “UI/UX design skills”, “out-of-the-box thinking skills”, “team-working skills” and so on. There were two candidates who were shortlisted. One of them spoke too much about how important it is to do some research to find out what exactly would the users want in the app — what features would be relevant and in what form. When asked about what colour should the app be in, he couldn’t give a definite answer (because he felt it was too early to comment on aesthetics). On the contrary, the second guy calmly listened to their requirements and showed them some cool UI designs (music player UI, with dancing Yoda). He even gave them an estimate of the number of screens that he would need to design to make the app!
Who do you think got hired?
So, the second guy (henceforth called, the designer) began creating wireframes for the app and converted them to stunning mockups — putting every feature that the bosses wanted. However, over a course of time, the designer began to realize that things weren’t making much sense — screens were cramped with features and there was no intuitive flow to the app screens. They didn’t look much good either, because of the clutter— there was no space to accommodate a dancing Yoda. At some points he did try to step up and make a comment on how a particular screen should be organized — but the bosses shushed him saying that if some “XYZ” company could do it that way and succeed, why should they do it differently and fail? When he pointed out that using the app might be difficult to understand for first-time users, the bosses made him design a mock tutorial on “How to use the app”, to be used on first time app launch. The designer did everything that was asked for — because he had no other choice! Still, he was happy, because of the paycheck he received in the end.
You might be wondering, when did the development begin. Well, it began soon after the designer delivered the homescreen mockup. The developers did what they could to keep up with the beauty of the sketch files. But the micro-interactions were too much for them to handle — and they felt they were useless anyway! So, they chucked them from the app. Wherever, it was difficult to code, they used images — because, obviously, the app can’t stop looking good! They kept stitching the screens together, using junk patches wherever required to keep things together. And one fine morning, the app saw the light of the Play Store.
You might be wondering, when did the user testing happen? You mean app testing right? Well, the developers tested the code and made sure it didn’t break. For the app, the bosses tested it on their phones; asked their friends and relatives to do the same. Everyone was so happy at the beautiful product they had created. The app received numerous installs because the people loved how good the “design” was!
But soon after, the company began to get flooded with customer complaints — very few people could figure out how to use the app. Even so, they often hit bottlenecks and the reasons remained a mystery to the users. The rate of uninstalls kept growing, till the point the bosses decided to pull down the shutter and move on to some new idea. A fresh start.
They came, they saw, but they couldn’t conquer…
Every good design of a product — physical or digital — must understand what the user actually needs, not what the makers think the users need. Users are not abstract, their problems are real. The only way to design for them, is to understand them well. Hence, the design should begin with proper user-research and analysis to create user personas who fit the needs. Design is not about making things just look good, because, believe it or not — beauty is skin-deep. One must understand that a good design is about making things functionally beautiful — aesthetics is just mere ornamentation.
Imagine having a computer with the i7 processor and the nVidia Quadro packed in a plastic bag. Would you buy it?
Now imagine having another computer with a sexy cabinet, housing a Pentium 4. Would you buy it?
The problem today is graver today, because, unlike a few decades ago, people think they understand design. “UI/UX”, “User-centered design”, “Design thinking” are often treated as cool buzzwords that make sales pitches sound sassy. It is true that designers should understand what real design is, and trust me, they most often do. But, their ideas and processes are often treated as mere pieces of advice, rather than strict guidelines. Designers are there to understand the needs of your company and that of the people it caters to. It is not wrong to follow trends as long as you understand how it fits into your goals and requirements, but it is a blunder to blindly follow them — based on the success of other companies — because design is contextual.
“Design is not just what it looks like and feels like. Design is how it works.”
— Steve Jobs
In any scenario, design must be the first step for any product. And it should be handled separately from the development, simply to keep it clean from biases — because designers and developers often have different views and mindsets. However, they go hand-in-hand — you don’t design something just because it looks good; you don’t develop something just because it is easier to code!
Also, design is not a static process. It is as much dynamic as programming itself. We have heard developers debugging pieces of code — rectifying mistakes and fixing errors. Well, debugging applies equally to design. Just like development, design too is an iterative process.
If you get a compiler error, you know that your design element doesn’t fit contextually into the scenario. If you a get a logical error, you know that your design process is flawed.
In the world of digital products and services, it is crucial to understand — whether you are an entrepreneur, designer or developer — that both are equally important and have their own overlapping spaces. Understand your space, respect others’ positions and keep the circle going on successfully — Design-Develop-Debug!
Good design is not just seen… It is felt as well!
