Links and articles about technology, design, and sociology. Written by Rian van der Merwe. Follow @RianVDM
My thanks to Greg Heade for sponsoring Elezea this week to promote his excellent wireframe stencils.
If you use Photoshop, Illustrator, Fireworks or Omnigraffle, you’ll love volume one and volume two of Greg Heade’s tiles for wireframes and flowcharts. These stencils are 100% vector-based and editable, and it allows you to put together page layout and flowcharts quickly so you can focus on adding the details — not drawing the skeleton.
These tiles include standard layouts like home pages, product pages, and error pages, but it goes beyond that to give you a framework for shipping and payment flows. These are an invaluable resource — so check his store out!
I need to tell you about a conversation I had with my 4-year old daughter this morning. You’re going to have to stick with me, because despite the potty talk this is going somewhere, I promise. The backstory is that lately she’s been forgetting to wipe after going to the bathroom (this is the type of stuff you’re here to read, right?). So when she got up this morning, this happened:
Me: “Did you go to the bathroom?”
Me: “Did you wipe?”
Her: “Oh… no. I don’t think so…”
After a few seconds of silence, she said something that’s pretty obvious, but hasn’t occurred to me before as the cause of the problem:
Her: “The toilet paper is behind me so I forget. We should put it in front of me so I can see it.”
Well, of course. Mystery solved. See, a few weeks ago I accidentally broke our toilet roll holder (yes, I’m pretty sure this is the kind of thing you come here to read…), and since then, we’ve been putting the toilet roll on the back of the toilet. And that was the cause of my daughter’s sudden “forgetfulness” in the wiping department.
This immediately made me think of product design, and in particular, the all-important principle of recognition vs. recall:
Showing users things they can recognize improves usability over needing to recall items from scratch because the extra context helps users retrieve information from memory.
It also reminded me of a great story Marco Arment once told in Right versus pragmatic. You should read the whole thing, but the gist is that at a previous job people kept dropping trash at the door before they left the bathroom (what is it with me and bathrooms today?), despite increasingly passive aggressive signs being put up by “management” to please throw trash in the bins. Here’s Marco’s illustration of the problem:
Source: Marco Arment
The solution that worked in the end? Put the trash can by the door. Seems obvious, but it still took them quite a while to figure it out. Instead of trying to change behavior — or to get people to remember to do something they’re not used to — they put a trash can where people are already throwing stuff, and that solved the problem.
Ok, enough with the bathroom examples. I recently had a discussion with a health plan who has a tool for their members to find doctors who are in their network. They mentioned that they get a lot of customer service calls from users who complain that they can’t search by a doctor’s name. This frustrates the health plan because the interface clearly lets you do that. But when you look at the interface you can see why they are having this problem. Here’s the home page:
Can you see where to go to search for a doctor by name? Not sure if you guessed it, but you have to click on the “Advanced Search” link under the Doctors icon:
Here’s the point of all this. Just because a feature is in the interface, it doesn’t mean users will find it. Just because an option is in a menu, it doesn’t mean users will know how to access it. And just because the toilet paper is somewhere in the bathroom, it doesn’t mean my daughter is going to find it.
The lesson is pretty simple, but there are enough everyday examples out there that it’s something we should continue to remind ourselves of. The next time you design an interface, say this to yourself over and over: If I want people to use toilet paper, I should put it where they can see it.
Lauren Chapman Ruiz shares an interesting viewpoint about the role of empathy in design in Inside the Empathy Trap. The issue is that we can’t just have empathy with one person, we need to have an understanding of a wide variety of goals and needs:
When we design, we pursue a broader type of empathy. As a colleague once said to me, designers need to identify with the whole user base. User-centricity is about the ability to recognize that there are a number of personas, each with different goals, desires, challenges, behaviors, and needs. We design for these personas, recognizing that each has different goals they’re trying to accomplish and with different behaviors in how they go about achieving them.
This is another good argument for why personas aren’t dead — they help us to keep our entire target audience in mind without getting overwhelmed.
As usual, Frank Chimero manages to capture what a lot of people in our neck of the woods are thinking in From the Porch to the Street. It’s an interesting, considered lament about how Twitter has changed, but it’s this part in particular that caught my attention:
Have you heard of evaporative social cooling? It says the people who provide the most value to a social group or organization eventually burn out and leave, undermining the stability and progress of the group. Most of my internet friends have been on Twitter since 2008, so they probably fall into this group. How much more is there left to say?
The linked post is Xianhang Zhang’s The Evaporative Cooling Effect, a broad article from 2010 that covers the design flaws in most social platforms. It’s definitely worth reading the whole thing — I’ll just quote this interesting way to classify different online communities:
There are two fundamental patterns of social organization which I term “plaza” and “warrens”. In the plaza design, there is a central plaza which is one contiguous space and every person’s interaction is seen by every other person. In the warren design, the space is broken up into a series of smaller warrens and you can only see the warren you are currently in. There is the possibility of moving into adjacent warrens but it’s difficult to explore far outside of your zone. Plazas grow by becoming larger, warrens grow by adding more warrens.
It feels like Twitter started as a warren and morphed into a plaza, which is where most of the current discontent is coming from — “This isn’t what we signed up for!”
Going even further down the rabbit hole, Zhang links to Eliezer Yudkowsky’s 2007 piece Evaporative Cooling of Group Beliefs, which has some further interesting thoughts on how to create healthy online communities:
My own theory of Internet moderation is that you have to be willing to exclude trolls and spam to get a conversation going. You must even be willing to exclude kindly but technically uninformed folks from technical mailing lists if you want to get any work done. A genuinely open conversation on the Internet degenerates fast.
It’s the articulate trolls that you should be wary of ejecting, on this theory—they serve the hidden function of legitimizing less extreme disagreements. But you should not have so many articulate trolls that they begin arguing with each other, or begin to dominate conversations. If you have one person around who is the famous Guy Who Disagrees With Everything, anyone with a more reasonable, more moderate disagreement won’t look like the sole nail sticking out. This theory of Internet moderation may not have served me too well in practice, so take it with a grain of salt.
On Twitter there is no way to exclude trolls — there are just too many of them. So there is this huge problem that inevitably appears once a community grows sufficiently large:
- Conversation moves from small warrens to large plazas.
- Many people loiter in the plaza and are only there to make trouble and ruin it for the rest of the community, and since it’s a public space there’s no way to chase them away.
- The people who created the original culture of the community leaves, and before long the broken windows theory kicks in and the plaza falls into disrepair.
All this to say that designing effective online communities is much more difficult than it might have appeared at first. We couldn’t see into the future when Twitter became a thing, so who knew what would happen once the growth monster grew too big? It reminds me of Gartner’s 2014 Hype Cycle for Emerging Technologies:
I think we’re firmly in the trough of disillusionment with social platforms like Facebook and Twitter. I think we’ll get through it, but it feels like we’re all waking up right now going, “Wait, that’s what this has become?” We can — and will — do better. But it’s going to take time.
I was a little reluctant to click on Greg Satell’s How Wells Fargo Learned To Innovate Around the Customer. First, it’s on Forbes, which has become virtually impossible to read on mobile devices because there’s so much blegh on the page that’s not related to the article. Second, whenever you see people talking about “The Customer”, you should be sceptical. There is no average “user” or “customer”, so this kind of thinking usually results in defining an impossibe target market:
Image source: Tom Fishburne.
That said, despite my fears, the article is quite good. It discusses how Wells Fargo uses ethnography in their business, and there are also signs that they don’t operate like a large, slow-moving corporation at all:
However, it is not just internal processes that have changed, but the culture as well. Ellis’s bankers don’t sit in cozy offices, quietly examining financial statements (nor does Ellis himself), but work in open cubicles designed to promote collaboration. They are constantly iterating, experimenting and testing.
This part, especially, surprised me:
Perhaps most importantly, they are not limited by a long range plan. There is no “five year death march” toward a transformation that will never happen—or be outdated by the time it does. Instead, their purpose is to improve their customers’ businesses and adapt quickly to shifts in technology and the marketplace.
I’d love to see more detail on how Wells Fargo remains lean despite being such a large company. If this is really how they operate, it’s encouraging proof that big doesn’t have to equal slow and tired.
Alvin Hsia’s What I Learned In My First Year as a Product Designer is a good refresher and reminder about what’s important when working with others. This point is worth discussing further:
Make a deliberate effort to cultivate empathy for other team functions and be able to explain your designs to whoever it is you’re talking to, in their terms. It’s ok to use design jargon as long as you’re able to educate others on what the impressive-sounding words you use actually mean. Break down how your designs fit into the context of what they do and/or company goals. This requires you to get inside the mind of people in a variety of functions and gain a basic understanding and appreciation of what they do and can manifest itself in many ways.
Two books were a really big deal when I was in high school. The first is Stephen Covey’s The 7 Habits of Highly Effective People. Everyone was reading this thing. I was obsessed with the book, and even read all the prequels and sequels — although the only title I can remember is First Things First, because it just seemed way too obvious to me at the time. I even bought the Covey Daily Planner™ (or whatever it’s called) and kept it up religiously. Paper — how cute.
The other book that was a big deal is To Kill A Mockingbird. I must have read it 10 times as part of English class. Up to then, most of my reading was confined to a very limited set of prudish Afrikaans authors. To Kill A Mockingbird was different. It awoke in me an obsession with words and reading that I’m thankful for to this day.
I bring this up because both these books — as different as they are — have served me well over the years in my career. All because at their core, they have the same theme: empathy. I’ve long forgotten the 7 habits — except for one:
Seek first to understand, then to be understood.
And I don’t remember much from To Kill A Mockinbird, except for this passage:
You never really understand a person until you consider things from his point of view — until you climb inside of his skin and walk around in it.
More than 20 years after reading the books, these are the phrases I can’t get out of my head, especially if I’m tempted to get frustrated when someone doesn’t “get” the reasoning behind one of my designs. Instead of going into defensive mode, I’ve learned to hold back and simply say: Tell me more about that. Trust me, this is a magical, powerful phrase. It shows that you want to understand, that you don’t know everything, that your only desire is to make the product better. It breaks down aggression, it improves communication, it teaches you things.
I’m not perfect at this — I admit that I sometimes still lose my cool. But whenever I have the wherewithal to seek first to understand, then to be understood, I come out the other side a better designer. And I think that’s worth sacrificing a bit of pride for.
If you’re a business that would like to reach Elezea’s audience, have a look at my sponsorship opportunities.
Everyone is posting about this today but I don’t care because it is really that good and it wins all the points on the Internet today. Paul Ford in How to Be Polite:
People silently struggle from all kinds of terrible things. They suffer from depression, ambition, substance abuse, and pretension. They suffer from family tragedy, Ivy-League educations, and self-loathing. They suffer from failing marriages, physical pain, and publishing. The good thing about politeness is that you can treat these people exactly the same. And then wait to see what happens. You don’t have to have an opinion. You don’t need to make a judgment. I know that doesn’t sound like liberation, because we live and work in an opinion-based economy. But it is. Not having an opinion means not having an obligation. And not being obligated is one of the sweetest of life’s riches.
I wrote something slightly related (and, let’s be honest, not nearly as good) a while ago for Smashing Magazine: Making A Better Internet.
I nodded along vigorously to Cap Watkins’s The Fight:
What I’ve come to realize in the past two years is how important it is to find a company and a product worth fighting for. To find a team that is dedicated to delivering the best product they can, despite the bumps, the frustrations, the exhausting moments along the way. Hurdles and failure are totally unavoidable. Having a resilient team around you working on a product you all believe in will make those hurdles easier to clear. They’ll turn failure into a learning opportunity. Great teams working on products they’re passionate about will back you up when you’re exhausted and cover for you when you’re frustrated.
When you find a team like this, hold on for dear life.
Dhruv Khullar describes The Trouble With Medicine’s Metaphors:
The words we choose to describe illness are powerful. They carry weight and valence, creating the milieu in which goals of care are discussed and treatment plans designed. In medicine, the use of metaphor is pervasive. Antibiotics clog up bacterial machinery by disrupting the supply chain. Diabetes coats red blood cells with sugar until they’re little glazed donuts. Life with chronic disease is a marathon, not a sprint, with bumps on the road and frequent detours.
Khullar goes on to discuss in depth the use of military metaphors in medicine, such as the common saying “We’ll fight this together,” and why it can be counter-productive.
Allan White describes Our Product Design Process:
Our design process at HealthSparq is — just like everyone else’s — itself a work in process. We have ongoing debates about the tools and techniques we use to execute on each phase. Parts of our process (for example, a new pattern library that integrates directly with our apps) are being rebuilt and aren’t fully useful yet. It was very constructive to have this discussion, and to have a framework to build upon moving forward.
I’m posting this here because we started a design and development blog where we plan to share some of the things we learn as we go, and I think this one is particularly useful since it includes (what I think is) a really great visual of the design process we agreed on as a team. Head on over and check it out…