Menu

Being

I’ve been thinking about being recently. Being online, being at home, being at work, being in public, being in private. This year my family and I made some gigantic changes in our lives that I won’t bore you with, except to say that constant change and discomfort gave me a renewed appreciation for human frailty. In fact, I’ll go so far as to say that, for the first time, I feel like I truly understand these words by Thomas Kempis:

A true understanding and humble estimate of oneself is the highest and most valuable of all lessons. To take no account of oneself, but always to think well and highly of others is the highest wisdom and perfection. Should you see another person openly doing evil, or carrying out a wicked purpose, do not on that account consider yourself better than him, for you cannot tell how long you will remain in a state of grace.

We are all frail; consider none more frail than yourself.

All of this helped me figure some things out about being that I haven’t been particularly certain about before. Things like who I want to be and what I want to do with my life. The answers to those questions are probably irrelevant for what I want to write about here, so I won’t dwell on that. What I will do is share a few things I’ve become fairly sure of over the last few months (while I remain open to data-driven mind-changing next year, like any decent designer would).

So here are some things I learned in 2014:

Smaller networks are better

During some of the darker months of the year I retracted from Facebook and found some solace in the 5 or so active friends I have on Path (go ahead, laugh it up…). On Twitter I doubled down on what I’ve always done: being a link monkey, there for your daily dose of UX and product management links. There’s certainly comfort in that ritual and the feedback that comes from it. But it does get pretty empty after a while.

When things started to improve I gave Facebook a try again. I once again expanded my network. And suddenly it just felt really really loud and crowded and filled with people like me who are just looking for positive reinforcement and I didn’t like the way that made me feel.

So I went back to small. I’m still active on Path. On Twitter I share more personal things in addition to links I really like. It pisses some people off, but it feels more real. I also started writing a newsletter and I’m really enjoying the personal nature of that medium.

All of this to say that we’ll do well to remember that the web is people all the way down. And that smaller networks mean more meaningful relationships.

Who we amplify is who we are

Every day we choose whose voices we amplify online, and those choices make us who we are. After Ferguson happened I felt like I didn’t have a right to say anything about it. But what I could do is amplify the voices of those who did have something important to say. So that’s what I did. I retweeted articles and calls for help. I eventually did write something, and I still feel uncomfortable about it, but in the end I felt like I had to.

The things we say are important. They make us. Not to get all preachy, but Matthew sums it up pretty well:

But the things that come out of a person’s mouth come from the heart.

So I’m not always getting this right, but I want to amplify good things and people who say important things. Who we amplify is who we are. So let’s choose wisely.

Learning and sharing is what makes us a community

After much reflection I realized that to become a better designer and be a good web citizen there are only a few basic things you have to do:

  1. Read about a new thing.
  2. Practice new thing until it works for you.
  3. Write about what you learned while practicing the new thing.
  4. Repeat ad infinitum.

That’s it. That’s what community is: learn from others, practice until you get it, and teach others the new things you learned. We should really do more of that.

Being a small fish in a big pond is ok

I don’t know how to write this without sounding weird so I’ll just go ahead and put it out there and hope it comes out right.

When I lived in South Africa I thought what I wanted was to become an author and conference speaker. It was a bit easier there because there aren’t as many UX people as there are elsewhere in the world. And when I decided to move back to the US several people didn’t understand. “You’ll be a small fish in a big pond,” they said. “I know,” I would answer, “isn’t that awesome?”

The fact is that where I am right now is a much better fit, and I recognize the importance of being content in the situation we’re in. I do a job I love at a company with an awesome culture. Every once in a while I share things. My book didn’t become a bestseller, but the people who read it seem to enjoy it, and that makes me happy. I spend time with my family, and I tweet some jokes and links every once in a while.

I don’t get invited to speak at conferences, and I don’t have a major book deal coming. But I still enjoy writing, and I enjoy being with the people I hang out with — online and in person. After the year I’ve had, that is all I could ever ask for.

It was hard, but I’m thankful for 2014 and the meaningful lessons that came out of it.

Now let’s get it behind us and move on, shall we?

Short-term vs. long-term product planning

Scott Sehlhorst makes some very good points about different levels of roadmap detail in Opposite Views of a Product Roadmap:

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways.

When it comes to what you’re building, the roadmap gets less precise as you move further out:

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. (BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.)

In contrast, when it comes to why you are building what you’re building, it starts off fairly broad and becomes more precise as you go on:

In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.

The way I would summarize Scott’s post is as follows. When it comes to product planning, be rock solid on what problems you’re solving for which customers, but be open to data-informed change when it comes to short-term implementation details.

Dark pattern: Walmart login

This is the login screen on Walmart.com:

Walmart login

It looks like any other login screen, with one difference. See that check box? What does that check box usually indicate?

Yep. The standard pattern on the web is to use that space for the “Keep me signed in” check box on login screens. Here are a couple of examples I quickly went to:

Signing in

That Walmart interface was designed to trick people into signing up for marketing email, since most people will simply check the box without reading the text. We really need to stop with these dark patterns.

Product management and context-switching

In Avoiding product management whiplash Hemal Kuntawala describes the constant context-switching that PMs need to do as they move from strategy to execution and back:

Each phase of product development requires a different perspective, almost a different mindset. At one end of the scale you have a big-picture view of the world, like looking at the market you’re in and hypothesising new value propositions. At the other end you have nitty-gritty details like the pixels and font-sizes of your UI.

I like the gentle slopes of the sine wave he uses as illustration, although I think in reality the back-and-forth is a lot less gentle…

In defense of enterprise software

I like Jordan Koschei’s defense of enterprise software work in UX for the Enterprise. This is what I get to do every day at Jive:

As designers, we live to solve problems, and few problems are larger than those lurking in the inner depths of a global organizations. After all, Fortune 500s tend to have a “just get it done” attitude toward internal tools, resulting in user experiences that aren’t well designed or tested. By giving those tools the same attention to experience that you give consumer-facing products, you can improve the lives of your users and support the organization’s values and brand.

And this is so important — it’s why it’s essential to do research with end users:

A successful enterprise UX project considers the users’ needs, the clients’ goals, and the organization’s priorities. The best user experience sits at the intersection of these concerns.

Product design: a balance between vision, intuition, and data

I really liked this interview with Josh Porter where he talks mainly about good product design, and the importance of user feedback:

Good product design is the result of persistence as much as anything else. That’s why you hear companies like Airbnb and Evernote and others say that it can take years to figure out user onboarding or free trials or other sophisticated flows. It takes a lot of time to get your message right, get the user incentives right, get the interaction right, etc. It is easy to become impatient and throw out some great ideas prematurely.

And this:

The interplay between vision/intuition and data/feedback is that you need both. You need to be able to assess how you’re currently doing with data but also not let data stop you from taking risks with your product. Many teams become conservative over time as they rely more and more on data to make decisions. They ultimately become paralyzed and unable to build something really new.

Don’t fear the empty space

Lukas Mathis writes about our fear of empty space in visual design in Horror Vacui:

There’s a concept in visual art called horror vacui, or «fear of empty spaces.» It’s the natural tendency of humans to fill empty spaces with stuff. Your new shelf has some empty panels? Put something in there! Your flat has an empty corner? Buy a chair! Or a plant! Something! Anything!

Humans have the same tendency when it comes to visual design. No empty space! Your screen has a few white pixels? What feature can we put there! Quick! Find something we can put there!

There’s a problem with that, though. Empty space is not useless.

He goes on to explain that “emptiness equates to prestige.” In short, don’t fear the empty space!

Using Mail.app as a replacement for Outlook for Mac

The biggest problem that many Mac users struggle with is that we work for organizations that use Exchange for email and calendar management. This means that, in most cases, we have to use Outlook for Mac if we want the majority of basic tasks to work. It’s an application that is so ugly and bug-ridden that most people look like this every time they open it:

Outlook

The problem is that traditionally it’s been pretty difficult to make OS X’s Mail.app play well enough with Exchange to be a viable replacement. For my personal use case there were a few things that always held me back:

  • The default view settings are not conducive to effectively manage a lot of email.
  • No keyboard shortcuts to move messages into folders.
  • All other email programs display the default system font when it receives an email generated in Mail.app — in Office for Windows this is Times New Roman.

I think I’ve finally addressed these issues enough to make Mail.app my primary mail application and ditch the horrors of Outlook. But you’ll need a few settings and plugins to get that done.

View options

I like the simple, friendly list view that these options give me. Try it out:

View options

Shortcuts for moving messages

Mail Act-On 3 is an essential extension. It does a bunch of different things, but for the best feature is that you can map a key to moving messages to a different folder (I use “v” to match Gmail’s shortcuts), and then use type-ahead to pick the right folder:

Move messages

Changing the default font

Universal Mailer is another powerful plugin that just makes Mail.app work better, but its best features is that you can set a system font that is respected by other email programs:

Force font

Unexpected bonus features

Switching to mail brings a bunch of great things with it that you don’t get in Outlook:

  • Smart folders that can bring a bunch of different emails together based on specific criteria you set.
  • Great integration with iOS, since it takes advantage of handoff.
  • Fast email that’s not ugly.

All I’m saying is, give it a try. Your eyes will thank you.

More

  1. 1
  2. ...
  3. 88
  4. 89
  5. 90
  6. 91
  7. 92
  8. ...
  9. 201