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…

I like the work Growing Agile does, so I clicked on Karen Greeves’s Agile & UX: What’s wrong with working one sprint ahead? with great interest. I’ve been struggling with this issue myself, but I’ve just never come across a better way to integrate UX and Agile, so I was very interested in their viewpoint. The post definitely got me thinking, but I have some issues with their objections. In the interest of letting you in on the thought process, I’m going to take some lines from the post and explain why I don’t agree¹. Let’s start with their main concern with UX working one sprint ahead:

The main issue with this is one of focus. If the UX designers work one sprint ahead of the rest of the team, then the UX designers and the team actually never work on the same stuff at the same time. This means they are never focused on the same thing.

This is (partially) true, but isn’t it also true for individual developers on the team? They’ll be working on different stories. That’s the reason we have standup meetings: to make sure that those individual tasks work together to finish the whole.

I say it’s only partially true, because people can focus on more than one thing… So while the UX team is working on the next sprint, they can still be available to help with changes and questions on the current implementation work.

It doesn’t make sense to have the same standup meeting because you aren’t working on the same stuff.

Again, very few people are working on the same stuff. And this is actually an opportunity for the UX team to highlight any issues they have that developers can help them with.

It’s harder to help each other out because you are focused on finishing different stuff.

I don’t really get this point — we should be able to shift focus, and helping each other in different contexts often produce better results. Isn’t that the principle that code reviews are based on as well?

The people working ahead consider their deliverable some interim artefact, not working software, so there is a handover of both knowledge and responsibility.

In our context the UX team’s deliverable is working software in the pattern library, which uses the same frameworks and environment as our front-end developers, so that they can keep going seamlessly. So it’s possible to solve this problem.

People don’t see themselves as part of the same team, so you end up having a UX team and a dev team. This inhibits collaboration and communication.

I don’t agree with this point, either. We’re always going to have different skills on teams. Product Owners have different skills than the development team too. In fact, I think it can increase collaboration if developers are asked to provide input while the UX team is working on an upcoming feature.

The people working behind aren’t involved in the decision making that happened without them and as a result they don’t understand the reasons for certain design choices, this often leads to assumptions, and rework.

This doesn’t have to be the case. We have developers involved from Product Discovery all the way through prototyping, testing, and final specifications.

I’m not advocating writing code before an UX work has taken place. I’m saying the whole team should be involved in that work. Obviously the UX designer(s) take the lead here, but everyone on the team needs to see users use their product and understand the user journey map.

Ok, on this we agree!

In each sprint the whole team should set aside time to look at UX designs for the next sprint, as well as usability testing whatever has been completed.

I agree with this, and it’s how we work. But where I’m confused is that this still means that the UX team is working one sprint ahead of development — they’re working on “UX designs for the next sprint.” The only difference from how it’s usually done when UX and Agile works together, is that it formalizes the time that developers spend on being involved in the UX process.

If I understood that correctly, then it turns out we agree after all, and maybe this post wasn’t necessary…

I really like the James Buckhouse explains in is article Story Map:

Halfway between a storyboard and a treasure map, it bundles the value and functional flow of your product with the delight people might feel at each step in your product. It sketches the UX flow without locking it down, and it delivers the gist of an idea and the emotional gestalt without prematurely belaboring the details.

A story map depicts how your product works and why it matters—but crucially—it does not explicitly spell out the final design, UI or in-the-weeds UX logic. It does, however, hold the product vision and works as a rubric against which the team can make better and faster decisions.

The article has some great examples worth looking at. As a big customer journey mapping fan, this is definitely something I want to try out.

I have one quibble though, and that’s with the name… “Story mapping” is already a very well established process in Agile development. Here are just a few articles about it:

• The new user story backlog is a map
• Visualizing Progress with Agile Storymapping
• Winnipeg Agilist: How to create a User Story Map

Semantics are important, so my suggestion would be to simply use a synonym:

@buckhouse Maybe just use a synonym and go with “narrative mapping”?

— Rian van der Merwe (@RianVDM) August 2, 2014

Claire Evans discusses how much more awkward break-ups have become in the age of social media. From Luddite love:

It’s time to end it online. I’m not just talking about the pedantic tick-box of Facebook ‘relationship status’: there are images to untag, emails to delete, an ‘unfriending’ to coordinate. There is the careful unravelling of the social web.

In a sense, every relationship now exists on two levels. The moments we spend in one another’s company, the neurochemical buzz of proximity, and the communion of shared silence: these are real. But just as physical places now have their geolocated overlays, every relationship, too, throws a digital shadow — and depending on the individuals involved, it can loom larger than the people who cast it. As we increasingly live our social lives in public, in a medium that retains the traces of our social noodling, the record and the relationship itself can approach a point of indistinguishability.