Richie Siegel in Facebook Isn’t Worth It:

With Facebook acting as the gauge of social worthiness in the twenty-first century, it’s time we realize that a lot of what we hoped Facebook could accomplish was unrealistic and impossible. Facebook is not going to keep your friendships going, no matter how much effort you put into it. Only humans, talking and being with other humans, can develop meaningful, lasting bonds. You can have all the friends in the world on the internet, but once you step away from your computer, only reality remains. 

That’s his conclusion following a long argument that’s well worth reading.

(link via Ben Brooks)

Arriving at a company as a new (or sometimes, the first) Product Manager can be daunting. Product Management is usually introduced in an organization once there is a such a high level of internal enthusiasm and chaos that the leaders aren’t sure how to handle it any more. And then everyone looks to the Product Manager — you — to “manage stuff”.

It’s easy to get overwhelmed by how much there is to do when you step into a stressful role like Product Management. So here are some recommendations on how to spend your first 3 months at a new company.

First 30 days: Understand the product, the market, and the company culture

The goal of the Product Manager is “to deliver measurable business results through product solutions that meet both market needs and company goals”. With that in mind, spend the first 30 days learning and understanding:

• The product. What does the company sell? What does the product do? How does it work? What is the value proposition? What problems does it solve for customers? What features does it have? What kind of bugs does it have? What are the main usability issues?
• The market. Who currently uses the product? What are they like? What are their characteristics? What do they like and not like about the product? Who is the target market? Are there personas for each different type of person in the target market? What are macro and micro market needs addressed by the product? Who are the competitors?
• The current product/market fit. Are you in a good market with a product that can satisfy the market? What are the gaps that you need to close between what the product does, and what the market needs, to ensure a better fit?
• The company culture. Talk to as many people as possible in the organization — from marketing to finance to design to engineering — to understand how things work. What do people like about the product development process? What do they hate? Do designers feel like they have enough time to do their work? Do developers have what they need to program effectively?
• Ensure the PM role is properly understood. For a Product Manager to be effective, the organization needs to understand that PMs should have autonomy over the products they manage. Executive buy-in is a prerequisite for success, so make sure that it’s well understood that even though everyone gets a voice, not everyone gets to decide. As Seth Godin once said, “Nothing is what happens when everyone has to agree.”

Next 30 days: Develop a strategic product plan

Based on what you learn in the first 30 days, start the product planning phase:

• Run a Product Discovery workshop to start identifying user needs, business needs, and technical needs, and to create a problem frame diagram.
• Develop personas and user journeys, and start brainstorming ideas for product development with the team.
• Work with the team to prioritise ideas and start building a roadmap for development. Consider methods like the KJ-technique or the Kano model as a way to formalize prioritization efforts.
• Identify success measures — define how you’ll know if what you’re doing is having the desired impact. The 3 A’s (Acquisition, Activation, Activity) are always a good start.
• Put the appropriate processes in place to ensure effective product development lifecycles. This means knowing what kind of requirements and specifications developers need to start working, how research and design fits into the process, where marketing becomes involved, how QA should work, etc. You can only do this once you understand the current culture, and what the strategic plan will be going forward.

All of the above goes into a document called the strategic product plan. Among other things, this plan includes statements about the product’s value proposition, who the market is (customer profiles), how you plan to achieve product/market fit (the business opportunity, pricing, distribution), what the priorities are, a first stab at the roadmap, and proposed success measures.

Next 30 days: Start executing on the strategic product plan

Now that the plan and the initial roadmap are in place, start the product execution phase:

• Start with a reasonably small requirement with clear and easily measurable success metrics. Work with the team to get it done right.
• Measure, and show the success of the process. Use this to build trust and continue to ship improvements (and even better products).
• Assess the situation, and use customer and business feedback to adjust priorities (and the roadmap) as needed. Flexibility is key.
• Keep going. Repeat any of the initial steps as needed.
• Have fun while you’re doing all of this.

The life of a Product Manager has an exhausting, exhilarating rhythm that is beyond the scope of this article. But spending your first 3 months systematically moving from product planning to product execution will not only give you a solid foundation from which to improve the product, but also ensure that you hit the ground running by shipping the right improvements as early as possible.

I posted an earlier version of this article as an answer on Quora.

120 days. That’s how long it took for the term Flat Design to go from cutting edge to extremely uncool. On September 25, 2012 the LayerVault team introduced Flat Design in their post The Flat Design Era:

We interpret recent shots taken at skeumorphism as a sign of the coming of “Honest Design.” Much like we were not too long ago, designers working for the web are getting fed up with the irrational, ugly shortcuts being praised as good design.

On January 23, 2013 Cole Peters pronounced the term dead in Flatliners:

However, it seems that fervour I mentioned has taken a turn for the worse over the past little while, switching gears from enthusiasm, straight into full-blown fanaticism. And while the topic has borne a few great articles, ideas and interfaces, the bulk of the conversation around flat design tends to mimic with unfortunate precision the lack of depth the movement is built around.

So, it’s time for us to find a new thing to argue about, I guess. But before we do, let’s remember something Wells Riley said at the height of the Flat Design debate. In Less Aesthetic, More Design he argues that a more accurate term would be Flat Aesthetic, and then concludes:

Flat aesthetic is great. Skeuomorphism is fine too. It’s even okay to gush over sexy UI on Dribbble and explore aesthetic fads in your own work. Just don’t forget the other 90% of what makes a design comprehensively great.

Design is a form of problem solving. Never forget that.

Preach it, brother Wells.

Cennydd Bowles casts a critical eye on the UCD process in Looking Beyond User-Centered Design. He lists several weaknesses of UCD, including the negation of style — the idea that “Good design is invisible”:

By negating the idea of a designer’s influence, we also negate the idea of style within the UX discipline. We’re saying that, done properly, it should be impossible to tell one UX designer’s work from another’s. There should be no signature elements, no philosophical movements, no overarching tenets except that of transparency. […]

Of course our designs must put users first. But there is never just a single way to meet user goals. Instead of trying to deprecate style, we should embrace it as a way to drive our practice forward and lend personality to the things we make. In a marketplace of bewildering clutter, products with a damn opinion are by far the most interesting.

Cennydd’s main point is not that UCD is a bad methodology and that we should stop using it, but that its dominance might be a problem. Designers should be familiar with many modes of design, so that we can draw on a variety of techniques, not just our favorite one. It’s a good article, well worth your time.

One of the alternative approaches that Cennydd touches on is Activity-Centered Design (ACD). I want to focus on that because Mike Long wrote a great article about ACD recently, cheekily called Stop Designing for “Users”. He discusses some limitations of personas before introducing Activity Theory, and a technique they use often called the Human Activity System Diagram.

As an example, Mike shows how he used the diagram to understand behaviors and actions in a local carpool:

Image source: Stop Designing for “Users”

Mike explains how ACD resulted in a better understanding of the problem (and possible solutions) than UCD would have:

By analyzing the whole system, rather than individuals, I came to the realization that the objective for drivers and passengers to carpool with minimal coordination was already happening. In the casual carpool pickup spots rituals and norms naturally emerge with readily available tools and artifacts. Namely, vehicles and queues. What about other issues like lost-and-found items? The system has already compensated: If someone forgets to take a purse or a phone when they get out of a vehicle, the driver can simply post “found” signs at the head of the passenger queue. Any other solution I can think of would require another layer of coordination between drivers and passengers.

Both these articles challenged me to think broader than UCD and explore other design systems — even ones I’ve been skeptical about in the past, like Genius Design. I realised that even though UCD is a proven way to build great user experiences, it would be foolish to ignore the good lessons we can learn from other methodologies.

One of my favorite articles of 2011 was What I Learned About the Web in 2011 on A List Apart. In particular, Erin Kissane’s call to respect complexity stayed with me all through 2012:

If a single idea has followed me around this year, from politics to art and work to friendships, it’s been this one: “it’s more complicated than that.”

It’s centrally important to seek simplicity, and especially to avoid making things hard to use or understand. But if we want to make things that are usefully simple without being truncated or simplistic, we have to recognize and respect complexity—both in the design problems we address, and in the way we do our work.

So it was with a sense of great surprise and gratitude that I responded to a request to participate in the 2012 version of that article, What We Learned in 2012. The section I wrote is entitled “Confidence versus humility”, and in a sense, it’s a continuation of Erin’s plea in 2012:

The biggest thing I learned last year is that the two most important characteristics of a good designer are ones that, at first, appear to contradict one another.

I won’t quote the section in full, because I’d love for you to check out the whole article. There are some real gems in there from a bunch of designers and writers I really admire.

It’s a somewhat uneven article, but Dave Wiskus makes some good points in The secret of Apple’s design success: the humane interface. I did get a bit uneasy when I got to this part:

Where Apple differs from its competition isn’t in aesthetic beauty, it’s in the company’s ability and willingness to make decisions on behalf of its users. […] Apple’s take is to remove complexity and make choices long before the user sees the product.

It’s an argument that’s often used by Apple fans to defend the “Apple prison” accusations — I’ve used this line of reasoning myself. But here’s the thing — and I’m saying this as a die-hard Apple fan — even though this used to be true when the iPhone and iOS first came out, I don’t think our argument holds water any more. We’re starting to see more complexity sneaking into iOS and Mac OS X, and even though the veneer of simplicity is still highly visible, there be trouble beneath the surface.

And then I read Federico Viticci’s excellent interview with John Siracusa, in which John sums up the situation perfectly:

Simplicity is great, as iOS has shown. But there’s a difference between conceptual simplicity and visual simplicity. Just hiding controls does make things appear simpler, but it doesn’t actually make them any simpler. The complexity is now just hidden. Similarly, removing features that few people use is a good idea, but like any good idea, it can be taken too far. At a certain point, you’re just making your application worse for everyone, even new users.

You can’t always tweak or refactor an existing application into the beautiful thing you’re envisioning. Sometimes the only way to achieve true simplicity is to start over with a new concept for the whole app.

The first iterations of iOS and Mac OS X were great because they did just that — they started over with a new concept. But complexity creep is inevitable, and the big challenge for Apple now is how they’re going to manage that. Jonathan Ive’s influence will certainly help, but perhaps there’s even a case to be made for (gasp!) borrowing a page from Google’s playbook.

In The Redemption of Distraction James Shelly goes into the etymology of the word “distraction”. He points out that the original meaning implies being “pulled away” from something, so the word doesn’t always deserve its bad reputation. Being pulled away from less valuable activities to focus on something with more value could be quite useful to increase productivity:

Perhaps we ought to get over our cultish demonization of distractions so that we can effectively utilize them. Perhaps we would benefit from instituting better distractions — not necessarily less of them. Perhaps the spreadsheet, artwork, or document before us needs its own interval or chime. Perhaps eliminating so-called ‘negative’ distractions is only half the story: a monastery is designed to eliminate interruptions, and yet sights, sounds, and smells are still employed to ‘pull away’ one’s focus from intruding, wandering thoughts. Such a place does not provide the absence of distraction, it utilizes distraction. Intentional distractions ‘pull away’ our thoughts from useless tangents, in order to ‘contract’ our focus back where we want it.

Of course, these days, most of our distractions are more destructive than they are productive. Jean Jullien sums it up nicely:

In The Post-PSD Era: A problem of expectations Dan Mall continues a Photoshop discussion started by Brad Frost a few days ago. Dan’s conclusion is worth pondering:

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context. If you can get your client to believe in the sales process that you’ll do that for them, they won’t care what the site looks like.

I agree with Dan’s viewpoint on what we should sell to clients, but not that they won’t care what it looks like. They always care. A little earlier in the post Dan says this:

I don’t think we’re in a post-PSD era, but I do think we’re moving towards a post-“full-comp” era.

Now that I agree with completely. At Flow our deliverables to clients have increasingly moved away from a PSD for every page on the site, to a combination of clickable prototypes, style tiles, and PSDs for key pages. Developers and Product Managers love this because they can play around with the prototype to see how the site/app works, not just what it looks like. Other decision-makers love the style tiles in particular, because it allows them to guide what the site looks like without getting distracted by the intricacies of the interaction design (which requires a different type of discussion/feedback cycle).

In other words: we should sell clients on our design process, agree upfront on what deliverables will help them accomplish their goals, and make the appropriate amount of PSDs part of those deliverables as needed.