business – Eran Dror

Apple: Forget Skeuomorphism, Bring Back Some Physicality!

(Originally published on Quora on September 20th, 2013)

A lot has been written about skeuomorphism, the idea that digital objects should look like their physical counterparts. Speculation went wild from the day that Jony Ive, Apple’s former head of industrial design, had taken the helm for software design as well after the letting go of Scott Forstall.

Steve Jobs, the rumors said, was an advocate of skeuomorphism, and so was Forstall. But Ive was a famous objector, and had many supporters within the Apple design team. On its face, skeuomorphism sounds ridiculous: why must a digital calendar, a thing far more complex and flexible than a paper calendar, be made to look like its inferior progenitor? Why must we have leather, and stitches, and yellowing paper texture in our modern, digital note taking app? In the early days of mobile computing, these things may have made some sense, to help train a generation of new users. But are they still necessary today?

There is a lot to like about the recent release of iOS 7. New features, and new design elements that make users lives easier. But one thing that seems evident is that Apple has taken the backlash against skeuomorphism a couple steps too far. iOS 7 does away not only with skeuomorphism, but with a lot of physicality per se. Buttons no longer look like you can press them. Icons are flat and cast no shadow. Toolbars are flat, and practically indistinguishable from the content below, and folders do not look like containers anymore. It’s true that some new physical behaviors have been added, like the frosted glass effect in the notification center, or the great new way to flipping through open apps. But for the most part, elements have become more abstract, less substantial, harder to separate from their background, and therefore – less “real”.

Physicality, the idea that digital objects should have physical characteristics so that they can be interacted with physically, is older than even the Graphic User Interface. Text cursors had geographical positions on the screen. Then graphics came, and with it, the concepts of background and foreground and various windows and menus that could be layered on top of each other, like physical objects. Drag and drop was introduced to mimic the way we manipulate objects in real life, and as soon as our screens were good enough, toolbars and buttons started employing shading and color to mimic volume and three dimensionality, and help users quickly make sense of a screen as if it were a topographical model.

When touch interfaces hit the mainstream with the iPhone, a new level of physicality was reached. Icons were made three-dimensional, to convey that they are for tapping. Toolbars were shaded and gradated to give them the illusion of volume so that they were easy to separate from the content, alert dialogs had a unique texture, lighting, and they cast a shadow on the content below. Buttons were made in various forms: either as protruding elements on the toolbar, as integral part of the content, or as big, puffy overlays on top of the content to stress an important but temporary selection. All digital objects employed shading, depth perception, volume, texture, three dimensionality, reflexivity, and sometimes even weight to give the user the illusion that they are physical, and thus to subconsciously clue him in on how to manipulate them.

But a lot of this physicality has disappeared with iOS 7. Why? Did the Apple design team simply decide that it had no use for it? Did they have brilliant new ideas that made the old ideas obsolete? Having played with iOS 7 for a day now, and knowing what I know about interface design, I find that hard to believe.

Physicality is one of the most powerful tools in the UX designer’s arsenal. It is the primary way for a designer to answer the following questions for the user, subconsciously and instantly:

Where does this object end and another begin?
Will it do anything when I tap it, or is it informational only?
Will it scroll away with the rest of the page, or will it stay?
Is it a permanent feature of this screen, or a temporary occurrence?
What should I pay attention to right now?
What part of the screen is normal app content, and what part is an alert intruding from the outside?
What is part of the content and what is part of the controls and navigation?

In the absence of physicality, which subconsciously informs the user on all of these questions, the user must resort to higher level thinking, and to memory (if he has previously used the app.) The designer who gives up physicality, on the other hand, is forced to invent new conventions in the form of color coding, layout conventions, and wording conventions, which the user must memorize in order to use. In other words, rejecting physicality is rejecting one of the principal ways in which a designer can connect an entirely new piece of software to a universe of pre-existing experiences and natural laws that the user had already internalized.

But, is the attack on skeuomorphism per se even warranted? Skeuomorphism may seem dishonest, a fake digital version of a physical product. But so is every graphic interface, or even the basic notion that your computer is displaying objects that can be manipulated. Are those really characters you’re reading on the screen? Or are they a lie, produced by arranging combination of little lights together? Do web pages really exist, or are they mere electrical processes running through wires that are designed to fool us into seeing words and images?

Software is a cognitive creation, much like a novel. And just like objects in a novel, digital objects should look and feel like whatever it is that helps human beings understand and interact with them. They have no other purpose that can determine a more “honest” form. Viewed from that perspective, skeuomorphism isn’t a lie: it’s a metaphor. A metaphor that helps us interact with an object that has no independent existence, and no independent qualities. It’s not as critical as physicality but it is, sometimes, a good idea.

Physicality, on the other hand, is at the very heart of computing. It is the future of computing. It’s important that Apple does not throw this baby with some of the more cheesy skeuomorphic bathwater.

Low-Bandwidth Teams: Remaining Human from Afar

The past twenty years have seen a rampant increase in what I call Low Bandwidth Relationships: Work or personal relationships that are based around video, audio, or textual communication with little or no face to face interaction. If in the past being remote meant that you couldn’t communicate very much at all, we now have emails, texts, instant messaging, group chats, social networking, and video conferencing tools that account for a growing percentage of our daily interactions.

These tools have vastly increased our ability to maintain work relationships across vast distances, and have made remote and even completely distributed teams possible. At worst, though, they can mask fundamental failures of communication by providing a very good illusion: Something that looks and feels like communication, but really isn’t.

Body language and facial expression, tone of voice and contextual awareness – even real presence vs. absence indicators are largely missing from our online interactions. As our brain strives to fill in the gaps, we often get a very distorted picture of who our team members are, what challenges they are facing, and what motivates them. Problems can go undetected, misunderstandings can multiply, and projects may even be derailed by miscommunications around priorities, subtleties of meaning, and levels of commitment.

In the past 10 years I have managed a remote team and two distributed teams and had to deal with those challenges first hand. When, not long ago, a friend asked me for advice on a similar situation, I tried to formulate my thoughts on the topic more systematically. Below are some thoughts on how to work remotely with a team while keeping communication real:

Meet First in Real Life – The first few meetings with your team members are a critical period, in which all parties form the basis of their opinions and conceptions. As such, it is quite important that those meetings happen in the most bandwidth-rich environment possible: real life. If at all possible, spend a few days working together with new team members in the same location. Go out to have drinks. Getting to know them as people will form a stable basis on which you can build your remote relationship.

Opt for High Bandwidth – Convenience tends to lure us towards lower-bandwidth communications, but don’t give in! Never send an email when you can gain a fuller understanding via chat. And never do via chat what is better discussed through an audio or video call. Try to hold important discussions in real life, where everybody can have a chance to speak and be fully understood.

Value Frequency and Consistency – Short, frequent communications are key for keeping teams productive and avoiding bottlenecks and errors of judgment. On the other hand, random interruptions are never good for productivity. For that reason, sticking to a light but routine schedule of communication is best. Knowing that there will be a time to discuss suggestions, air out disagreements, and catch up on developments will promote trust and teamwork, and make everybody more productive.

Seek Out Context – Maintaining awareness of another person’s context becomes much harder when the other person is remote. The flow of information stops as soon as the call stops, and it is therefore easy to fill in the gaps in non productive ways, or worse – forget that the person has an independent existence beyond the span of the call. It is important, therefore, to seek out context. Learn as much as you can about their regular work environment, the type of interruptions they face, and any special circumstances. Ask about people’s mood, plans, and schedule.

Be Mindful of Tone – Textual messages, especially short ones, can often be read in very different ways based on our own personal biases and insecurities. Emotional tone is largely missing from textual messages, and our brain has no choice but to fill in the gaps. The problem occurs when we do so without being aware that we’re doing it. Unless we are mindful, our interpretation gains the power of fact, and this affects our judgment of people’s motivation, commitment, priorities, and attitude. It’s always a good idea to pause and consider whether you might possibly be misreading tone. It’s also important to pay very close attention to tone in your own messages, and try to be sure it comes across clearly.

Make Time for Empathy – Empathy, or our ability to read and emotionally respond to the feelings of others around us, is crucial to building effective teams. Unfortunately for Low-Bandwidth relationships, empathy is often put at risk. It is easier for a manager to expect unreasonable things from tired employees they can’t see. It’s also easier for employees to ascribe insensitivity to a manager that is out of sight, or dealing with faraway, unseen challenges. It’s important therefore to engage empathy actively: talk about your aspirations and frustrations and seek them out in others. It feels more natural when bonding over beers in real life than on an early-morning Skype call. But do it anyway, and you’ll gain valuable insight.

Expect Complexity – We may wish we could reduce the people around us to simple, easy to remember labels – but we can’t. When we are exposed to people’s full human complexity on a daily basis, this fact is easy to remember. In a long term Low-Bandwidth situation, however, people tend to flatten in our minds and become abstractions. A team member who’s demotivated because his priorities are unclear might seem simply lazy. A team member going through tough time at home might suddenly seem flaky for no reason. The truth, however, is that people are enormously complex. The less information flow you have about them on a regular basis, the more likely you are to make grave errors and oversimplifications. If your model of a team member is too simple, it is almost certainly false. When it comes to another person, real understanding is complex, nuanced, and subtle. Seek it out!

When Possible, Move – Low-Bandwidth relationships are no fun. They require more effort, offer less reward, and present more risks than co-located relationships. The ideal solution will always be to co-locate. Co-locating enables you to form personal as well as professional relationships with the people you work with, which will help keep you happy and motivated for longer. It will allow you to create and participate more extensively in team culture, and may help you generate better opportunities down the line.

As new tools evolve and change our ability to communicate, for better or worse, the science of management will have to catch up and account for those changes. Until the science evolves, however, those who work with and manage others remotely must remain mindful of the human implications of the new medium, and struggle to maintain a human attitude and process. It’s important not only for productivity, but also for happiness.

Motivation: Why Talented People Create Bad Products

In my time as product designer, I’ve worked with many startups as they struggled to design and build a brand new product. Some companies get it right early: they build a product that people love, and continue to iterate on it quickly as more and more users join and provide feedback. Others struggle, and throw good money after bad in one redesign after another in an attempt to gain traction, which never comes.

More often than not, the people at these struggling companies are very smart, talented, and well meaning. Yet over time, I began to notice a pattern of thinking, both in myself and in others, that seemed to reliably push teams in one direction or another. The issue turned out to be primarily one of motivation. What motivates a team now seems to me a more basic and more important determinant of their results than talent, experience, or resources.

Specifically, I see these three serious motivational issues professed openly everywhere:

Designers are motivated by the desire to improve people, instead of the desire to satisfy people . This is a subtle difference, but it will often lead in massively different directions in product design. The desire to improve people via product design is understandable, but it is also a very pernicious form of wishful thinking. In truth, as a product designer you must work with how people are, not how you think they should be. There is room for idealism, but it must always be in the form of “People should be able to do X,” not in the form of “People should do X more.”

Designers are motivated by the desire to employ specific technical capabilities, instead of the desire to answer real human needs. Technologies introduce limitations, capabilities, and context for the product designer to work with. But one of the most common mistakes is to allow those technical considerations to become part of your motivation, instead of just a means to an end. Technologies looking for a problem are abound, and some of them sound awfully enticing. (Think of sexy words like Augmented Reality or Social Discovery.) But in the end, products are about people. You must repeatedly return to human beings, their needs and desires. After all – it is much better to solve a big human problem with a very simple technology than to employ the most sophisticated and cool technology to solve a problem that no one has.

Designers care more about some external factor like executive approval, or peer perception, than the benefit and joy that users will derive from the product. Even honest product designers can sometime fall into the trap of designing under an external mandate that has nothing to do with what users want. Specifically, there is a tricky balance to hit between the product designer’s job of figuring out the truth of human pain and desire, and the ultimate product design that must eventually be produced in a complex political and business reality. A good analogy for this would be job searching or apartment hunting: it’s a good practice to figure out what you want before looking at what’s available, because it will help you navigate the numerous options much more effectively. If you start with what’s possible before formulating what you want, you will almost certainly settle for the first thing that “sort of works.” Worse, since in product design you are essentially looking for a job/apartment for someone else, there really is no way to start other than to get a very good clue about what people want.

In the end, there is only one overriding motivation that can help you get it right: you must desire to remove friction from your customers lives. Which means that above all else you must desire to allow them to do more of what they already want to do, and less of what they already don’t want to do. It may not sound like much, but it’s what technology is all about.

Building a Truly Creative Team

There is a complex “chemical reaction” that happens when a group of individuals locks itself in a room and tries to produce something that has never existed before. In most cases, it fails miserably. The results in the end are consistently worse than any individual’s initial ideas. The team is entropic. Instead of working as a harmonious whole, clashes and tensions between individuals produce a mangled product that is nothing less than a physical representation of repression, compromise, and frustration in the creative process. Other teams work harmoniously, having fun and consistently producing results that are better than what any of the individuals could have come up with by themselves.

It’s clear where every team wants to be. The monetary value of a team that can deliver true creative solutions is enormous, and the value in satisfaction and happiness for both the team and the customers is incalculable. So how do you make sure your creative team is smarter than any individual member? How do you build a team that truly works as a cohesive system rather than a tentative truce between opposing forces?

In my work, I’ve seen the creative process collapse when certain elements have been missing. I’ve also seen tremendous outpouring of creative energies and joy when the right balance was struck. I see these elements as critical to success:

Filter Upfront – Only invite people who are talented, highly motivated to do a good job, and have a fairly secure sense of self-worth that will not become threatened by criticism and honest debate, even if it’s quite intense. You want people who are opinionated, and never afraid to speak their mind. On the other hand, don’t let total jerks in either. You want a supportive, enthusiastic, and collaborative environment that spends very little time on either wounded or inflated egos.
Keep the Team Small – The creative team should be small enough so that anybody could feel free to jump into the discussion without having to ask for permission, and without total chaos ensuing. High bandwidth communication tends to break at around 5-10 people. Experiment with what works for you, but for really creative problem solving, I believe it’s important to maintain the team’s ability to have free flowing creative discussions, without overly rigid rules about who speaks when.
Get Enthusiastic Buy-In – Be very clear about goals, and make sure everybody who’s going to participates in the product discussion fully and enthusiastically agrees with the goals, the value hierarchy, and the process. This may involve some long initial discussions, but it’s very important to get this out of the way early so that you don’t waste time on this later. These sort of questions, if you refuse to deal with them early, tend to creep into other discussions and become really pernicious.
Aim for Consensus – Once the team has started dealing with particular problems, features, or products, always aim for consensus. If your team really is composed of smart, creative people who share the same goals – aiming for consensus is the best way to air out any unexplored issues with any of the proposed solutions. Spending the time discussing those issues and trying to resolve them in an elegant way makes 90% of the difference in the product process. Transforming an inevitably mediocre first draft to a brilliant final design often depends on nothing but the manager’s sincere desire for consensus in the braintrust, and the willingness of everyone on the team to spend time in an uncomfortable position of uncertainty.
Allow Complex Positions to Unfold – Behind everyone’s differing positions, opinions, or suggested design is a very complex array of assumptions, opinions, and creative decisions that have to be understood before they can be accepted or rejected. Allowing people enough time to explore and explain those elements is crucial for achieving true consensus. Once you’ve done it enough times, you’ll learn to recognize that different members of the team always see different aspects of the complex problems you’re facing, and that only by exploring all these truths openly can the team agree on the basic elements of the problem and begin to work out a truly elegant solution.
Encourage Mindfulness – Encourage team members to pay close attention to their own reactions, both to the product as it’s evolving and to their own and other people’s position. Encourage team members to speak up the slightest objection, if they believe it is relevant. More than anything, the team should value openness and honesty over repression.
Use Authority as a Last Resort – Very rarely is your authority as the product owner relevant to the discussion at hand. Using authority out of place is the best way to kill the quest for truth that the team has engaged in. It demotivates the people who are primarily in it to solve the problem, and motivates those who are in it for power and external rewards. It also prevents you from finding out the complex truth that invariably lies behind other people’s opinions. Authority should be used only when the team has failed to achieve consensus in a timely fashion, and moving forward is simply more important than discovering the truth on a particular point. Otherwise, your role as the product owner is to decide who is part of the process and who is not, and to set the general direction of the team, then let consensus emerge.
Structure Time – Early in the process, you may need plenty of unstructured, wide-ranging discussions to get everybody excited and on the same page. Once the discussion has naturally shifted towards more concrete solutions and problems, it may be time to start introducing more structure. For instance: people take turns presenting their thoughts and others ask questions. Or – people throw out their ideas on a whiteboard, and then the team does a quick vote to get a read on controversial areas. At any stage in the process, it’s better for the time and place of the meeting to be fixed and predictable, so that people arrive at the meeting with a ready mind.
Let the Process Evolve Organically – At the same time, structure should not be rigid. It’s important again to get buy in from everyone about whatever process you follow. It’s OK to spend some time discussing process adjustments every couple of meetings. The process should evolve organically with the problem. No two processes should be exactly alike in the same way that no two problems or teams are exactly alike.
Balance Alone Time / Group Time – Whenever the team has identified an especially hard challenge or complicated problem, consider assigning it as “homework” for people to try and solve individually in their own time. The next time you meet, comparing everyone’s proposed solutions will introduce plenty of new material to discuss and iron out as a group. As a general rule, I find that alone time is best for solving complex problems, while group time is best for identifying problems, generating creative new ideas, and making critical decisions as a team.

This is by no means a complete list or a final one, but I hope it helps you think about the issues facing your own team, reduce entropy, and allow for true synergy to emerge. Would love to hear your thoughts, especially any additional tips you have for keeping teams creative!

Interface is Everything

If you think the debate over iPhone vs. Android, or Windows vs. Mac is too vitriolic, prepare for the real battles to come. Touch interfaces have removed a psychological and functional barrier, and opened the way to an always-connected, computing in your hand world. This is a major step forward, but as early demonstrations of Google Glasses reveal, computing technology continues to strive for an ever greater and closer integration into our psyche.

That’s interface. And whether it’s touch, gestures, voice, augmented reality glasses, or eventually a direct brain connection, it is going to play a much greater role in our lives in the coming years. Our online data and activities are bound to leak in and eventually fully integrate with our everyday physical existence. Eventually, interface will not only shape how we “use apps” or “surf the web” – it will filter how we view the physical world around us, shape how we make sense of it, drive how we operate in it. Increasingly, the people who shape the interfaces we use shape our lives, and even shape us.

That’s why it’s important to realize that different interfaces are based on different assumptions about the world and the user. Embedded in Apple’s software interface, for example, is the assumption that your experience while using the tool is just as important as what the tool does. Dig deeper, and you’ll see a present-oriented approach. The idea that life is made of a string of “nows”, and that good experiences are therefore the most important thing in life. Embedded in Google’s designs is the idea that new technical capabilities must be available to users as soon as possible, and that over time the right experience will develop. Again, dig deeper and the assumption seems to be that your ability to get a certain result in the future is more important than your experience in the present. Google, in other words, views life as a string of past and future milestones. As long as you hit the right ones, what’s in between matters less.

When buying into a software platform, we should be aware that we are buying into a philosophy of life, and that that philosophy, whether conscious or not, will shape our lives in no small way. When thinking of particular app designs, the assumptions become more concrete. What is the most important thing for us to know in a given situation? What is the most important action we need to take? When and how should we take that action? When is it OK to interrupt us, and who gets to decides that? All of these are interface questions that already shape our lives today.

How much more influential will they become, when software becomes less and less separable from our own psyche?