Interface Inconsistency is Killing You

Posted on by krys
Kaylee the Frug puppy

My puppy Kaylee is worried about your interface.

Consider this an intervention.

There are a lot of reasons your interface can become inconsistent.  That ONE page needs to have a 24pt headline because it just doesn’t look right in 22pt. Designer 2 doesn’t like the loading spinner that Designer 1 made for their section of the site, so Designer 2 makes a new one. Designer 3 doesn’t know you already have a progress bar design, so they make a new one. There’s a new and awesome technology that’ll save you a ton of time so you implement it on new features and it’s got some UI baked in. You’ve redesigned and all the new pages are going to use the new look. Etcetera, etcetera, etcetera. (Yes, I wrote that in Yull Brynner’s voice.)

But just stop it.

You see, interface inconsistency is bad for ALL THE REASONS.  It’s tech debt. It’s cognitive load. It makes your site look unprofessional. It’s hard to QA. It’s embarrassing, for Pete’s sake.

So, how do you correct it?  And once you’ve gotten your site clean of this poison how do you prevent a relapse?

One step at a time

Think of inconsistency as an addiction. Addiction to form over function, or quick over quality – it doesn’t matter. You need to approach it the same.  First, admit you have a problem. Tell everyone who will listen (internally – let’s not air our dirty laundry!) and get them to help you take stock of the problem.  How many button colors do you have. How many font sizes?  How many types of popups?  How many ways do you say “buy”?  How many shades of grey are you using?  (I kid you not, I once worked for a company that was using 23. We narrowed it down to 6)

After you’ve made your list, you’ve got to start cutting back. Who should be the head pruner depends on the organization, but I tend to feel it’s the owner of the overall design – so, a director of UX or a lead designer or whatever your company has that serves as a Design Poobah. They’re going to add another silly Silicon Valley title to their skillset – Consistency Czar. If they’re smart, they’ll involve other designers and maybe even a product manager or two in the process, so that they’re not shoving decisions down peoples’ throats later.

Pruning usually goes one of two ways: You can either choose the few versions of each thing that make the most sense for your brand, or you can choose the version that’s used most often. If one version is more usable than another, choose that one. Be ruthless. You don’t need 23 greys. You probably only need 3.

Once you’ve decided what’s canonical and what’s apocryphal, you need to communicate it like crazy. Remember how you told everyone you were an inconsistency addict?  Now you need to tell them you’re in recovery. You need to push the consistency agenda like it’s an election year and wealthy donors are standing by. If you have multiple designers, make sure the whole design team knows what you’re moving forward with and what you’re sunsetting. While you’re at it, make sure the engineering team is in on the fun too. You’re about to ask them to retrofit some code.

Once the communication is done, you need to start acting. This is where your partnership and good relationship with your developers comes in handy, so I really hope you’ve built one.  This is truly where the withdrawals hit in my addiction metaphor, because it’s the painful phase.

How you structure cleaning house into your roadmap will be unique to your organization, but the devs will ultimately be deleriously happy to be able to get rid of extra stuff.  If you have a hard time selling them on the idea, tell them three things:

1. Consistent sites have reusable widgets that can be maintained and shared.
2. Consistent sites load faster and that helps everything from SEO to performance scores to bounce rate.
3. Consistent sites are way easier to upgrade later.

Put your ego away

Once you’ve started the process of pruning out the apocryphal versions of your widgets, text, icons, colors and other code noodles, you automatically enter the next phase: relapse prevention.

When you’re designing a new feature, refer to your styleguide, pattern library, UI library – whatever you use to document your design decisions. When in doubt, just go click around your own site and talk to people who are designing stuff too.  Before you add a progress bar, check to see if you’ve got progress bars anywhere already.  If you do, USE THAT ONE.

If you don’t like that one, DO NOT design a new one unless you first get agreement from everyone including developers to change the original too.  You heard me right.  Use stuff you hate unless you’re willing to make changes to all instances of a thing. It’s better for everyone involved, because your developers are not going to trust you if you make them go through a big consistency project every two years. Not to mention the executives, who will wonder why they have to keep spending money to fix something they already fixed.

When you do design a new feature, make sure you share it.  “Hey everyone! We didn’t have a slider widget so I designed one. Here it is for you to use!” is not only a great way to ensure consistency, it also saves other people future work and plays a PR role in letting people know what you’re doing. Never underestimate the value of good internal PR.

Everyone is a sponsor

From the moment you realize your site should be more consistent, every single employee of the company should be deputized as a consistency sponsor. While ultimately, it’s the designer’s call whether to introduce new styles and elements, every product manager, developer, executive, and admin should speak up if they think they’ve seen an inconsistency. The designer will either justify it as necessary, or fail to justify it and need to change it.  Either way, users win and engineers don’t waste time building bad things.

Today’s Interesting Link:

How much to make – This is all about the broad strokes, of course, but it’s fantastic as a way to get you thinking about whether or not you should be building a mobile app, vs making a properly responsive site.

 Today’s Usability Quote:

“Know the rules well, so you can break them effectively.” – His Holiness the Dalai Lama

Today’s Music To Design To:

I’ve lately found that Erasure’s Wonderland, from 1986, is amazing for driving you through heavy workloads and crushing deadlines. It’s high-energy electro synthpop, in case you’ve been living under a rock and don’t know this seminal album.

 

Artistic Freedom is Bull$#!+

Posted on by krys
Streetlights in fog

Streetlights in fog

The other day, a wonderfully well-intentioned developer said to me, “Designers shouldn’t be limited artistically. If designers are thinking about how we write code they’ll be less creative and they won’t have artistic freedom to make the best designs.”

Bless his beautiful heart, he’s wrong.

Let me just put this here, in case I haven’t said it enough times. UX Design is NOT art. User experience designers are often artists, but the concept that they need or should have artistic freedom is completely invalid. Let’s examine.

1.  Art is an expression of your vision.  User Experiences are not about YOUR vision, they’re about your users’ needs.

You have to be willing to put your own preferences aside as much as possible and cater to the audience. Otherwise, people won’t use your product.  And what’s the point in a product no one uses?  To be indelicate, it’s designurbation.

Let’s face it – we all have side projects.  Hobbies, personal sites, etc. Those are the place, arguably, to practice artistic freedom. Not on your poor users and developers.

2. UX design is science, and subject to being tested and measured. 

It’s not really artistic freedom anyways, if the metrics say that my arbitrary giant green text with the lovely fading background doesn’t convert. Metrics are king, after all, and to be a professional designer you need to submit to the measurement of and subsequent improvement on your work.

3. Users don’t notice most of the incredibly subtle things that designers are passionate about.

I have never seen a non-design user ask for greater text kerning, or wish that line were one pixel wide instead of three.  They just don’t care. It’s arrogant to think that one out of ten tiny details is going to make all the difference for the average user.  Now, don’t get me wrong – the aggregate of those ten is what makes the difference and it makes all the difference in the world.  But if for some reason you have to give up one, it’s not the death of aesthetics. It’s just a crack in the china no user is probably ever going to see.

4. Usually a scientifically sound and consistent approach solves the problem as well as, if not better than, a random and arbitrary but beautiful design.

The scientific method, in case you weren’t exposed to this a zillion times in school: Hypothesize, Experiment, Measure, Re-hypothesize, Experiment, Measure, etc.  Beautiful designs might or might not test well with non-designers. More often than not, actually, plain or sometimes even ugly designs win the day. Users like simplicity and clarity and there’s an elegance in plainness that often triumphs. You can’t know unless you test. You can’t win unless you are willing to change your designs to fit the results of the test.

5. Disciplined design is easier for a user to get used to, and creates a subconscious level of trust and enjoyment in the user.

Consistent interfaces are easy to learn. It’s just that simple. So even if you didn’t design the most beautiful perfect charming icon for that action, as long as the ugly button is consistent your users are going to be able to find it and use it.  Probably. Would it be better if it was consistent AND beautiful? Oh yes.  But the consistency thing is the key. And the only way you can have consistency is if you think about EVERYTHING and give it rules.

6. Disciplined design is faster, allowing teams to produce more without reinventing the wheel.

If my dev team knows that my leading will always follow a certain formula, they don’t have to spend time measuring pixels in my psds to see what the line-height will be.  If they know that I am always going to use a certain font, they can code it into base classes and forget about it.  If I always use the same conversion widget, which I’ve tested into and proven works, they will be able to modularize it.  Think of how efficient your teams can be, if you give yourself constraints.

7. Designers need to consider themselves servants, not presenters.

User experience design isn’t about showing off.  That’s why the geniuses aren’t household names – my aunt has never heard of Jony Ive or Dieter Rams or even Luke Wroblewski, that dynamo of UX mastery.  UX is about receiving information and turning it into knowledge, it’s about looking at the complex upside down and making it simple.  That’s why we are servants – our whole reason for existing is to get the hell out of the way and facilitate communication between humans and computers.  Not humans and designers and computers; humans and computers.

8. Designers can be happy working within constraints.

Constraints challenge us. Especially when they’re self-imposed, we love them.  Why else would someone decide to build a replica of a church using matchsticks? Why else would LEGO be so popular? Constraints let us stretch our muscles in a way that keeps us from getting lazy and complacent.  They make us THINK, and we’re all thinkers, we UXers.

Summing Up

I’m always wordy. The TL;DR is totally that while User Experience designers should have some freedom of judgement and aesthetic, more than a little is actually harmful to everyone involved. UX is more science than art, and should be approached with the rigor that the scientific method supplies.

Today’s Interesting Link:

Underscores – This is a fantastic framework for wordpress.  Regardless of your opinion of WP as a whole, who doesn’t love a framework generator that leaves you complete control of the look and feel?  It’s a great place to start.

 Today’s Usability Quote:

“Creativity is intelligence having fun.” – Albert Einstein

Today’s Music To Design To:

Lindsey Sterling has a new album – Shatter Me.  It’s fantastic.  I’ve recommended her before, but lately I’ve had Shatter Me playing while I design and it’s total awesomesauce.  Think violin, with a strong electronic beat in the background, and occasional guest vocals that really blend perfectly. This is not your grandma’s violin, and Lindsey is totally not your grandma.  :)

 

Inside the Workflow: Sketching on Whiteboards

Posted on by krys

Today I want to give you a peek into my workflow, literally.  Here’s a picture:

Picture of my monitor and a whiteboard

Tackling the challenge

A product manager challenged me to incrementally improve an existing internal tool, keeping the potential engineering points very small.  He gave me the following constraints – I couldn’t remove any information from an already crowded search result list.  I had to add two additional pieces of information, and I could not use progressive disclosure – all information/functionality had to be visible at all times.

After I fought and lost the Get Rid of Information and Use Progressive Disclosure fights, I buckled in to work on a way to lay out this information and functionality in a way that would let the users quickly scan and act upon the data.

Like most designers, I think in pictures.  So, I whipped out my trusty UI Stencils Whiteboard and started sketching.  I used different color pens for each option and just started drawing every single idea that came into my mind.  I knew I couldn’t change things drastically, so I just pushed stuff around, played with encapsulation, played with methodology, and toyed with size and color.

You can see the result of my design work in the back, comped in situ in the page where it lives.  This may not be the final design – now it’s time to show it to my users and see if they can find everything they need to find in the list.

I’d really love for you to take two lessons out of this.

First, take the time to focus individually on every aspect of your page – even a list which takes up 25% of a whole deserves to be broken out of its context and explored in depth.

Second, there is no replacement for the speed and flexibility of sketching.  Since trees are a limited resource and tend to be much prettier when providing shade, save paper by using a whiteboard.  Plus, then you can erase the crappy stuff and there’ll never be any evidence that you had an idea that bad.

Today’s Interesting Link:

CompressPNG.com – This website is so slow that I actually forgot about it.  BUT, it did compress a PNG from 756K to 250K with no loss of quality at all.  Can’t shake a stick at that.  Just upload up to 20 PNGs and walk away.  Have dinner, come back, see compression.  It’s a bad UX, but a useful tool.

 Today’s Usability Quote:

“Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove.”
-Antoine de Saint-Exupéry

Today’s Music To Design To:

Brian Hazard is an old acquaintance and he’s been making music for ages.  Color Theory is his one-man musical escapade, perfectly named to be designer music.  Expect electro synth-pop for the old stuff, and slightly edgier, industrial shininess for the newer stuff.  My favorite album is Sketches in Grey, which if I remember correctly is the first. But it’s probably not the best, it’s just the one I like most.

 

5 Ways To Make It Safe to Fail

Posted on by krys

“The biggest risk is not taking any risk… In a world that is changing really quickly, the only strategy that is guaranteed to fail is not taking risks.”
-Mark Zuckerberg

“If you want your team to succeed, create an environment in which they are encouraged to fail.”
-Me

Today I want to talk about something really, really important.  I want to talk about screwing up.

I do it.  You do it. Everyone you know does it.  We all make mistakes, forget things, try things that don’t work, or otherwise fling poo at our batting average. It’s important that we admit that, and accept it, and plan for it. That “plan for it” part is the hardest one, and it’s the one I want to focus on.  Because you should be focusing on it too.

People in a creative role are not flawless.  Whether that’s a design role, product management, or development, they miss little details from time to time.  They work long hours and forget to close a tag.  Or they try something that research or instinct tells them will work, and it doesn’t.  It’s only through these mistakes that they learn and get better.  And it’s only through taking risks that they can discover the insights it takes to win big.

So, if people aren’t flawless, and you want them to do great work, then you need to make it ok for them to mess up.  Here’s how to create an environment that fosters calculated risk-taking:

1 – Turn off the bozo switch

We’ve all been in companies where there is a “bozo switch” with a hair trigger.  If you do one thing less than perfectly, they’re going to think you’re an idiot for the rest of your life. Screw up once, in a small way or a big one, and you’ll never be given the chance to succeed again. How did you feel there?  Were you energized, enthusiastic and ready to take the risks needed for big successes?  No, you were downtrodden, over-cautious and looking for the first opportunity to leave the company.  And I guarantee the company suffered for it, because they didn’t get your best work.

I’m not saying that someone who is wrong every time they make a statement should continue to get the benefit of the doubt.  But allow people to be wrong, let’s say, up to 33% of the time without assuming they’re incompetent.  No one has a hundred percent success rate at anything – even Bobby Fischer lost games sometimes.  If someone is wrong so often that you find yourself having a hard time believing in them at all, then maybe they haven’t got the tools they need to succeed. Ask them.  If they’re wrong less than a third of the time, they have a good track record and you should give them the benefit of the doubt.

2 – Determine causality, not blame

When something breaks, it’s important to know who broke it. That way, they can feel good about themselves by fixing it. Also, you can identify issues with process or opportunities to improve skillsets. However, it’s not important to assign fault, shame the person who made the mistake, or levy consequences.  Again, if every time a person touches your code it crashes the website, maybe you want to see if they have all the tools and knowledge they need to do their job.  But if a person writes code for you for a year and then one day breaks the build then you should figure out why and help them, not ridicule them.

3 – Take blame

The best way to create an environment where it’s safe to mess up occasionally is to show that you aren’t perfect. When you make a mistake, own up to it in front of the team. Take responsibility, and be an exemplar. Don’t lose confidence in yourself, either. It takes a strong person to admit they’ve messed up, and a stronger person to follow through on the fix.  Your team will admire your courage and honesty and they’ll know that they are safe to do the same.

4 – Laugh it off

I’m not saying that you should create a “Most failed experiments” trophy or anything. But the best way to create a close, trusting environment is to bring a little humor in.  It’s ok to laugh when something flops. It’s ok to gently tease each other, to have friendly competitions and chuckle while you’re cleaning up the mess.  Laughter is, after all, the best medicine.

5 – Budget some wiggle room

When you’re planning, plan a fudge factor in. I tell my team to use the Scotty Principle – multiply the time you think it’ll take by 3 and that’s the estimate you give. In every sprint, add some points for fudging.  Have multiple people check your work.  Have a backup plan.  A/B test.  If you assume that some experiments will fail, then you’ll be ready with alternatives. Be like the Buddha, and accept failure before it even happens.  Heck, count on it and figure out what you’ll do WHEN it happens.

If you apply these principles to your product organization, and maybe even to your life, you’ll find that it’s less scary to take risks.  After all, as long as the risk is a calculated one, and you have a disaster mitigation plan, there’s a ton of upside and the downside is manageable. Life is really just a series of iterations, day after day. Some of the iterations are improvements, and some aren’t.  But the universe didn’t give up on you when you didn’t get the relationship with your high school sweetheart just right.  It gave you endless second chances, and you’re clearly still getting second chances since dead people don’t read my blog.  (Or maybe they do.  If you’re dead and you’re reading this right now totally give me a call so I can write a book about you!) Create an environment full of second chances, and your product and your users will ultimately thank you for it.

Today’s Interesting Link:

Random User – Such Tool! Much Helpful! Many Fun! And other Dogespeak! This is an elegant little API that generates random user info for use in your designs.  The applications are only limited by your imagination.

 Today’s Usability Quote:

 This is an age of experiments. – Benjamin Franklin

Today’s Music To Design To:

Another oldie but goodie is Deep Forest’s Boheme.  It makes me think of browns and oranges, and makes me want to use rich textures. It’s smooth but just energetic enough to make it hard not to sway around.  Apply at very high volume for best effect.

How to Win an Argument About Design

Posted on by krys

This is my new desk fish, Pixel.I get asked – a LOT – how to persuade people to accept a particular design.  It makes sense.  Design, especially visual design, is a very subjective… subject.

I don’t win them all.  There are designs out there, even at my current position, that I’m embarrassed about. In the end, you can’t win them all, because if you do, you’re a dictator and you’re not doing it right.

However, in most cases, the designer should win any argument or discussion about design.  Why?  Because this is their area of expertise, that they have trained in and are paid to provide.  I’ve said it before and I’ll say it again: If the designer is consistently being overruled, they are not the right designer for the company.  Or maybe the people having the design discussion just don’t know how to do it right.

There’s one way to always win a design argument:  The designer can say “I’m the designer and I say so.  The end.”  However, I wouldn’t want to work with that person, and I don’t think you would either.  Pedantic is not teamwork.  Nobody wins, not even the user, because the designer might be missing out on better ideas than they could have come up with.

So here’s how to win an argument about design, in six not-easy steps:

  1. Genuinely listen to the other perspective.
    Maybe this isn’t an argument you should win.  Maybe the other side has merit you haven’t considered.  Maybe the other solution is equally beneficial to the user experience and the business case and when you examine it, maybe you win because you are won over.  There’s no shame in that, really.
     
  2. Apply statistics and standards to the other perspective.
    Really look at it analytically.  What do other sites do?  What’s the accepted standard?  What do studies say?  If statistics or known user behavior don’t support the other method, but do support your point of view, present them.  Depending on your company and team and how much they trust you, you might need to cite sources or show examples.  Be prepared to do this – don’t make stuff up.
     
  3. Apply your past experience to the other perspective.
    What have you done in the past?  Has their way failed or succeeded in the past and what factors were different?  Share this respectfully, and show examples.  Show numbers if you can.  Explain why you tried it and echo the person’s motivation so they know that you, too, thought that way.
     
  4. Explain your process in arriving to the conclusion that you arrived at.
    Often the other person is suggesting something because their process is different than yours, so they don’t know a piece of information you know.  If you can’t explain your process, then you probably shouldn’t be defending your position.  This leads to one of my key UX principals:

    If a position is hard to defend, you probably haven’t thought it through very well and it might not be the right position.  Stop and do your homework before you argue.

  5. Weigh the design position against the business needs.
    The number one source of design arguments is a conflict between business needs and friendly user experience.  Sometimes the business really needs to get something out of the user, or the business won’t be there to serve the user tomorrow.  Startups especially run into this conflict.  Weigh it carefully.  If the business needs are winning over good design principles more than 20% of the time, you’re making short-term decisions and will pay a long-term cost when it comes to keeping customers and word of mouth.  Maybe you’re looking for a quick exit, and that’s the right thing to do.  Or maybe you’re looking to build long-term relationships and parlay them into further business, so it’s not the right thing to do.  Your position will vary, but know what it is and act accordingly.
     
  6. If it’s just a matter of personal preference, be willing to admit it.
    There is NOTHING wrong with saying “I want it to be green because I like green.”  Nothing.  However, I’m going to say that it’s CRUCIAL for you to admit that it’s only preference, and if this is your only support for the position, you absolutely MUST realize it’s the weakest of all possible arguments.  Be willing to back off and swallow your preference for the greater good, if there’s even one data point against it.
     

There you have it.  That’s how I win the majority of my disagreements on design.

Of course there’s a few critical attitude components too.  You have to respect the other person’s opinion and thoughts and method.  You have to remain unemotional and cooperative.  You have to keep your mind open.  And in the case of an impasse – I sometimes run into these with people who outrank me organizationally – be willing to explore in tandem to find a third option.  After all, whenever it looks like there are only two options, it’s because you are being pedantic and closed minded.  There are always more than two solutions.

 

Today’s Interesting Link:

Practical Typography – I love type so much.  It’s pretty and it carries words to our eyes and through our eyes into our brains. Type is an art form.  This site is a great primer if you’re curious to learn about type, and it gives you just as much as you want to know.  That’s great UX.

 Today’s Usability Quote:

I am convinced the solution is always in the problem. You could do a design that you like, but it doesn’t solve the problem. Design must solve a problem.
– Massimo Vignelli

Today’s Music To Design To:

I can’t tell you how much I’m digging Blackmill.  It’s melodic dubstep – just what you need for crisp, outside-your-rut (come on, we all have them) designs and Gettin’ S— Done.  Check out Miracle, you can thank me later.

Book Review: Blink by Malcolm Gladwell

Posted on by krys

When I am teaching art to kids, they frequently ask me “Is this right?” or “Is it done?” or “How do I know if it’s good?”. My answer to them is always the same – you’re the artist, you tell me. Only the artist can know when art is done, and only the artist’s heart knows when it’s right. The kids usually react one of two ways – they’re either relieved to have complete freedom, or they’re horrified at the lack of judgement.  I can tell a lot about the kids and about their parents, by those reactions.

User experience isn’t quite the same. It isn’t art.  It’s right when it’s easy, it’s never done, and it’s good if the users are delighted at the end, and if the business wins too. I like to say that UX is 50% science and 50% art, but it’s probably more 75/25.  We user experience designers rarely experience artistic freedom because we are not serving ourselves.

At the same time, it is the UX person’s job to become as expert in the field as possible, so that they can make split-second decisions. Companies, especially those who haven’t had a UX person before, are very critical of a UX person who isn’t right with these split-second decisions.

This is where Malcom Gladwell’s Blink comes in.  Blink talks about the difference between conscious deliberation – the gathering of data, weighing and analyzing, and then choosing a course of action – and instinctive judgement.  Gladwell explains that instinctive judgement can be much, much more powerful in the right circumstances and coming from the right person.

As UX designers, when we’re called on to quickly decide whether a form field should be a dropdown or radio buttons (both valid choices for most circumstances) our subconscious processes a million pieces of experience stored in our supercomputer noggins, and spits out an answer.  Gladwell says this is a great use of instinct – it’s that primal reflex built into us since the dawn of time.  We look like we’re pulling it out of thin air, but in reality we have processed this and our split judgement has an answer at the ready.  This is “thinking without thinking” in Gladwell’s world.

However, the business world has taught us not to trust ourselves.  We second-guess, we think everything needs deep analysis, and we don’t know how to explain our instincts.  So we back up and question our experience, and this leads us to either 1) go with a HiPPO’s snap judgement, which they trust more than we trust ourselves or 2) wind up in analysis paralysis, working on a project for 3 months that should take 2 weeks.

I’ve been there. Gladwell describes a ton of other people who have been there too.  Careers are won or lost on the ability to trust snap judgements. Industries are built around the snap judgements of experts.

In Blink, we are shown through anecdotes and real-world examples just how amazing the instincts of experts can be. There’s a strong distinction there:  Gladwell is clear that you must be an expert in your field before your instincts are to be trusted. No one would ever ask me to make an intuitive diagnosis of a car problem, and I would never ask a sign language interpreter to choose the best interface for building engagement.

Gladwell also goes into the need for deeper analysis and examination of data.  He says that instinctive judgement should not be the only thing relied on.  It should be a data point. His contention is that, unlike what we have all been trained to believe, instinct is as strong a data point as data is.

I recommend this book for anyone who has ever questioned their instincts, and that’s all of us.  It’s good at reinforcing the lost confidence in our mind’s subconscious processing power.  And it will reinforce to you that it’s ok to put that problem down, walk away, and do something else while you let the wetware in your head work out the solution for you.

Blink was published in 2005 and is available on Amazon in just about every format.

Today’s Interesting Link:

CSS3 Animation Cheat Sheet – I love this, it’s so clear and beautiful and it’s fun at the same time.  It’s the perfect example of what a cheat sheet should be.  It shows you examples of all of the CSS3 animations and if you like it, you can just add their stylesheet to your work and boom! You can call them by name.  Saves time if you want it to, or gives you inspiration.  You choose.  😀

 Today’s Usability Quote:

The key to good decision making its not knowledge. It is understanding. We are swimming in the former. We are desperately lacking in the latter. – Malcolm Gladwell

Today’s Music To Design To:

Vicious Delicious by the Infected Mushrooms.  I’m pretty sure this is good for just about everything, because the Infected Mushrooms are energetic, electronic, melodic and evocative. it makes you want to dance, so don’t blame me if you find yourself swaying and bopping in your chair.

 

Don’t make your users repeat themselves

Posted on by krys

There are basic principles and pillars that make an app usable. The very most basic is “Follow standard practices whenever possible.” Directly following that, I think, is:

Don’t ever make your users enter the same piece of information twice.

Image from cheezburger.com

We live in the digital age of computers. One of the primary functions of computers is REMEMBERING things. If a user has ever entered something, you should remember it and carry it with them, across pages, across functions, even across applications if need be. If you want to be successful, you should be customer focused. If you are customer focused, the value proposition of saving information for a user and prepopulating forms or shortening workflows for them is fairly evident.

We have all had the experience of having to fill paper forms out in triplicate for government organizations. We’ve also had the experience from the meme above and been impatient.  Why would you put that on your users, when a few lines of code can avoid it?

I once worked for a fortune 500 company where 12 different applications (And a team of 5 people working in tandem) were required to order a single product. The tools were all built by different teams in the company, with different backends and different data output. They didn’t share data between themselves, so at each step, the user would be required to export data and then (in the best case) import it to the next tool.  Sometimes the user had to enter the data manually, and they would literally print it out and set it next to their monitor so they could type it in exactly the same.  I am not kidding you.

Probably, you’re not doing anything quite that bad.  If you are, hang your head in shame, and then fix it.

But you might be asking them for their name in one place, and then for first name and last name somewhere else.  Parse that bad boy out.  Maybe your phone system uses the phone number to look up the customer to see what tier of support they qualify for.  Then make sure your CRM is tied into the phone system so that when the customer is routed to the appropriate representative, that rep has the customer’s info and doesn’t have to ask for it again.

Google’s autocomplete is a prime example of this principle in action.  When you’re typing a search into the form, Google will autocomplete first with things you’ve searched for before, then with the most likely guess.  This is also one reason that Facebook sign ins are so popular – you use Facebook to sign up for a site and your info is there without you having to enter it in the new site. It’s like magic!

In the end, remembering things is probably one of the easiest tasks you can ask your software to do.  As users become more comfortable with computer interfaces, they will begin to expect this basic courtesy, as surely as we expect someone to respond “hello” when we greet them.

Today’s Interesting Link:

SVGeneration – This site is so much fun your head might explode. It’s got a ton of wonderful, tiled backgrounds that you can customize and then generate as SVG files. Go ahead, try not to get addicted. You’re welcome.

 Today’s Usability Quote:

It takes considerable knowledge just to realize the extent of your own ignorance.  – Thomas Sowell

Today’s Music To Design To:

Silent Shout, by the Knife. With a mysterious, slightly dark groove, this is synthesizer-based music that manages to be futuristic and uplifting and tickles your creative bones in all the right places.  The vocals even have that sort of airy but ominous feeling that lives somewhere between german synth pop and Lords of Acid.  Seriously, it’s worth a listen.

Design your back door

Posted on by krys

I keep company with architects and the children of architects, and I love buildings. I often think of my UI design process much the way architects think of the building design process.  You design your pages around the content.  You design a building around the primary space.  You ensure there are enough bathrooms for the number of people likely to be there at any given time.  You build in the features your users are likely to want just before, and just after your golden path task.  You make it accessible to anyone, regardless of physical ability type.

And I notice, that in much architecture, just as in much design, the back door becomes an afterthought.

Have you ever been amazed at how beautiful a building is, and wandered around it in awe, only to find yourself in a plain white hallway that leads to a mass-produced back door with chips in its paint and dirt pushed up against the doorjam?  Did you question it, and did it make you sad, or did you just accept it because it’s not the face of the building?

I got to tour the Pixar campus a while back.  It’s gorgeous.  And you know what?  Their architect even thought about their back doors.  Sure, they’re functional and not as beautiful as the rest of the building.  But the one I passed out through was Pixar-crisp.  A detail that the designers of the interior spaces looked at, thought about, and assigned.  It fit.

Why am I going on about architecture?  Because I want you to think about your back doors.  I want you to think about the alt tags and titles on your images and links.  I want you to think through the way your emails look with images off.  I want you to think about how your website looks with ads turned off (OKCupid.com does the neatest thing – they have a placeholder behind their ads that suggests you donate to have an ad-free experience).  I want you to DESIGN the voice browser experience.  I want you to think through your error pages and 404s and make them build your brand and help your customers in some meaningful way.  And I especially want you to think about your unsubscribe process.

I have a checklist for QAing and specing and even designing.  When I think I’m done, I go down the list and there’s always one thing I missed.  It includes things like

  • What does it look like in mobile?
  • How does it interact for touch?
  • What’s the SEO impact?
  • Does this affect other areas of the site/app?  Should it?
  • Are there emails associated and what do they look like?
  • What needs to be tracked?
  • What are the alt tags?
  • How does it share socially?
  • What’s it like to print it?
  • What does it look like when logged in? Out?
  • How do they get help?
  • What’s the back-out plan for the user if they’re not happy?

There should be no aspect of your app that’s accidental, or arbitrary, or forgotten.  Sure, you can have a perfectly successful website  without thinking about these things.  I’d say 90% of the successful websites out there do.  I once worked at a company that had a net promoter score of 93 (that’s astronomical, in case you don’t know) and they sucked at so many of these things – but the users were perfectly happy.

However, there is no downside to thinking about these things.  No one ever said “I liked that building until I saw that it had a beautiful back door and now I hate it.”  But maybe, just maybe – one person was on the fence about the building until seeing that beautiful back door gave them just the perfect subconscious feeling of elegance, refinement and conscious design.

Remembering your alt tags is a small investment for gaining one more delighted customer.

Today’s Interesting Link:

Trask Industries – This is the best movie promotional site I’ve ever seen. Even leaving aside my bias to immersive multi-channel entertainment experiences, and just pretending this is only some company’s brochureware site, it’s freakin’ awesome.  CSS animations build as you scroll, the page reacts and feels alive.  This is good design.  And it has Peter Dinklage.  You can’t get much more win than that.

 Today’s Usability Quote:

“Not having confidence will lead to bad decisions”  – Dave Mott

Today’s Music To Design To:

Coco Part 2 by Parov Stelar is, like much of what I recommend, at once exotic, energetic, and ambient enough to not distract you.  I love how it makes me sway while I work, and I think you will too.

Clear ownership makes for a happy team

Posted on by krys

Hybiscus flowerIn a lot of my posts, I talk about deputizing everyone to give input to the user experience, product and design process.  However, it’s important not to lose sight of clearly defined roles and ownership, or you’ll end up with a very mediocre product.

“Websites designed by committee end up beige and tweed” – A COO I used to work with

On a product team, you usually have executives, product managers, maybe project managers, content producers, designers and engineers.  Note that these people might be on different teams organizationally, but they need to understand that they are on the same team pragmatically.

Each and every person should be able to give input to every single aspect, from strategy, to tactics, to the pixels on the page and which screens show.  However, just because everyone’s voice should be heard, doesn’t mean that the project manager should dictate what color a button should be, or an engineer should be the final decision maker in the pivot of a company’s strategic direction.

That said, this blog is about design, and how to be a good designer even when you’re not a designer.  Here is the most important thing I will ever tell you about doing design:

Give your designers problems to solve, and don’t tell them what interface they have to use to solve the problem.

First of all, if you are not the designer, you are not the expert in design and interaction.  You might have knowledge, you might even be really good.  But the designer is the person paid, probably very large amounts, by your company to do that job and to think through all the options.  You should let them do their job.  If you don’t feel like they are good at design, you should talk to your supervisor or theirs about replacing them.  Don’t undermine them or overrule them.

Second, you are all on the same team, working for the same goal.  If you and the designer have a difference in opinions about what specific interface or interaction will meet that goal, the designer should win by default.  They are the one who will be held responsible for the interface they’re designing.  They need to be the tie breaker, even when the designer is part of the tie.  Would you want to be held responsible for decisions someone else makes against your will?

Third, designers are highly in demand right now.  Every designer I know hears from at LEAST one new recruiter a week.  If you’re constantly overruling your designers, they’re going to wonder what you need them for, and they’re going to go join a company where they get to actually do their job.  Maybe this is a good thing – maybe they aren’t the right designer for your company.  But ask yourself: if you hire a different designer, are you still going to overrule them when they disagree with you?  If so, the problem isn’t the designer.

Designers have a role in this too.

Execs’ job is to steer the company in the right strategic direction.  They get the big bucks, and have the big risks, to make it worth the sweat and tears they put into this.  Designers should bea  voice at the table, when strategies are being discussed, but once a strategy has been chosen – by the exec, not by the designer – it’s the designer’s job to jump into it with both feet and tow the company as hard as they can toward those goals.

Product managers’ job is to decide the tactics that get you to the big picture the execs have drawn.  They also need to determine the requirements for those tactics, and make sure the whole team is clear on what needs to be done.  Designers should give input, suggest features, and argue against the ones that are just cognitive clutter – but in the end the designer needs to trust the product manager to do the right thing for the company, and make the best design to fit the features specified.

Project managers’ job is to keep things moving on a timetable.  Designers have a responsibility to communicate how long things are going to take them, taking into account possible delays, iterations, and things that’ll go wrong.  And then, when the project manager sets a timetable and commits the company to it, it’s the designer’s job to pull as many all-nighters as are necessary to get things done by their due dates.

Content producers deliver the content the designer relies on to design their screens.  The designer can give direction as to length and sometimes structure, but in the end they need to trust the content strategy and adjust their designs to fit the content, or make the designs AROUND the content provided.

Engineers make the world happen.  They need to be involved in the design process, and designers need to trust that the engineer will build what they’ve designed. When the engineer says something can’t be done, the designer must listen to the alternatives, and be flexible enough to change their design to fit reality.

The bottom line

  1. Trust your designers to know what they’re doing.
  2. If you can see it or click on it, the designer has the final word, not you.
  3. Designers: open your ears and listen, and trust others to do their jobs if you want them to trust you.

Today’s Interesting Link:

From Up North – If you’re like me, inspiration comes from everywhere.  From Up North is a fantastic blog that gathers up inspiration from all over the art world – fine art, illustration, design, word art, tattos – you name it!  It’s daily and easily consumed and I love it.

 Today’s Usability Quote:

 “[Having too many choices] takes [customers] out of the purchasing process and puts them into a decision-making process.”  – Stew Leonard Jr.

Today’s Music To Design To:

Arash’s self-titled album is Iranian pop, so I don’t understand the words.  This makes it great for design work!  It’s energetic, exotic, uplifting and a little bit sexy.  I REALLY hope the lyrics don’t talk about drowning kittens and stealing candy from babies, because I like it so much.

Don’t be the weak link

Posted on by krys

A while back I wrote about Death By A Thousand Bugs, the slow degradation of user experience that comes from keeping all those little bugs around that are just too small to feel like they’re worth fixing.  There’s another kind of death, death by mediocrity, that I want to save you from today.

Have you ever stopped to think about the difference between a really great product that you love, and its competitors that you don’t love as much?  Odds are, it’s the small details. When a product team has taken the time to think about all the little things, not only does the product feel more polished, it’s easier to use, and it’s a more comfortable environment.  It’s like a house, where your hosts have thought to clean the grime out of the corners in the bathroom.  It’s just NICE.  The details matter.

What are details?  

Everything.

From the corner radius on your rounded boxes, to the color of your dropshadows, to the way things respond when you click them, to the thoughtful predictions of user intent, there is no end to detail. I can’t list every detail of an application because they are truly, infinite.  Apple is a master of the details, though even they don’t think of every single one. Google, I’m sorry to say (as a very loyal user of their products) is not good at details in its UI.

Learn how to break things down.  There’s the normal view:  “Oh, it’s a page with a body, an aside, some ads and a call to action button”.  Then there’s the next level of attention:  “The body is 2/3 of the page and the aside is 1/3 on the left.  They are separated from each other by a colored border.  The ads all have borders and a label.”  Then there’s the next level: “Everything but the content responds when I mouse over it.  As I scroll new things appear.  All the borders are 1px.  Everything actionable has a drop shadow.”  And then you get really into the nitty gritty “The shadows are dark green instead of black.  There is a darker shadow on the most important thing.  Things that are meant to guide my attention are tilted at a 15 degree angle” etc.

This is, of course, a vastly simplified example.  But it’s important to see the progression – it’s like zooming in with a microscope on every single little element of every screen.  I like to start at the top and work left to right, top to bottom, but you can find your own method.  Think about the very atoms of what you’re looking at – and while you’re at it do your users a favor and ask if it really needs to be there.

Whose job is it to keep track of all the little details?

I can’t think a single person in a product team who shouldn’t be thinking of details.  There’s probably a funnel, with the product manager and designers thinking of the most details, but every person, from project manager to developer to QA engineer should be paying attention to these things and talking about them with the rest of the team.  If  designer misses the idea of putting helpful mouseover text on the icons, the janitor should be able to point it out and suggest it.  If the engineer notices that it would be neat if the eyes on the icon critter closed when the product wasn’t in use, they should be able to suggest it or even just build it.  How much you empower the people outside the “planning and design”  functionalities of the project is up to you.

I’d like to say that the product manager and designer should think of every detail, because detail is their job.  However, no one, two or ten human beings can think of an infinite number of things and I’ve already pointed out that details are infinite.  Even Apple misses things.  So the product manager should do their best and they should deputize every other member of the company to do the same.

You’ll find that certain people are really good at finding certain kinds of detail.  I’m really great at noticing visual design and interaction details, but I’m not always awesome at data details or QA details.  Because I like to set up tight all-way communications in my teams, I usually get the feedback that I missed a certain browser or resolution when I was QAing, and I actually keep a checklist.  Know where you’re strong, and offer that up to the team.  Know where you’re weak and find a workaround, whether that means trusting someone else to be strong there or making checklists or creating mnemonics or whatever works for you.

The user experience of your product is only as good as the least detail-oriented person working on it. Don’t be that person.

How can I train myself to think of details when I’m busy crafting the big picture?

That’s the easiest part.  There are some great blogs out there – one of my favorites is Little Big Details – and you can subscribe to them.  They only take a second to read each day, but they’ll change how you view the world.  While that’s happening, you can start asking yourself why all the time.  Why am I doing it this way?  Why do I like that?  Why did they do that?  Why should we do this?  You’ll start finding that the critical thinking will really improve your appreciation of everything you do, but it’ll also improve your understanding.  As a side effect, it’ll also increase your frustration with the world “Why did Safeway require me to choose payment method on the self-checkout screen and then again on the card reader screen?”.

Every time you see something you like, think about whether there’s an equivalent for your product.  Maybe the texture on the dashboard of my Prius (one of the many details that makes me love the car) inspires me to use a texture in the background screens of my app, just to make it feel more tangible or evoke a subconscious association.  Nothing in the world should NOT inspire you.

This doesn’t mean you have to stop thinking of things holistically.  It just means you need to become a more flexible human being.

When should we start fine-tuning details?

This is a prickly question, because details can mean scope bloat and creep if you’re not careful. It can lead to analysis paralysis if you don’t practice pragmatism and prioritize well.

Start thinking about your details from the very first moment you conceive of a project.  Carry over details from previous projects that you’ve already thought of and implemented. Bring in the dreams of idealism.  Polish starts from the very first second, as you build a smooth surface to buff later.

As you move through the production process, details get more and more expensive to design and implement.  Too much, too late, and you have experience rot before the product even goes live.  So try to make fine-tuning a part of your DNA.

If you’re willing, empower your developers to just Make It.  I’ve worked with some great developers who knew that thing could pulse when you mouse over it, and I happened not to think of it.  They just did it, and showed me, and I jumped up and down with delight.  Just remember to encourage communication loops; surprises are a bad thing.

If you have a deadline, or if you are on an agile schedule, treat the details like a constant improvement.  Do as many as you can before you push, and then queue up a list of new things.  Always be adding to the list, always be improving.  I’m an Agile fan, so this comes easy to us.  Waterfall shops will have a little more trouble with that, since it’s often “get it perfect before you hand it off and then don’t even think of changing it”.  However, even in a waterfall world, you can build relationships with the people downstream and upstream, and make judgement calls.  What doesn’t increase scope too much goes in, what does goes on a list for the next rev.

Get started today

Go.  Go now, my child!  Look at your website, your app, your product. Break it down to every atom of form and function. Find a friend who’s anal-retentive and ask them to do the same thing. Find someone who’s good at describing things and ask them to describe to you how it looks, how it feels, how it behaves. And then make EVERYTHING better.

You can do it, I believe in you.

Today’s Interesting Link:

random.org – Random is hard.  Like really, mathematically hard.  Let these guys do it for you.  They have so many fun toys, that you’ll find excuses for being random all the time. And that can’t be a bad thing.

 Today’s Usability Quote:

 “If it is something important, get a colleague to improve it.” – David Ogilvy on writing, but fits design

Today’s Music To Design To:

Cirque Du Soleil has so many good options.  However, Dralion has everything I love – haunting vocals, varied tempos, and a wonderful mixture of exotic and familiar.  You can’t go wrong with Cirque, and maybe it’ll even inspire you to get out of the office and go see them.  :)