God tells Abram to move to Canaan.
Get thee out of thy country, and from thy kindred, and come into the land which I shall shew thee. This is one of the earliest examples of a Call to Action (CTA) known to man. Calls to action are ubiquitous in the field of marketing websites and simple apps, where you can be pretty sure why the user entered a specific screen and what do we want her to do next. In the Complex Systems domain, where each screen serves a number of personas and often a number of use cases for each, it’s much more difficult to be able to tell the user “do this and that”.
In addition, historically, the design of complex systems didn’t invest as much in motivating users — because we assume they’re already motivated. They’re there to do their job, they get paid for it, they just want to be done as soon as possible and with as few mistakes as possible. They get in trouble if they don’t deliver. Their compensation may depend on their performance. They’ve got all the reasons in the world to be motivated. The approach was that they actually needed was was help and facilitation, not encouragement.
In recent years this has changed considerably. Firstly, even if the above is true, we still wish to direct them towards certain actions which benefit our business goals, maximize the value they are getting out of our product, or increase our visibility to decision makers. We want their bosses to renew their subscription.
Which brings us to the second reason — the times when the users’ bosses would just inform them of the system that they would be using, are going away. More and more, we see that vendors are being selected from the bottom up, and this is especially noticeable in the tech industry — now it’s the users who are demanding the hottest new tools of their bosses. Accordingly, many of the B2B marketing budgets are now targeted at the users and not just at the decision makers, as they were not so long ago. As sad as it is, the reality is that just until a few years ago we only needed the bosses to like us. As for the users themselves — as long as they didn’t hate us we were good. Well, now the power is with the people and when the decision maker is the one using your product and not the one who only gets a monthly report on it, you really need to convince the user to do stuff. And there’s no better way to do it than a Call to Action. We’ll get back to this in a few weeks.
In the meantime, note the powerful use of the verb. The best Calls to Action, and some say the only true Calls to Action, use verbs — because this is precisely the role verbs play in language and everyday life. Sure, you can label your button “Subscription”, but then your call to action has no action and no calling. If you label it “Subscribe”, you’re on the right track. If you say “Activate your free subscription now”, you may be overdoing it, but it’s a matter of testing. If instead of “Get thee out of thy country” God had said “The land I will shew thee is located west-south-west”, maybe we’d still be in Iraq. It’s not so nice there from what I hear.
Due to the famine in Canaan, Abram and his wife Saray move go Egypt. Abram wants to conceal the fact that they’re married, so they pretend to be brother and sister.
Abram is trying to influence the Egyptians’ mental model — the way that they will perceive his family. He is trying to have them form a mental representation which isn’t accurate, but which serves his goals. This reflects the important distinction that we make between a mental model and a conceptual model. A conceptual model is the way that the product team perceives and builds the product — this is usually the “technically correct” model. We are familiar with the entities that comprise the product, with all their properties, abilities and interconnections. We know where everything is and why, and what’s the most efficient way to do stuff.
The user, on the other hand, knows none of these things. She gets assorted glimpses of the product while working with it, in a unique and often unpredictable order, and she is trying to put all of those pieces together into a single coherent picture. That picture is her mental model of the product. As UXers we try to shape that picture through the interface, and mold so that it will serve the user in the optimal way. We don’t strive to make her understand all of the “real” structure of the product because it includes lots of technical stuff that’s not supposed to be of any concern to her.
For example, the mental model of “how an automobile works” for the typical user is that you pump gas in the appropriate hole, you turn the key in the ignition, and you drive using the steering wheel and the pedals.The car mechanic’s mental model of the same car includes the entire electrical system, the drive system, the steering, the fuel injection, and tons of other stuff I don’t really know, not being of the technical inclination. The car engineer’s mental model goes much deeper and includes parts that the mechanic doesn’t even know about. At least, that’s my mental model of these professions, and I may be wrong.
The problem with the mental model is that it can’t really be described in words, because it’s fluid and ever changing. It exists only in the specific user’s mind and it can’t be extracted and captured — we can only try describing it in some approximation. It also can’t be dictated or designed directly, we can only try affecting it by careful exposure of the interface. A classic example is the email. Its very name is supposed to convey the proper mental model — that of the regular mail, but in a computer. This metaphor works remarkably well, until you get to the “sent items” folder, at which point your grandfather becomes very puzzled by how is it possible that a letter that’s already been sent, is still on your computer. Shouldn’t it have gone somewhere?
Abram is in the ninth decade of his life, but has no children with Saray. She gives him her handmaid Hagar to father a child with.
The name of the game here is flexibility — having several ways to reach important goals. Such as procreation. There is a fine line between flexibility and redundancy. To be more exact, flexibility is good, or “designed” redundancy, where the different ways to perform an action complete each other and make up for each other’s shortcomings. When you have two buttons performing the same action in the same context, or you have the same info provided twice in the same way with no clear added value, you have (bad) redundancy. Beyond wasting real estate and adding visual clutter, it makes the user’s life more difficult because now she is trying to figure out why there’s two buttons, what differences might exist between them, and which she should be using. There’s a very real possibility that the user will simply get stuck on this for a while until she decides to just gamble on one of the buttons and see what happens.
But as long as the differences are clear and each “duplicate” control plays a well-defined role, the system is perceived as being more flexible and supportive of more use cases. To illustrate, Microsoft’s Outlook has three different locations for the Reply, Reply All and Forward actions — once in the main ribbon toolbar (аs part of “the collection of all the possible actions that can be performed on the selected object”), once in the message header (to be as close as possible to where the user’s attention is when she is working with a specific message) and once in the contextual menu (for when the ribbon is minimized or the user is going through a list of emails one by one and doesn’t want to keep going up and down for the ribbon and back to the list). The three instances of the buttons duplicate each other in a useful and complementary way.
God tells Abram to circumcise himself, and the men of his household from now on. Also he renames Abram to Abraham and Sarai to Sarah.
Consistency and edge cases. Abraham got circumcised at the age of 99, the men of his household did this each at his respective age, but all future baby boys need to undergo the delightful procedure at the age of 8 days. A new visual standard is being introduced to an existing, well-established and battle-proven component. This happens. Problem is — the new solution can’t be applied to all of the existing screens, because the effort would be too high. This is the fail point of many alignment and unification initiatives, because the “all or nothing” approach offers decision makers a great opportunity to easily reject UX innovation attempts. In the long run this approach causes much damage and breeds outdated products, held back by this forced alignment to the oldest part in the system. When weighing the pros and the cons of these initiatives, the actual implications of the inconsistency must be examined, without falling back to mere slogans and best practices. Does each inconsistency really hinder the user’s workflow, and by how much. Do the inconsistent parts even share the same users, or are they part of different workflows, so there’s no one to even experience the inconsistency? Might the benefits of the change be worth it?
Another aspect of this episode is a testimony of the importance of microcopy, as God renames Abram to Abraham and Sarai to Sarah. We’ll discuss microcopy in more detail in a few weeks, but for now we have more pressing questions — does Abraham prefer the good of the users or the divine business objectives? Do drawn out UX discussions cost human lives? Does exaggerated consistency lead to incest? Which distress signals are available in the desert? All this and more — in the next chapter. Follow to stay tuned!
Source link https://uxplanet.org/the-ux-of-the-bible-chapter-3-lech-lecha-a049b60d019a?source=rss—-819cc2aaeee0—4