Design – PM'ing

Make the easy stuff easy and the hard stuff possible.

Open source software sux at UX. Why?

Lots of reasons, of course, but one is that these interfaces and their creators are often focused on users abilities, and the full expressiveness of the software’s functionality, not on the users’ needs or capabilities.

For example, often, the free software drive to make everything controllable by the user leads to an approach to interfaces that make all that is possible, visible. They treat all functions equally, since the goal is just to provide all the tools and let the liberated user decide. This equality of features often also leads to interfaces that lack clear hierarchy, or are overloaded with menus, options and configuration preferences. Lastly, in these projects, design and particularly visual design are “extra”, and often not in the skill set of participants. The reasons for that are, really, I think, a separate discussion, touching on the gender of aesthetics and traditional roles in software.

But, all that said, full user control is a value worth preserving as software evolves. It’s something people who focus on licenses and patents as the core of free technology lose site of: if software is truly libré, everything a user wants to do, or change, should be possible, even if it is hard. Software may be freely licensed, but if it is impossible to use, or very difficult, is it really free for all? If it is to be a real practical freedom, free software must also be useable for all.

Finally, for software to be broadly successful, it needs to be not fully featured, but useful. It need not be fully customizable, but it must be intuitive. So how do these tensions get resolved in a way that pushes free software forward?

Larry Wall has a phrase that he applied to PERL, but could also be applied to open software interfaces: make the easy stuff easy and the hard stuff possible.

This is the way to bridge these tensions: make the things people most need from the software easy and intuitive. Don’t make the user invest in configuration, or understanding complex metaphors, or unique interface paradigms. But also, make the hard things possible. Don’t enclose everything in black boxes and “smart settings”. If the user wants to turn something off, let them. If they know better than your recommendation model what they want to see next, let them manage their own queue. For everything you make easy, also make it controllable, and understandable. Then it will be truly free.

Contending with contemporary methods in design

If you’ve worked with designers, researchers or product managers who’ve been educated in, or advocate for “user centered design”, you’ll know it is well worth researching and learning about this philosophy and the processes it advocates. If you haven’t, see this standardized summary and this video by way of introduction. The original, complete, user centered design process is quite full and nuanced, and like many development and design systems it is rarely (never?) fully and completely implemented as envisioned. However, many of its methods and ways of thinking are useful, even without full adoption of the entire program.

Below, are some thoughts on some of these methods (not the program as a whole) and the good and bad of them, and how to deploy them effectively.

One of the main related methods of user centered design is user testing. This is the most important thing you can take from this. Watch users use your product. There are services and firms that can help you, but even you (yes you!) can record and observe a user while they use your product. Don’t intervene, don’t let them see you. Then ask them questions when they’re done. It’s never not informative.

I love user testing, and have used, and advocated for it, since I learned about it. But it is focus grouping. It will reduce the risk of confusing or failing the user, but it won’t find a compelling use case. Just as a focus grouped movie is less likely to fail, but focus grouping is unlikely to turn a shitty movie into a hit. You still need the need discovery. In user centered design they advocate for a generative research and prototyping process to achieve this. Personally, I’ve never seen such a process uncover a need that cognitive empathy with a well developed persona could not. But obviously these methods have been quite successfully applied by some. It does provide a lot of evidence for needs, though.

Which brings us to personas. Personas are archetypal users that represents a defined audience or role in the system. Often these read like the product of a marketer’s imagination, and that is indeed their origin. Usually they come with some cheesy name (“The Megainfluencer”, “Soccer Mom”, and so on) and some demographics. Even when developed specifically for your audience, I’ve found these to be of less value than user testing. Often they are good for organizing and explaining the product or its user stories, especially in documentation, but less valuable for decision making, or actual feature development. There, they can help develop empathy, and also help give focus and reality to stories and features. But I’ve been involved in very few systems or contexts where rich personas were more useful than just simple names for roles and user types, and associated needs or stories. I’d also strongly urge caution if using personas without real training in user centered design or marketing, especially if the personas involve people unlike yourself. It is very easy for a well intentioned amateur persona to become indistinguishable from an offensive bundle of stereotypes that reinforce bias rather than develop empathy.

Camp Software

Wikipedia explains that camp is:

“an aesthetic style and sensibility that regards something as appealing because of its bad taste and ironic value. Camp aesthetics disrupt many of modernism‘s notions of what art is and what can be classified as high art by inverting aesthetic attributes such as beauty, value, and taste through an invitation of a different kind of apprehension and consumption… Camp aesthetics delights in impertinence. Camp opposes satisfaction and seeks to challenge.”

Camp is often applied to visual, performing and conceptual art, along with lots of movies and TV, restaurants and experiences. RuPaul is campy, John Waters is campy, Benihana is campy, an art car is campy. But can it apply to software? Can you make meaningful or even “popular” software that “opposes satisfaction”? This website’s own home page was my attempt to work in an aesthetic I thought was so ugly it might actually be cool and to oppose satisfaction by providing only the shallowest of explanations of what Jiko Kanri is.

But there has to be much more out there. Apps with ironic look and feel? Does that count? Or tools made intentionally hard to discourage their use. We’ve all seen web sites we could easily describe as “over the top”. Every Chinese social app I look at seems to be inverting the normal values of software design to stuff the screen with every function and text it can find a few pixels of space for. Is that camp? Is Snapchats “old” unfriendly, gesture heavy UI and attempt to be impertinent and to challenge users to learn new things through word of mouth, excluding the conservative of habit and the un-networked user. Is that camp?

One effect of the usefulness of software, and its categorization as a medium for tools and games, is that media theory, which is rich and insightful about movies, TV, news, music, you name it, seems to treat software as outside its view. Website and trends might be analyzed and deconstructed. But non-game software is not subject to the same level of critical and analytical thinking. I enjoy watching YouTube videos by movie and cultural critics. These lengthy reviews, analyses and essays are interesting, insightful and show how media like TV and movies work. How much of that is possible for software? Most software videos are tutorials or shallow reviews. I understand these apps are tools.

But I also know: Software is a medium.

I want a more popular, useful, fun, interesting media study of it. And I want to see weirdos like me celebrating software so ludicrous its tragic, or so tragic its ludicrous.

Keeping designers in their place

This is one of a series of essays about how to relate to common stakeholders. Here, I’ll provide some tips for working successfully with designers.

The relationship between the designer(s) and pm is the determining factor in user experience. Their mutual understanding of the user is the software’s understanding of the user.
Hopefully, it goes without saying that design encompasses more than how the buttons will look or what font to use. UX is not visual design. But it is metaphors, aesthetics and taste.
If you have a good designer let the designer own the experience. Just set the stories and the priorities and let them go. If you have a junior, outsource, or less talented designer, still let them go first, but expect to edit and iterate a lot. If you do wireframes to convey the story or experience you want, either do it very low fidelity (whiteboard, etc) or give screenshot examples. If you’re doing high fidelity mock ups or prototypes, you’re a designer. Thats cool, you can be both, or may have to be, but those are design thinking tasks.
Good, compelling, design is about a single vision or aesthetic shining though in a collaborative medium. Even in software, it’s easier to understand and transmit emotion via a single designer than a committee. If your product has had many brand, design or designer changes over time, consider the potential value of a normalizing effort to unify the look-and-feel.
Designers are often emotional; creative people need to be passionate, but can also be dramatic. Just accept it. Don’t over-react but don’t treat their feelings as invalid or unreal. They are very real to them.
Many designers, especially the young and inexperienced (or lazy) will give you one design and say “here’s the design”. Make them show their process. Like checking in source code and breaking down programming work into milestones, designers should be able to share their ideations, helping the team understand not just what they are proposing, but how they are got there and why they are not proposing other ideas.
In complex software designers are often working on features or interfaces in isolation. It’s vital the PM work with design leadership to keep the holistic user view and big picture (how interfaces interact, patterns/metaphors/components consistency, and building shared intuitions) and most of all, priority. Design is prioritizing things visually and in terms of the interactive space (how much space to give to each potential user action, what gestures will do what, which actions to make easy or hard). The clearer you articulate your user’s priorities and hierarchy of needs to the designer, the clearer that should come through in the interface. Do the designs priorities match you’re users priorities?
Don’t let design determine the roadmap. Design is about how the user experiences the product. Product should always own what the team focuses on and why.
Provide an incidental creative outlet (team schwag, internal logos, UI of internal tools). Ask/expect them to own the visual space of the team, in whatever form.
Know basic design jargon like you should know tech jargon: visual hierarchy, wire frame, high fidelity, evaluative vs generative design research, what the hell is an affordance?

A Matter of Taste

Steve Jobs once famously said on 60 Minutes that Microsoft had no taste and its products were unoriginal and culture-less. In his usual, insightful douchebag, way Jobs was articulating an idea that I think is paid lip service, or even attacked, but rarely engaged with in a meaningful way. That is, what is the role of “taste” in a software product’s success and a team’s process? What is taste, anyway?

First, I take taste, as used by Jobs here, to mean an understanding of what users want and expect, and how to make things that are not just satisfying to their needs, but appealing to their senses. Tasteful things affirm their owner’s sense of self-identity and make an emotional connection with them, over and above the thing’s basic utility. This talent/skill is often derided as hopefully squishy, unscientific, qualitative and arbitrary. But, I would argue that is a misunderstanding of taste by those who don’t have any. Taste doesn’t have to be a golden sight that some people have and others don’t. Or something that is so unpredictable as to be anathema to risk management. Taste is merely a predictive skill. One that, yes, some people are more talented at naturally, but which is not some magical, ineffable, quality. Just as antique experts can get better at predicting auction value, or top chefs can sometimes predict which new flavor profiles critics and diners love. It takes stepping back, doing a neutral analysis and introspection of your work. But even more importantly of your product peer group. Develop taste by practicing thinking “what do I like about this and why?” Develop it by seeing what really sells. Develop it by measuring feedback and understanding audience trends. It’s not some artsy fartsy nonsense. Learn what you like, and what others like. You’ll never be right all the time, but you can get better at it through focused intention, and attention to detail.

Most of all, I think this quote plays into the theory that being a great PM is a craft. Making something carefully, thoughtfully, that’s not just useful, but in some way beautiful, touching or meaningful. The kind of object or experience people will collect or remember. To have good taste is to know what will be compelling. Not just on first use, but in a way timeless, as much as software can be. Build your intuition for what is a flashy trend, and what is a good new paradigm that will be around for a long time.

Finally, this quote reminds me that, although I’m not a designer, aesthetics matter. What your design says to your users speaks louder than the copy on the screen. If you are building software with user interfaces, design is not an afterthought, or coat of paint on the machine of your engineer’s code. It is the thing that separates Apple’s best iPhone from Microsoft’s worst Zune. The Zune played mp3s fine, but it was in bad taste. If you’re not naturally a visually artistic person, that’s okay too. Hire one. Or work to develop your taste. Take a drawing or photography class. Go to art museums (especially modern or contemporary). Ask your designers about the designs they love and why. When you see something that you think is beautiful, don’t just pass it over. Stop, think, introspect. It’s not a magical blob of irrational emotional noise, untamable by analysis. Aesthetics are not random, there are patterns and you can learn them. And even more fun, you can feel them, if you care to.

So give taste a chance. Embrace your own taste (or acknowledge your lack thereof) and always work to understand not just what will help people, but will move them.