Advice for Software Designers in 2017


  • Community
  • Design
  • How To's
  • San Francisco
  • Technology

Millsby Mills Baker
Product Design Manager at Quora
( reposted from Quora w/permission )

I’ll restrict myself to a few things I mention to new designers from time to time which they seem to find helpful; some of these apply most directly to working on scaled or social software:

It’s Rare That Inventing New Interactions Is High-Leverage. Unless you’re working on a new platform or new paradigmatic technology —like you’re an early GUI designer for the PC in the 1980s, or you’re working on VR / AR now— you should favor using whatever interactions are commodified, common, and settled. There are a lot of reasons for this. Usually it’s our best practices that are commodified, but regardless of “what’s best” users tend to master patterns slowly and with great effort, so whatever they’ve already mastered is preferable to novel solutions unless those solutions have significant, not marginal, benefits. Don’t make web readers scroll horizontally or use some 3D interface; don’t make mobile app users “force touch” to trigger a contextual menu. Nowhere near the number of people a scaled software product targets will be able (or willing!) to learn your novel interactions, even if they’re very, very cool. In sum: usability and creativity can be in tension, and we should favor usability. We’ve exaggerated the degree to which product design should be UI design / IxD. (Even our tools exacerbate this).

Relatedly, for most designers Leverage Over Existing Products Is Not Available In The UI. Rare is the scaled product which, thanks to some new gesture, affordance, visual treatment, or interaction changes meaningfully. Most of what influences these products is upstream of this: less “where should the button be” and more “what is the privacy model”; less “what does the animation for this transition look like” and more “how can we align user outcomes with business outcomes”; and so on. Snapchat’s UI is not that important; the fact that they have no profile and therefore you can’t be searched and judged by others is. We should try to learn more about business, sociology, psychology, economics, and technological history than we maybe thought we should! If we understand how development works (and fails), how people form mental models, and what the most usable patterns for our platforms are, we’ll be in good shape.

Imposter Syndrome Is Fine, As Is Its Absence. The appropriate attitude towards designing complex systems is a blend of humility and confidence. We should be humble because we’re error-prone, bias-filled, creatively-unpredictable humans who understand insanely little about the world or ourselves, working on systems no one has ever built. We’re fools who will fuck up. On the other hand, we should be confident because all we can do is try our best, make mistakes, learn, and improve, and that’s a reliable-enough path to warrant optimism. This blend of humility and confidence does indeed make you feel like an imposter, in some ways; but of course, you’re not: this is just the job. If you feel anxious because of these countervailing forces, that’s natural. If you don’t, because you accept that this tension is irresolvable, that’s also fine.

Take The World — Its People And Institutions — Seriously. Almost everything in the world can be improved, theoretically. But it’s also the case that what exists tend to exist for reasons we often cannot understand. Frequently, some solution or system has evolved or emerged over long periods of time in response to causally dense fields of dynamics and entities, and its effects are beyond our reckoning. Designers sometimes act like we’re the first to show up on the stage of history interrogating human phenomena, which is of course absurd. Something I learned from David Cole is that when evaluating an industry, commercial practice, cultural tradition, social norm, or anything else, start with trying to understand why it evolved, what problems it was the solution to, before doodling out your revolutionary improvement. Assume there are reasons —and not just shallow or nefarious ones— for why things are the way they are. And always remember that every solution brings new problems. Related to this is the fact that all problems have many solutions; in the words of Karl Popper, “Whenever a theory appears to you as the only possible one, take this as a sign that you have neither understood the theory nor the problem which it was intended to solve.” In sum: problem-solving is genuinely hard, and we mess it up all the time.

Focus On Getting Better At Thinking, Communicating, And Persuading. The technical and theoretical sides of design obviously merit the most investment, but getting better at thinking, communicating with others, and persuading others is valuable. Specifically, I tend to think designers benefit from working more on (1) epistemology and logical / methodological rigor, so they can understand things more deeply and reach more accurate conclusions; and (2) writing a lot, so they get better at framing positions and persuading others of those positions’ value. As a very simple example: I wrote Story Thought and System Thought and found many PMs and engineers receptive to this framing of what design is about (and why it often clashes with cultures emphasizing metrics and measurability); some told me they’d never thought about design this way before, whereas many designers I know basically do but have not articulated their position. Related to this: it’s important to be good with data, analysis, and research, and to know what each can and cannot help with.

Do Whatever It Takes To Connect With Normal, Non-Bay Area, Non-Technical People. Take them seriously. Respect that building mental models for your software isn’t something they have time or energy for (or interest in). Try to remember what regular life is like. Everyone knows this, says this, but as an example: if you’re making software that presupposes the value of “sharing everyday moments,” you may forget that many humans in a given day, week, even month do not visit a single photogenic or scenic or significant place, do not have a single party, do not attend a single public event (like a concert), do not like the way they look or their clothes or their jobs, are not proud of their cars, etc. And, of course, they don’t know a thing about software: even iOS is extremely advanced to them, confusing, complex. An incredibly high percentage of pitches, portfolio pieces, and startups ignore such realities.

As with any bits of advice, there are exceptions and caveats to much of this. For example, my friend Gabriel Valdivia works in VR, and in VR the work of figuring out atomic interaction elements, input systems, UIs, IxD, and all the rest is still very much happening. But for every wave like VR, there’s another like “wearables”: for some time, I saw a lot of portfolios with cool watch apps; I even had a watch app on my portfolio! But it turns out that wearables were extremely premature and remain irrelevant for almost all designers, such that investing in e.g. new interactions for watch face transitions would have been a waste of time relative to e.g. learning how humans think of status and what that means for public behaviors in social software, etc.

 


 

Mills Baker is a product design manager living in San Francisco. Before joining Quora, he worked at Facebook and a few small startups.