<p>Published on <a href="http://ift.tt/2oSwDnL">| Prototyping: From UX to Front End &mdash; Medium</a> Jess Holbrook <img alt="" src="http://ift.tt/2oPhnZ5"><a href="http://ift.tt/1rvHtYh">http://ift.tt/1rvHtYh</a></p>
<p>There have been many articles over the past two years or so articulating UX teams’ design processes, usually coinciding with a big new product launch. I personally really enjoy these views into how different teams approach their work and when people share these stories they help our community learn and grow.</p>
<p>Something I’ve noticed in just about all of these articles is the mention of <a href="http://ift.tt/1a2OUyX">design principles</a> (aka UX principles) as part of their processes. I’m a big fan of design principles. When used correctly, they can help a product designed by dozens or hundreds of people feel like it came from one POV.</p>
<p>However, I have a particular point of view about what makes design principles effective vs. just some platitudes. I’d like to review the ones I call “platitudes” and why they are ineffective and then offer what I think effective principles have in common.</p>
<p>Let me start with the most ineffective ones I see all the time.</p>
<h3>The platitudes</h3>
<h4>Simple</h4>
<p>This tops soooooooooooo many lists I’ve lost track.</p>
<p>There are two problems with this one. First, no one is trying to make a product complicated. Complicated is bad, everyone knows that. So why do so many experiences end up so complicated? I think it’s because there’s an important difference to understand between “complicated” and “powerful.”</p>
<p>Teams are often trying to make a product or feature more “powerful” by adding features, options, choices, etc. for users. This is always seen as addressing additional user needs, matching competing products’ feature lists, or giving users options they will appreciate. All good things right? Well you include enough of these and the product becomes complicated <em>for where the user is in her journey</em>. Yes, those options may make sense after gaining more experience or in particular situations you can dream up, but be aware your design may be getting ahead of your users. Any feature people don’t use didn’t add any power.</p>
<p>Second, I actually think “simple” is the wrong goal for many products. It’s pretty easy to make something simple that doesn’t do much and isn’t that enjoyable:</p>
<p><img alt="" src="http://ift.tt/2nXR4fv">Oversimplified from <a href="http://ift.tt/2oe9LfJ">http://ift.tt/2oe9LfJ</a></p>
<p>I think when people say “simple” they really mean “<strong>clear</strong>.” They mean something along the lines of “everything is where I expect it to be and does what I expect it to do, so it <em>seems</em> simple to me.” This is about clarity, not simplicity. For example, kitchen setups can include many tools and ingredients but still be perfectly <em>clear</em> to the user (cook or chef).</p>
<p><img alt="" src="http://ift.tt/2oPd28o"><a href="http://ift.tt/2nucLHU">http://ift.tt/2nucLHU</a></p>
<h4>Easy</h4>
<blockquote><p>“Oh good catch, I was trying to make everything really hard, let me just update the mocks.” — Sadistic Designer</p></blockquote>
<p>As with <em>Simple</em>, a common culprit here is people trying to “put the user in control” by adding more options and choices. This well-intentioned path takes a lot of products from easy-to-use to usability-train-wreck in a series of small steps no one notices, except for your users.</p>
<p>Making clear when, where, and what kind of control has <em>priority</em> in the product is a much more effective approach.</p>
<h4>Fast</h4>
<blockquote><p>“NOOOO, make it SLOWRRRR!!” — No one designing a product ever</p></blockquote>
<p>As with “Easy”, products often get slow because of feature creep, rushed implementations, and legacy code. Making something fast is as much about your team’s approach to product decisions as it is about milliseconds. Remember that there is latency and <em>perceived latency</em>, and you can affect both.</p>
<p>Ask yourself and your team, what decisions are you forcing users to make? Are you making them sign-in on their first visit to your page? Can they skip the tutorial? Can they change the default landing page? Are you using data from their previous use to make their current session more efficient?</p>
<p>Ask yourself and your team, what are you willing to give up for faster?</p>
<h4>Smart</h4>
<p>Sure yeah, I love smart things. Dumb things are so dumb. What this product-that-is-already-working-just-fine needs is to be “smart.” How about we add a location tracker and send people notifications when their toast is ready?</p>
<p><img alt="" src="http://ift.tt/2nXUH4V">Oh, you thought I was kidding? <a href="http://ift.tt/2oe9cCE">http://ift.tt/2oe9cCE</a></p>
<p>Often “smart” ends up meaning “has a screen” or “has an app” or “has a screen and an app.” This is pretty far off the mark.</p>
<p>If you can get past the screens and apps, “smart” seems to often be code for “predictive” or “actually uses all the previous data we’ve collected from users to tailor the experience to them.” Definitely, be that kind of smart, but please don’t think because a product doesn’t have wifi, a screen, or an app that it’s dumb.</p>
<h4>Personal</h4>
<p>Maybe. Like with <em>Smart</em>, this usually means “can we please actually use the data we have about a user to make things more efficient or relevant for her?”</p>
<p>One test of an effective principles is to ask is anyone in favor of the opposite? (more on this below) Is anyone saying, “no, we should make it impersonal”? That may actually be the right call for some experiences, but for just about any situation where there is previous user data, markers of intent, or preferences that could be known, the experience should be personalized in a way that helps the user accomplish her goal.</p>
<h4>Delightful</h4>
<blockquote><p>“Can we amp up the unpleasantness? I’d like to see some options devoid of humanity.” — Worst PM ever</p></blockquote>
<p>I personally think having <em>Delightful</em> as a principle is a distraction for all but a handful of products. I’m not saying products shouldn’t have delightful moments. But having “Delightful” as a principle makes everyone look at what they’re designing and think about how their piece of the whole can be delightful. That rarely leads to a whole lotta delight. That’s kind of the catch. Delightfulness has to be a bit out of ordinary, a bit unexpected, in the right amount, and timed just right so people are open to that delight. Not getting slowed down by a smiley emoji animation while they’re trying to complete a task that should take 5 seconds tops.</p>
<h3>What effective principles have in common</h3>
<p>So I hope I’ve made my case against principles that are ineffective because they are really platitudes (and I didn’t get too ranty in the process). If you agree with me so far, you’re probably wondering, “OK so what makes for good principles?” Well, a few things.</p>
<h4>Created from unique data and insights</h4>
<p>This is the foundation of the insight not everyone else has mentioned above. This is how you know you’ve figured something out other people haven’t. This is your deep knowledge and empathy with your users or customers. This is your special sauce. This is your competitive advantage.</p>
<h4>Make choices obvious</h4>
<p>If you can’t collect user feedback or data on a decision for whatever reason, will this principle help you make a consistent and coherent set of decisions? Will it help you prototype ideas along an informed trajectory in between user research studies? Put another way, given a few options, does it make one of them the obvious choice?</p>
<h4>Verbs, then nouns</h4>
<p>Principles should ideally be directing you do something, not offering an ideal outcome you aren’t clear how to get to. This is one of the problems with platitudes like <em>simple</em>. OK, great, sounds good, what decisions do I make to keep the product simple?</p>
<h4>Someone should disagree with them</h4>
<p>Actually a bunch of people should. A good principle should reflect an insight not everyone has. It should lay out another way to frame the decisions you’re making. This inherently challenges the current thinking of the group. Otherwise, you’re just laying out table stakes product requirements or as we say in the US, “motherhood and apple pie.”</p>
<h3>Clear?</h3>
<p><img alt="" src="http://ift.tt/2oP0rlE">Thank you Internet. <a href="http://ift.tt/2nu9l85">http://ift.tt/2nu9l85</a></p>
<p>That’s my take on what makes for ineffective and effective design/UX principles. So what do you think? Agree? Disagree? What are your favorite principles? How do they stand up to these criteria?</p>
<p>Let’s discuss some examples in the comments.</p>
<p><em>P.S. After writing all of this out, I found </em><a href="http://ift.tt/2lnP5PH"><em>Anton Badashov’s great collection and review of design principles</em></a><em> from many companies. He and I agree on many points in this article and I recommend you read his article as well if this is an interesting topic for you.</em></p>
<p><img src="http://ift.tt/2nXS5Em" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="http://ift.tt/2oP86jK">Principles, not platitudes</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


Principles, not platitudes

Top Stories