In the previous section a bunch of stuff happened. The world got created, Adam and Eve misbehaved and got banished from the Garden of Eden, Cain misbehaved and got cursed, the whole of humanity misbehaved and got doomed. Except for Noah, that is. Today’s section takes it from there.
Noah receives detailed specifications for the construction of the Ark.
As soon as Noah receives the specs, he immediately gets to work. He doesn’t ask any questions, doesn’t doubt the instructions given to him, follows them blindly. Well, to be honest, it doesn’t look like he was in a position to challenge any of the client’s assumptions, but that’s usually not the case for us UX folks. We often get thinly veiled solutions under the pretense of requirements: “this page should have a large heading at the top, with a dropdown under it and then some checkboxes and a button”. If our job boils down to more than just converting text into wireframes, which are then to be nicely filled in by an equally mechanistic designer and to be taken as a vague recommendation by the developers, we need to understand the real need behind these requirements. What’s the use case they aim to solve, who is the user, what is she trying to achieve, and might there be a better solution.
One way to dive deeper is requesting that stakeholders provide detailed textual requirements rather than UX sketches (either visual or disguised as text). However, this may be a bigger request than it seems to be, because they’re also spending their days up to their necks in UI — so expressing themselves in these terms comes very naturally for them. We are basically asking them to reverse engineer the interface that they have in their minds, and write it down in the form requirements — instead of us doing so. More often than not, it’s a good idea for us to do it together with them, going through their sketches and figuring out the assumptions and requirements behind each element. This is a great way to facilitate a conversation around the product, uncovering the insights between the controls and enabling us to understand the requirement more profoundly than it would be possible with a dry bullet list.
Had Noah’s client been someone less… ahem… shall we say “authoritarian”, Noah could have employed different techniques for a deeper dive into the requirement, including the wonderful “The Five Whys” method.
Noah constructs the Ark.
Estimations of the time it took to complete the Ark vary between 75 to 120 years. Somewhat prophetically, it seems that Noah is working using the Waterfall methodology. I hope you appreciate the irony. It was probably lost on him. “Waterfall” was the classical approach to product development methodology, which means that first you do all your research, then all your planning down to a tee, then you develop, and then you launch. This methodology was used from Noah’s times and up to the beginning of the century, and its main problems were that it generated products which became outdated immediately upon launch, which came after years of development, during which time there was zero income for the company, zero value for customers, and zero feedback from the field.
As the pace of change grew, the need to stay responsive to the market became more and more critical, until the need had been recognized for a major change in the entire methodology. In 2001, the Agile approach came into being, advocating the development of small, meaningful features in short and frequent iterations, leading to continuous delivery. Under the Agile ideal, the feature is launched as soon as it’s developed, which serves the customer by providing value from the initial stages of development, and also serves the product by providing usage data, user feedback and sometimes a cash flow from the get go.
In Noah’s terms this would mean building a small raft, then some sort of rowboat, then a sailboat, and in this fashion he’d slowly build his way through to the ark. Of course, this doesn’t really work for boats (nor for every type of software), so he is pretty lucky that his client knew exactly what he wants and when he wants it by, and he could give Noah an early enough start to get everything done in time.
The subject of incorporating UX teams in agile processes is a challenging one, because it dictates a pace and mode of work very different from what’s considered ideal to the UX practice. The whole planning phase becomes much less rigorous, and the delivery is more hurried. The upside is that the feedback comes in as soon as the first features are out, which is priceless. Much has been said about how UX and Agile plays together, with the same typical conclusion — UX needs to be an organic part of the development team, to be ahead of the development by one or two iterations, and to adopt quick, effective and less rigid research methodologies, an approach known as Guerrilla Research. We’ll get a glimpse of this a bit further down.
The Flood covers the world. Once the rain stops, Noah begins sending out birds in order to understand when is there enough dry land to let him disembArk.
See, instead of continuously launching expeditions to explore the seas looking for land, Noah found a very quick (agile) and a highly effective way to perform the test, utilizing his available limited resources. This also let him run several tests in a row at a low cost. This is the essence of Guerrilla Testing — running very quick and focused tests, like reaching out to a colleague across the aisle or approaching someone at a coffee shop down the street and asking for feedback. We’ll get back to this in more detail in a few weeks.
As Noah disembarks, he offers sacrifice to God. God accepts it, promises that there won’t be another Flood, and as a token of this promise creates the Rainbow.
We have some great mutual feedback here. Noah shows God that he remembers what kind of behavior caused the Flood, and promises to behave from now on. He basically accept the Terms and Conditions of the new, damp world he had just been handed. God also makes a promise to Noah, but he is well aware of the limitations of human memory, so he knows that when dealing with important information, it’s not enough to inform the user of this once — rather, a recurring indication needs to be used as a reminder. It is also important for the indication to stand out and attract attention if we want it to be noticed and processed. Hence — the rainbow, very pretty, hard to miss, the wowest of all wow effects.
Noah gets drunk. His son Ham performs a shameful act towards him (this is not the reason why Jews avoid ham though). His other sons Shem and Japheth enter the tent backwards so as not to see their father’s nakedness, and cover him up.
Ham’s actions beg the discussion of Ethics in UX, but we’ll have plenty of opportunities to discuss this one in upcoming chapters. For now, I’d like to focus on Shem and Japheth’s actions. They enter the tent blindly, going backwards, relying on their senses of touch and of hearing (and possibly that of smell, given Noah’s state).
People new to UX are often surprised by the multitude of non-graphical interfaces out there. But before the first GUI (Graphical User Interface) had been invented at Xerox PARC labs in 1973, command-line interfaces ruled the world. You can still encounter them if you know where to look — and I’m not referring to some backwards industry that hasn’t caught up with the times. CLI users are often zealously dedicated to them, because they offer a degree of efficiency and flexibility unparalleled by any GUI. This comes at the great price of much higher cognitive load, a learning curve that is actually a cliff, extensive reliance on long-term memory, and stretching the working memory to its limits. And no shiny pixels!
The CLI’s little and unexpected brother was born a few years ago in the form of chatbots — virtual representatives on various websites, and Facebook and Slack bots, among others. They’re much easier to use than a full-blown CLI, and they’re very limited accordingly.
The second major type of non-graphical interfaces are voice interfaces — Apple’s Siri, Amazon’s Alexa, Microsoft’s Cortana and Google’s Assistant are the most famous examples. They can all speak to the user and perform her requests at a varying level of success.
People are often puzzled by the claim that this has to do with UX — “what’s to design there, if there are no screens involved?”. Well, in terms of UX Design the work is not all that different. The research is exactly the same, the cognitive limitations are still there, you still have personas, user journeys and use cases, the Information Architecture follows the same rules, and you still need to define every little thing the users encounter. It just happens not to be visual. Of course, each platform has its own nuances — but this is also the case when discussing iOS vs Android, OSX vs Windows, or web vs mobile vs desktop. It’s the same job, with some platform-based adjustments.
For a while after Noah’s passing humankind lives in peace and harmony so complete that they decide to build a tower to reach all the way up to the skies — the Tower of Babel. God doesn’t appreciate this and mixes up their languages so they can’t understand one another, so the project fails.
Standards, conventions, common patterns. Isn’t it great when everybody speaks the same language? We can achieve incredible things. Except it never happens. Sometimes it feels like things are finally settling down and we can get to achieving all them incredible things, but then some sort of a technological breakthrough occurs and hundreds of thousands of coders all around the world swoop in on the new technology, everyone trying to beat the rest of the world to the punch. Since the playground is brand new and uncharted, everyone does everything slightly differently than everyone else, and we become flooded (no pun intended) by noticeably different solutions to the same few problems. Natural selection runs its course over the next decade or so, until we arrive at a few basic paradigms covering 80% of the market — and this usually happens just in time for the next disruptive breakthrough, and there we go into a new spin. We’ve seen this at the dawn of the personal computing era, then (at its worst) at the early days of the internet, Web 2.0 was quite entertaining, then the first open platforms on Mobile, and we can see it happening before our eyes today with AR/VR/Voice/Chat interfaces. In the meantime, this chart shows all the different Android devices present on the market, with their market shares. If you wanted to develop an Android app that works for all Android users — you’d have to support each box in the chart. And this is within one operating system!
Can Abraham recognize a good Call To Action when he hears one? Which mental model will the Egyptians develop? Do you need flexibility to make babies? How do you handle edge cases that are dangerously close to the edge? All this and more — in next week’s episode. Follow to stay tuned!
Source link https://uxplanet.org/the-ux-of-the-bible-chapter-2-noach-287005f3bb5b?source=rss—-819cc2aaeee0—4