There are some wonderful and surprising stories in Ian Urbina’s The Secret Life of Passwords:

SEVERAL YEARS AGO I began asking my friends and family to tell me their passwords. I had come to believe that these tiny personalized codes get a bum rap. Yes, I understand why passwords are universally despised: the strains they put on our memory, the endless demand to update them, their sheer number. I hate them, too. But there is more to passwords than their annoyance. In our authorship of them, in the fact that we construct them so that we (and only we) will remember them, they take on secret lives. Many of our passwords are suffused with pathos, mischief, sometimes even poetry. Often they have rich back stories. A motivational mantra, a swipe at the boss, a hidden shrine to a lost love, an inside joke with ourselves, a defining emotional scar — these keepsake passwords, as I came to call them, are like tchotchkes of our inner lives. They derive from anything: Scripture, horoscopes, nicknames, lyrics, book passages. Like a tattoo on a private part of the body, they tend to be intimate, compact and expressive.

I now use 1Password to create unique passwords for each service, but the article did take me back to the one password story I do have. Back in college, when it was time to select a password I could remember easily, I remember leaning back in my chair and giving it some serious thought.

I had just seen Patch Adams and top of mind for me was part of a poem the character recited that really stuck with me (full version here):

I know it’s ridiculously syrupy, but I apparently used to be a romantic. Huh.

Anyway, my default password became two words from the poem, smashed together. Even though I don’t use the password any more I just can’t get myself to tell you which words, though. I guess some of this story needs to remain mine alone.

There are a few controversial ideas in Benjamin Sandofsky’s You Can’t Go Home Again, in which he basically says that Agile methodologies shouldn’t be used in mobile app development. I did find this perspective on QA interesting in our increasingly post-QA world:

Sit down with a software engineer from anywhere but the web, and ask them about QA. Tell a game developer you don’t need it, they’ll tell you you’re nuts. Maybe these agile people have been burned by bad QA, but a great QA team is far from a bunch of monkeys clicking buttons all day.

Formal QA provides a counterpoint to “move fast and break things.” Their job isn’t to say, “No.” It’s perfectly fine to ship bugs– otherwise software would never ship. You need someone who is aware of all the bugs, and help you make the decision if the risk is worth it.

Also see Michael Lopp’s The QA Mindset for some really good perspective.

Dan Lockton’s As we may understand is unnecessarily long and rambling at times, but it’s still worth it for the very interesting views on the Internet of Things and designing for behavior change:

Many of the issues with the ‘behaviour change’ phenomenon can be characterised as deficiencies in inclusion: the extent to which people who are the ‘targets’ of the behaviour change are included in the design process for those ‘interventions’ (this terminology itself is inappropriate), and the extent to which the diversity and complexity of real people’s lives is reflected and accommodated in the measures proposed and implemented. This suggests that a more participatory process, one in which people co-create whatever it is that is intended to help them change behaviour, is preferable to a top-down approach. Designing with people, rather than for people.

Again, it comes down to understanding people and their needs before embarking on a design. I wonder if we’ll ever fully learn this lesson.

Also see:

• Can Technology Really Change Your Habits? (Fast Company)
• There’s a backlash against nudging – but it was never meant to solve every problem (The Guardian)

David Cancel has some interesting thoughts on how they split up product management and tech team responsibilities in How we transformed HubSpot into a Product Driven Company. I really liked this part about embedded designers:

While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. […] The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.

That post led me to Jeremy Crane’s What does a Product Manager do at HubSpot, which goes into more detail on the PM/Tech team split:

Every product team’s job is, essentially, to solve problems for their customers. Solving problems involves two key components: (1) Understanding the problem, and (2) creating the solution. At HubSpot the product manager owns the “problem” and the technical team owns the “solution.”  The “problem” is defined by whatever is likely to produce the greatest value to the customer and the business at large within the area of influence. The “problem” is both long-term and short-term in scope. It addresses the immediate challenges that the customer is experiencing, while still keeping an eye the longer-term vision of the product as a whole.

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?

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.

This is the login screen on Walmart.com:

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:

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.

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…