Trevor Connolly breaks down the myth that the Post-PSD Era means that graphic designers will soon be out of a job if they don’t learn to code. From The Post PSD Era doesn’t want to kill designers:

Designers are more important in today’s digital world than ever. You are still responsible for creating flexible design systems and finding the styles that will connect with the user. Now you just have to do it faster. By ditching the PSD and streamlining the design process, you aren’t just providing the client the value of saved time, you are making yourself more valuable. And ultimately, the real goal of the Post PSD Era is about creating more value — for your customers, for your team, and for you.

The graphic designer’s outcomes are just different now, even if they still use Photoshop. Instead of producing pixel-perfect mockups, their time is spent creating visual inventories, style tiles, and other artifacts that are essential in an atomic design environment.

Cennydd Bowles writes about data-led design vs. idea-led design in Ideas and/or data:

Product design that’s driven entirely by data is horrible. It leads us down a familiar path: the 41 shades of blue, the death by 1000 cuts, the button whose only purpose is to make a metric arc upward. It’s soul-destroying for a designer. But its moderate counterpart, data-informed product design, is fine. It reduces risk, and encourages confidence and accountability.

Product design driven entirely by ideas is equally painful. The romantic notion of design genius and the Big Idea soon gets swamped by a culture of risk, favouritism, and blame. Idea-informed product design is fine. It provides agility, creativity, the power to see blindspots and seize opportunities.

Braden Kowitz makes a similar call for a middle-of-the-road approach in Should Tech Designers Go With Their Guts — Or the Data? For an extremely practical view of using data in design, check out Joshua Porter’s excellent talk from SXSW 2011 called Metrics Driven Design. And while we’re at it, here are a couple more recent posts about using data in the design process:

• Building websites with science
• The Agony and Ecstasy of Building with Data

Working with people can be hard. Designing with people can be even harder. Designing with people who are not in the same location can be almost impossible. There’s no perfect solution for working in distributed teams, but if there’s one tool that seems to get our community further than most, it’s Trello. I’ve seen some really great Trello workflow posts over the past few months:

• How we use Trello & Google Docs to make UserVoice better every day
• Coordinating with Cards (Kickstarter)
• How We Make Trello (Fog Creek)

We have a distributed team across Portland, OR and Dallas, TX, and we use a workflow similar to the ones above, but different enough to make me think it might be worth sharing.

As background, we have a team of 5 UX Designers who split their time across 3 main products as well as our internal Pattern Library. Each product has a Design Lead (this role can rotate), and we define the Lead’s responsibilities as follows:

• Understanding and documenting user needs, business goals, and technical constraints before any design work starts.
• Being the single point of contact for any design questions by Product Managers or the rest of the business.
• Making sure Trello is updated with latest priorities, due dates, and artifacts.
• Making tie-breaker design decisions as needed and required if there are design disagreements and we can’t reach consensus.
• Designing interactions and screens, and/or implement those designs in the pattern library, and distribute the workload to other designers as needed and capacity allows.
• Explaining and defending design decisions, even at 8:30am before having a cup of coffee.

Granted, that last requirement is a bit harsh, but we set high standards for ourselves here.

Anyway. Our week starts on Thursday mornings with a Design Pipeline meeting where we go through our upcoming tasks as a team, give each other design feedback, and play with the animations in Google Hangouts. Here is a typical Thursday morning view — Trello on the left, Google Hangouts on the right:

Each Design Lead comes to this meeting with an understanding of their Product Manager’s main priorities so that we can discuss how to divide up the work. As you can see above our Trello board has 6 columns:

• Backlog: Work that’s coming down the road, prioritized every week by the Design Lead after talking to their Product Manager.
• Up Next: What we’re going to work on next once current tasks are complete. We use our Pipeline meeting to pull cards out of the Backlog and into the Up Next column.
• In Progress: In typical Kanban fashion we try to limit work-in-progress, so for a card to be in this column it really has to be in progress. During our Thursday meeting we have an opportunity to give feedback and help each other out on any questions we might have.
• Waiting/Blocked: If something can’t move forward it can’t just sit in In Progress gathering dust — we have to move it into this column. This gives me an opportunity to know where I need to get involved to unblock things if necessary.
• Done (current quarter) and Done (previous quarter): We keep two quarters of completed cards in the history, and archive further back. If everything goes into one big Done column it just becomes really unwieldy.

A couple of other random points:

• We use Trello’s color labels to indicate who’s responsible for each card, since it’s not possible to assign a single point of contact to a Trello card (unless you remove the watchers, which kind of defeats the point of, you know, collaboration software).
• We all dial into Google Hangouts separately from our desks. I find that if you have two rooms and a single dial-in it’s easy to get distracted or for side discussion to start happening. This approach puts everyone on the same playing field, and as an added bonus we can all update Trello together.

During the week we use Trello as a running News Feed of what’s happening on each of our tasks, but sometimes that’s not enough. For ad hoc design feedback during the week we using InVision, a tool I dearly love, and not just because they sent me this nice coaster in the mail (thanks guys!):

InVision is more of an internal scratchpad — a safe place where we can work together as a team and ask each other tough questions about our designs. In contrast, Trello is the paper of record for each of our revisions that we share with anyone who’s interested. It works well for us to separate those spaces out.

The combination of Trello, InVision, and Google Hangouts don’t make up for in-person time (I hope for at least some of us to be in the same space every couple of months), but it sure makes it easier than email and Lync, which is THE BIGGEST PILE OF CRAP SOFTWARE EVER CREATED.

The kicker is that our organization is finally moving to JIRA and Confluence, so we’re currently messing around with Kanban boards in JIRA to replace the Trello bit of this workflow. If we ever figure that out, I’ll write another post about. But for now, this is how we work. I’d love to see how you do it. Write a post, send it to me, and I’ll link to it here.

I don’t quite get the style of John Herrman’s Internet, Why So Blue?1, but this bit about why hyperlinks started out blue is quite interesting:

The man who invented links2 was writing them to a grayscale screen. The first popular browser, Mosaic, later turned links blue because it was the darkest color available at the time that wasn’t black; they needed to stand out, but only just. Blue was the best alternative. Blue always survives the focus group. Blue wins the a/b test. Which is convenient, because blue is usually already there.

---

1. It’s probably, once again, because I’m old. ↩

2. AKA Sir Tim Berners-Lee. ↩

Mills Baker wrote one of the best analyses I’ve seen on the the design of messaging apps in his comparison of Slingshot and Snapchat:

Snapchat seems eager to support naturalness in communication, which can be considered in terms of deformation. It wants to combat draining formalities, make it possible for all parties in an interaction to behave as they wish without anxiety, without fear of publicity or permanence, without the burden of modal moments. In other words: it wants the full range of technologies our smartphones enable to support honest, authentic, spontaneous interaction.

In contrast:

Slingshot makes demands of you for the sake of novelty, without having any organic justification for doing so, whereas Snapchat seeks to support your communicative intent without asking for justification, without even prioritizing things — like a social graph — that would be profitable for it to develop. Snapchat seems interested in helping you communicate; Slingshot seems interested in mandating engagement and experimenting with game-mechanics and arbitrary friction, in service not to your ends but to Facebook’s.

As I read this I kept thinking of Jared Spool’s view that design is the rendering of intent. Even though I don’t understand either of these apps because I’m old, it’s clear that Snapchat understands its intent and the design renders it effectively. Slingshot, on the other hand, appears to be a shot in the dark.

Tom Jacobs discusses some new research that shows people are more comfortable sharing their medical information with virtual people in I’d Never Admit That to My Doctor. But to a Computer? Sure. The implications are interesting:

When it comes to fixing our healthcare system, very few people would agree that part of the answer lies in less human interaction. Patients generally want more, not less, contact with health professionals. Yet this study suggests that, at least for the intake interview, a little less of the human touch — and a little more perceived privacy — may be precisely what the doctor ordered.

Cotton Delo in Facebook to Use Web Browsing History For Ad Targeting:

But what Facebook is now enabling is far more expansive in terms how it uses data for ad targeting. In a move bound to stir up some controversy given the company’s reach and scale, the social network will not be honoring the do-not-track setting on web browsers. A Facebook spokesman said that’s “because currently there is no industry consensus.” Social-media competitors Twitter and Pinterest do honor the setting. Google and Yahoo do not.

There’s going to be a lot of handwringing about this over the next few days. And then we’re going to forget about it and move on. I’m guilty of this myself — the number of times I’ve quit and rejoined Facebook over the last few years is embarrassing. But I do think this might be the time I unfriend Facebook1 for good. Here’s why.

I’m becoming increasingly uncomfortable with how online data collection is driving product decisions. If a product’s sole source of revenue is advertising, then the design is going to reflect that. The product is going to be optimized for data collection so that it can provide better accuracy for advertisers. And if a product’s direction is driven by anything other than user needs, that product becomes worse for end users. That is inevitable. Nothing you can do about it.

This is why the “Well, what’s wrong with better ads?” argument doesn’t hold water. It’s not that I want to see less relevant ads (or no ads at all). It’s that I don’t want a company’s design decisions to be driven by a need to get as much data out of people as possible (as apposed to how to meet their core needs better).

I think Nicholas Carr summarized the problem with this type ad targeting very well in his post A complicated courtship:

Anyone who has a car accident today, and mentions it in an e-mail, can receive an offer for a new car from a manufacturer on his mobile phone tomorrow. Terribly convenient. Today, someone surfing high-blood-pressure web sites, who automatically betrays his notorious sedentary lifestyle through his Jawbone fitness wristband, can expect a higher health insurance premium the day after tomorrow. Not at all convenient. Simply terrible. It is possible that it will not take much longer before more and more people realize that the currency of his or her own behavior exacts a high price: the freedom of self-determination. And that is why it is better and cheaper to pay with something very old fashioned — namely money.

I want to use products that I pay for, so that I can say with reasonable certainty that those products are designed based on my needs, not to satisfy the never-ending data hunger of a faceless entity.

(link via Daring Fireball)

---

1. Sorry. I’m putting myself in internet time-out for that joke. ↩

You know that thing where you get home after a long day and catch yourself some time later staring off into space, pigging out on a bag of Doritos and…? Oh, uhh, no me either. But I heard that happens to some people.

Anyway. I’ve been thinking about that phrase you always see on consumer goods packaging when they go through a redesign. The almost-apologetic and slightly nervous proclamation that even though the thing now looks different, nothing else has changed:

Clearly marketers have learned that consumers don’t like redesigns, so they started using this message in a defensive attempt to soften the blow for people. Even then, it doesn’t always work. Remember when Tropicana reverted to their old packaging because some people called the redesign “ugly” and “stupid”? We should know this by now: people have opinions, and they are going to make a big noise about those opinions.

Yet whenever we go through a website redesign process we appear to develop some amnesia around this topic. We seem surprised when people spew vitriol all over Twitter, and we try to make ourselves feel better by saying that they’ll “get used to it.” Some part of me really wants us to create “Bold new look, same great functionality!” gifs for those kinds of projects, in the spirit of the “Under construction” gifs of yesteryear. But just like in the case of Tropicana, I don’t think that will work.

What’s the alternative? Well, first, we have to realize the biggest problem with big web/app redesigns. It might be the same functionality underneath (or not), but that functionality is often harder to find, and that frustrates users to no end. The good news is that we work on the web, not in packaging. We can do things incrementally! In the words of Cameron Moll, “Good designers redesign, great designers realign”. I’ve also written about this before in The Data-Pixel Approach To Improving User Experience:

The main problem with big redesigns, therefore, is that, even though objectively the UX might have been improved, users are often left confused about what has happened and are unable to find their way. In most cases, making “steady, relentless, incremental progress” on a website (to borrow a phrase of John Gruber) is much more desirable. With this approach, users are pulled gently into a better experience, as opposed to being thrown into the deep end and forced to sink or swim.

Look, I’m not saying this is a perfect analogy. But I spent a lot of time spacing out about this on Friday, so I thought I’d write it down for posterity. What I’m trying to say is, let’s worry less about bold new looks in web design, and instead work on making things taste better.

We’re in the process of hiring UX designers and Product Managers, so I’m currently looking through a lot of resumes. I’m finding the breadth and depth of UX resumes really impressive — there are a ton of great people looking to make a shift at the moment. But on the Product Management side, not so much. I don’t want to believe it’s because most Product Managers suck. I just think there is a big supply/demand issue in this area at the moment.

But not just that, I also think that Product Managers need to write better resumes. Designers have, for the most part, figured out that it’s more about showing than telling. It’s easy to go to someone’s sites and portfolio to get a sense of what they’re about. Product Managers still appear to be stuck in the “Let me tell you how awesome I am” rut, though. This is a generalization, of course, but what I’m mostly seeing right now is resumes that excel at vagueness. It’s not uncommon to see a sentence like “Applied world-class methodologies to create a successful customer-centric product”, or some variation of that. What does that mean?

It’s great to see proof of success, yes — stats about conversion improvements, etc. are extremely useful. But hiring managers need more than that to assess Product Managers. We need to know how you think. We need to know how you approach problems, how you work, what methods you like and don’t like, and why. And for some reason most PMs I speak to seem surprised by those questions and have trouble answering them.

I’ve now gone so far as to send a short list of questions to our HR department. I’ve asked them to forward these questions on to potential candidates, and send their answers to the hiring team along with their resumes. So I wanted to share those questions here in case it’s useful to PMs looking for a new opportunity. This isn’t an exhaustive list, but here are some of the questions Product Managers need to be able to answer at any time of day or night:

• How would you describe your ideal product development process? Please share details including, but not limited to, the following:
  • Roles and responsibilities within the team
  • How to develop a strategy and vision for the product
  • How to decide what to build, and when (include thoughts on different prioritization methods and, in your experience, what works best)
  • Development methodology
• In your experience, what are the most important characteristics of a good Product Manager?
• In your experience, what are the conditions for success that have to exist in an organization for a Product Manager to be successful?

This is one of those classic “there is no wrong answer” situations. The absolute answers matter, but what matters more is the thought process. I want to hire PMs who think about these things. PMs who have an opinion on UCD vs. ACD. On Kano vs. KJ prioritization. On user stories vs. job stories. I want to work with people who read and think and build, and have found a way to balance those different activities effectively.

So, if you’re looking for a Product Management role, communicate those things to the recruiter and/or hiring managers. I’m pretty sure it will get you an interview. Oh, and if you want to move to Portland to help us make better healthcare software, and you have good answers to those questions, let me know!

I found Ellis Hamburger’s view on what’s wrong with Facebook quite interesting. From Facebook’s friend problem:

In the real world, losing touch with people happens naturally and effortlessly, but on Facebook, unfriending is reserved only for breakups and acts of malice. So, the ghosts floating through my News Feed vastly outnumber the friends I’ve kept. My Friends list went from a roster of my current friends to a collection of everyone I’ve met in the last 10 years — a social group too massive to feel urgent, and too broad to share with on a daily basis.

Facebook is broken for its earliest users, and perhaps soon, for many of its new ones as well.