Photographer Tanja Hollander wanted to find out what online friendships are really about, so she set out to visit all 626 of her Facebook “friends” at their homes to take formal portraits of them. The first part of How Real Are Facebook Friendships? describes the project, and then it goes into some other research about social media and friendship:

In fact, the distinction between online and offline may be less relevant than it seems. Thinking about social media as a kind of place you go, divorced from physical reality, is a forced demarcation. Facetiming and meeting a friend for coffee certainly aren’t the same experiences, but as Nathan Jurgenson, a contributing editor at The New Inquiry and a researcher at Snapchat, points out, “the self is fluid.” Facebook messaging one friend and writing in pencil to another, as Hollander did that New Year’s Eve, may be more equivalent ways of communicating and expressing herself than she thought. A video chat is physically intimate, Jurgenson argues. And what he calls “digital dualism,” the separation of online interactions from “real life,” doesn’t capture relationship dynamics in the 21st century.

I think this is the most important sentence in the article (and maybe of 2015):

[Jessica Vitak, a professor in the College of Information Studies at the University of Maryland] cautioned against an all-or-nothing divide—that Facebook is either “a waste of time” or “the most important social development in history.”

Imagine that. It’s not universally awesome, or evil. It’s just a tool, and how we use it makes all the difference.

Buzz Usborne’s “God is in the details” is a great reminder that spending just a little time thinking things through a bit more that usual can have a big impact on user experience:

But it’s those little things, the tiny minutia of detail, that ultimately make beautiful products, and beautiful houses.

Unfortunately, when I refer to the “details” in product design, I’m not talking about obvious design things; like colours, drop-shadows or placement. Instead I’m referring to something harder to define; experience and subconscious patterns that help the user feel more at-ease with an interaction. That detail might come in the form of a change in cursor, a “down” style for a button, or a helpful animation.

Whatever form that detail takes, I’ll bet that it wasn’t designed in Photoshop, or included in even the most detailed spec document. It’s the details that fall outside of titles like UX, or UI. It’s interaction detail that can only be found after using a product for real, then dedicating solid design and engineering time to building.

I definitely agree with that last bit as well. I’m working on a prototype for a new app at the moment, and it’s only after we did usability testing with real target users that we discovered some interactions that would make the app a lot easier (and more useful) for users.

Michael Andrews brings up some interesting concerns about cards in Are UI Cards good for content? However, I’m left thinking that most of the “cons” in the article are actually Information Architecture problems, not problems with the card metaphor:

UI cards can contribute to content usability problems that may not be immediately evident.  Users often like UI cards when they encounter them, and don’t notice their limitations.  They see tidy cards often with colorful thumbnail images.  The cards seem optimized to make good first impressions.  But often, the cards end up squashing the content that must go in them, or omitting content details that don’t fit the layout vision.

If content is squashed and truncated in cards, it’s not the card element’s fault, it’s the content’s fault. It happens when content isn’t written while keeping the context of use in mind.

Here’s another example:

Another issue with UI cards is their lack of hierarchy. When all cards are the same size, all cards look equally important, whether they have detailed information, time sensitive information, sparse information, or optional information.

Again, visual hierarchy is a larger design problem, and not the fault of cards.

I point this out because it reminded me of one of the big dangers in design that we have to watch out for. We often see a UI issue and immediately switch out the pattern instead of trying to understand what the the real problem is. It’s great if we can look at something we designed and say, “Hmm, that doesn’t work.” But we have to go further and also understand why it doesn’t work before we just take the easy why out and replace the UI element.

If content is squished on cards, is it because we used cards, or because we didn’t write the content concisely enough to be easily consumable in small spaces? If all cards look the same, should we stop using cards, or design different card types to address visual hierarchy better? I would argue that in both cases, the latter should at least be considered. Of course, if cards are wrong for the interface, then burn it with fire. But be sure.

Further reading on cards:

• Card Architecture and Card Design
• How to Champion Your Content with Cards
• Why Cards are the Future of the Web
• Twitter, canvases and cards

Debbie Chachra wrote a great essay on our current obsession with the word “Maker”, and how that devalues other professions like educators and caregivers. From Why I Am Not a Maker:

When new products are made, we hear about exciting technological innovation, which are widely seen as worth paying (more) for. In contrast, policy and public discourse around caregiving—besides education, healthcare comes immediately to mind—are rarely about paying more to do better, and are instead mostly about figuring out ways to lower the cost.

I’m currently working on the design of a native app for Jive Software, and we really wanted to do some usability testing on a prototype before development starts. There are, of course, a multitude of reasons to do usability testing on prototypes, but we had some very specific issues we wanted to address:

• We are a distributed team. Product Management is in Palo Alto, Product Design is in Portland, and Development will happen in our Tel Aviv office. So we knew from the beginning that a functional prototype would be essential to communicate within the team. Flat wireframes / PSDs just weren’t going to cut it.
• We’re working on something in a fairly new market, so we need to do quite a bit of validation to make sure we get the utility of the app right.
• And of course, our designs are never as good as we think they are, so we wanted to make sure we correct the majority of the usability issues before development starts.

I read a lot about prototyping native apps and mobile usability testing, and since everyone’s process is different, I wanted to give an overview of the process we settled on, since we’re really happy with it so far. It was very important to me that all our offices would be able to observe the usability tests, so that guided a lot of the decision-making. Here’s how we’re doing it…

Prototyping

After reviewing and trying out every prototyping tool known to man, I settled on Proto.io for this project. There are so many great options out there that it’s hard to go wrong on a choice of tool. Proto.io was the best for me because of a few key features:

• I needed full interactivity — since we used the prototype for usability testing it needed to feel as real as possible.
• I needed lots of flexibility in the animations/transitions supported, since we’re in new territory and need to try out lots of different things. Proto.io supports any interaction I threw at it.
• I needed to use a mix of built-in components and my own assets, and Proto.io handles that pretty well.

Of course, I can’t show what the prototype looks like at the moment, but as soon as the app launches I’ll update the post and embed it here.

Mobile usability testing rig

I got lost in mobile usability testing guides for days — there are so many good ways to do it. At first we considered remote testing, but it just wasn’t a good option for us because we were going to do part IDI (in-depth interview) and part usability testing, so we needed a way to be in the room with users and dig deep into certain areas.

I’ve seen some crazy setups — my favorite and weirdest is probably MailChimp’s “hug your laptop” idea. It’s a brilliant hack, but I was worried our non-tech savvy users would have trouble with this, so I needed another solution.

I ended up going with Bowmast‘s Mr. Tappy kit, and I attached a Logitech HD Pro Webcam C920 to it. We played around with it in the office first to make sure it’s going to work:

With that out of the way, it was on to the next challenge — how to stream it everywhere.

Streaming to observation rooms

This part was much easier than I thought, simply because we already use Vidyo for videoconferencing in all our offices. So every time I started a usability test I would start my meeting in Vidyo, and then people from our other offices could dial into my meeting from their observation rooms. They could see the room on one screen, and the participant’s phone on another. It worked like magic:

What we ended up with is a setup where I can do usability testing in person on mobile devices, record the sessions, and have people observe these sessions from anywhere in the world. It was an incredibly productive few days, and I’m now working my way through fixing all the usability issues we picked up. Can’t wait to show this to you when it goes live!

Further reading:

• Recording Mobile Device Usability Testing Sessions
• How we built a research lab for mobile app testing in just a few hours
• Remote Usability Testing on Mobile Devices
• How to Conduct a Usability test on a Mobile Device
• Eight Lessons in Mobile Usability Testing
• Secrets From Facebook’s Mobile UX Testing Team

There is so much wisdom in Paul Adams’ Lessons learned from scaling a product team, but my favorite part is the clear articulation of accountability. All companies should have something like this:

• If the analysis of the problem to be solved is incorrect, it’s on the PM. Ensure appropriate research is done.

• If the design doesn’t address the problem, it’s on the Designer. Ensure you understand the research and problem.

• If the design solves the problem, but doesn’t fit with Intercom, deliver best practices, or is otherwise weak, it’s on the Designer. Ensure you understand our beliefs, patterns and principles.

• If engineering doesn’t deliver what was designed, or delivers it late, it’s on the Eng Lead. Ensure you understand the problem being solved and design, plan appropriately and accurately before writing code.

• If it goes out with too many bugs and broken use cases it’s on the PM. Ensure the team test realistic usage and edge cases.

• If the team is spending too much time on fixing bugs and not adding new value per our roadmap, it’s on the Eng Lead. Ensure each project improves overall code quality.

• If we don’t know how it performed, it’s on the PM. Ensure success criteria are defined and instrumented.

• If it doesn’t solve the problem, it’s on the PM. Ensure there is a plan to improve product changes that don’t fully solve the problem.

In other words, the buck mostly stops with Product Management…

Putting the linkbait title aside, Steve Denning’s The Dumbest Idea In The World: Maximizing Shareholder Value¹ is a really interesting article about the difference between “real markets” and “expectations markets”:

In today’s paradoxical world of maximizing shareholder value, which Jack Welch himself has called “the dumbest idea in the world”, CEOs and their top managers have massive incentives to focus most of their attentions on the expectations market, rather than the real job of running the company producing real products and services.

And that comes at the expense of customers. This sentence also stood out for me:

Unfortunately, as often happens with bad ideas that make some people a lot of money, the idea caught on and has even become the conventional wisdom.

In Netflix’s Secret Special Algorithm Is a Human Tim Wu writes about the importance of human intervention in data-driven decision making:

Of course, there is a big difference between using data in combination with intuition and relying entirely on an algorithm—the decision-making equivalent of Siri finding gas stations near you. I don’t think anyone—Netflix, Mitt Romney—makes big decisions that way. As Chris Kelly, the C.E.O. of Fandor, an indie-film Internet channel told me, “It just isn’t true that you can rely on data completely.” Even Google, the champion of algorithms, employs substantial human adjustments to make its search engines perform just right. (It cares so much about this that Google claims First Amendment protection for its tweaks.) I do not doubt that companies rely more on data every day, but the best human curators still maintain their supremacy.

It’s a good reminder that following data blindly is a pretty bad idea. Joshua Porter’s Metrics Driven Design is stil the best presentation I’ve seen on this topic and how it relates to design.