Tonight at midnight ends Optimal Workshop’s Designer’s Toolkit sale. We’ve used a number of these tools, and gotten good value out of them. For $1990, here’s what you get in the toolkit:
OptimalSort for card sorting – 12 month subscription
Treejack for tree testing – 12 month subscription
Chalkmark for first click testing – 12 month subscription
I enjoyed reading A Loose Heuristic for Mobile Design on UXBooth. The full article is worth the 5 minutes it will take to read, but here’s most of the heuristics in bullet form [with a few comments by me in brackets]:
Simplicity is a requirement [not just a “good idea”]
Balance brevity and comprehension [don’t throw the baby out with the bath water by stripping out necessary context]
Understand, then optimize, your core value proposition [don’t try to do everything your desktop version does]
“Where” is more important than “who” [understand physical context]
Assume terrible dexterity [favorite quote: “give it to a young/drunk/old person and see how they do.”]
The footer is a dead zone [don’t waste time on it!]
Assume distracted, disrupted, and intermittent use
Good experience is a subset of performance [it’s gotta be snappy]
Provide access to the “desktop” version [like it or not, the “non-optimized” version will still work better for some people, depending on familiarity, performance, device, etc.]
Great poster on why you fix bugs as soon as you find them. Many of the same cases could be made for usability issues (at least the medium to large sized ones). Here’s the short list (via uTest):
Unfixed bugs camouflage other bugs. (So true for usability issues! This is why I love RITE testing and similar methods; you get those Big Rocks out of the way so you can discover others.)
Unfixed bugs suggest quality isn’t important. (Amen, especially with regards to usability issues.)
Discussing unfixed bugs is a waste of time.
Unfixed bugs lead to duplicate effort.
Unfixed bugs lead to unreliable metrics.
Unfixed bugs distract the entire team.
Unfixed bugs hinder short-notice releases.
Unfixed bugs lead to inaccurate estimates.
Fixing familiar code is easier than unfamiliar code.
Fixing a bug today costs less than tomorrow. (Very true.)
You’ve been there. You’ve felt the knot in your stomach. You’ve tightened your grip on your iPad ever so slightly after hearing your client say “You know, on that header? I want our logo to be bigger. Way bigger.” And you think to yourself Great. I just found me another do-it-yourselfer. He designed a newsletter for his student club twenty-seven years ago and now he’s ready to tackle his corporate website. He just needs me to run Photoshop for him.
The world slows down for just a moment. You stare down at your notes, half pretending you didn’t hear and half expecting your iPad to feed you your line or something. But nothing comes. Time picks up its lumbering pace again. The street noise outside your client’s office window wakes you up and you realize now you have to say something; something that acknowledges your client’s statement. Something that isn’t “You wanna do this thing yourself?”
But, what?
Newton, Sumo Wrestling, and Design Iterations
Newton’s third law of motion states that “for every action, there is an equal and opposite reaction.” Of course the guy was talking about the physical world. You know, like the pull of gravity working against your overwhelming desire to dunk it, or the tension of your belt working against the fierce push of your expanding gut. But, of course, we can always twist his words to apply them to design. And it’s fun.
In the “very complicated act of faith” that is design, there are two main forces at work: the problem and the solution. Their relationship is a lot like the one between your beer belly and your belt: they mirror each other. One is the question, the other the answer. They’re twin sumo wrestlers in different-colored diapers, pushing at each other with tremendous force. They’re the yin and the yang: identical, but opposite.
This is a fact that designers the world over use to their advantage. Want to come up with a great solution? Understand the problem. Want to understand the problem? Come up with a solution. If you figure one out, you immediately understand the other.
The design iteration, then, becomes a nice, sweaty wrestle between problem and solution. A designer will do a bit of research on the problem, and then propose a solution. That proposal invites feedback (aka more information about the problem), which the designer then takes into account for the next solution proposal. Rinse and repeat. Slowly, the designer’s understanding of the problem and the solution grow together, until finally, voila! We’ve got ourselves a finished product.
Clients Have Brains Too
As designers, we’re comfortable with this relationship between problem and solution. In fact, we use it to make a living. We’ve come to accept the iterative synthesis of solutions as the best way to come to understand problems. And we love it.
Well, it turns out our clients are often doing just that when they blurt out an unsolicited design suggestion. They may see a problem with our design, but instead of describing the problem by saying something like “You know, the home page just doesn’t feel ours enough. It still feels a little generic to me. I don’t think it reflects the personality of our company quite yet” they propose a solution and say “I think the logo should be bigger. Way bigger.”
This is because clients have brains too, and they understand that problems and solutions are like bellies and belts, like crooked teeth and braces, like moobs and manziers. So, perhaps involuntarily, they blurted out a proposed solution instead of a description of the problem.
So why are the solutions they propose rarely great? Because they’re not trained designers. But that doesn’t mean they’re bad clients. They may be diagnosing a legitimate problem, but because they did so by prescribing a lousy solution, you think they’re dumb.
Take a step back. Breathe.
Find the Twin Sumo
Now it’s back to you in your client’s office, iPad clenched in agony. You need to say something. What to say, what to say, what to say?
Well, if you understand that your client’s lousy design suggestion is really the mirror image of a problem he’s trying to diagnose, all you have to do is find the twin sumo. Take the proposed solution and turn it into the problem you think it was designed to solve. Then shoot it back at your client. Hmmmm…bigger logo…what could he be talking about?
“So, what you’re saying is that you think the current design doesn’t really feel like it belongs to your company, like it’s really you?”
Whew! You made it. Now, relax. Wipe your brow and get rid of the poker face. The conversation is ready to go somewhere.
Did you nail the problem on the head? Maybe so, or maybe not. But when you translated your client’s proposed solution into a diagnosed problem, you did something priceless. You let your client know that his input does matter, but you did it without compromising the integrity of your work, or your role as the design expert in the room.
Now you can work to refine your understanding of the problem the client is trying to diagnose. And your client? Not an idiot. Not a deadbeat. Just a guy with a brain trying to tell you something’s wrong. So listen up. You just might learn something.
Ifttt.com is an app to manage and automate all my social profiles. I love it for three reasons. First, it’s based on the dead simple concept that if I do something then it will do something else for me. So if I post on flickr, it will send that image to facebook. If a stock hits a certain price, I’ll get an email. If I publish a blog post, it will tweet about it. Each “task” is completely customizable, so I can set it up exactly the way I want. Second reason I love it, is the UI. It makes a 7-step process feel completely effortless. I wanted to take a video of it, but then I got tired and gave up. Last of all I love the sheer number of apps & services that it works with. Below is a screen shot of just the popular applications.
The app is in private beta, so you have to sign up. Additionally I have 5 invites, so if you want one and are quick feel free to reach out.
Great question. Here is a quote from stackexchange on the topic that is pitch perfect:
“So suppose you can save $2000 every three years by buying cheaper computers, and your average developer(or designer) is making $60k. If those cheaper computers only cost you 10 minutes of productivity a day, not at all a stretch, I’m sure that my machine costs me more than that, then over 3 years the 125 lost hours would add up to a loss of $7500. A loss of 1 minute a day ($750) would give a net gain of $1250, which would hardly offset the cost of poor morale”
Would a contractor ask his carpenter to cut with a dull saw? Full thread here.
First off thanks to all those who particpated in our survey. The data points included some surprises that I hadn’t expected. I’ll let the results speak for themselves. As for the schwag, we’ll announce that soon too!
Annually alistapart has a web design survey which is jam-packed of interested data points about our industry. Their survey is built around the people, how they work, and how they learn. I enjoy reading it each year, but I’ve always wanted to know a little more about the technology behind it all. To that end, here is our first annual web developer survey. Each year we’ll solicit feedback from folks in and out of the NorthTemple community, then pool together the results and post them here.
As a thank you participating, we’ll randomlly send a few lucky readers some NorthTemple/FamilySearch swag.
Last week at FamilySearch, Eishay Smith came to talk to our org about Continuous Delivery. His company wealthfront.com, which manages a quarter of a billion dollars in an SEC regulated environment, pushes code from commit to production in less than 10 minutes, about 50 times a day. Full talk here. Imagine how this would impact your work, if you could test features against a subset of real users at this pace.
If that sounds good, we’re working on it. Come help us.
Former colleague August de los Reyes pointed me to a 1932 typography article by Beatrice Warde posted on Design History:
Imagine that you have before you a flagon of wine. You may choose your own favorite vintage for this imaginary demonstration, so that it be a deep shimmering crimson in color. You have two goblets before you. One is of solid gold, wrought in the most exquisite patterns. The other is of crystal-clear glass, thin as a bubble, and as transparent. Pour and drink; and according to your choice of goblet, I shall know whether or not you are a connoisseur of wine. For if you have no feelings about wine one way or the other, you will want the sensation of drinking the stuff out of a vessel that may have cost thousands of pounds; but if you are a member of that vanishing tribe, the amateurs of fine vintages, you will choose the crystal, because everything about it is calculated to reveal rather than to hide the beautiful thing which it was meant to contain.
Even a tee-totaling Mormon like myself can appreciate the point: the best design is invisible. Warde applied it to typography specifically, but the same applies to design in general. Often, our goal in design should be to get out of the way, so that people can consume the content or perform the task that they came for. I think too often we get caught up up in the decoration and adornment of our own particular golden goblets, and don’t pay enough attention to the content and tasks that are so central to the experience.
I was checking out a site referred to me by a friend at work: Safe Mothers, Safe Babies (SAFE). She said they needed some design help, so I thought I’d take a look. (You can contact them if you’re interested in helping out—looks like a great cause, helping mothers and babies in Uganda.)
As I browsed the site, there were clearly a lot of opportunities to spiff things up, but not that many that truly hindered understanding or use of the site. At least until I came to their multimedia gallery:
Interesting photos, but I am not sure what they are about. There are no labels on each photo to help me out, so I start looking for clues. At that point a new problem emerges. See it?
Seven nav links aligned pretty closely with seven columns of images. Without a closer examination, some folks might think that the nav links are related somehow to the content aligned beneath them—that they are column headings. Human beings are are meaning-makers, so we stretch and strain to figure out the relationship, to define a connection that isn’t really there. Confusion or at least a loss of time is the likely result. In worse cases, it might actually lead you to assume something that isn’t so—that the last column shows actual photos of the group’s headquarters or something, for example.
It struck me that this is a type of visual “tombstoning”—an unintentional (and often humorous) alignment of headings in newspaper or magazine layouts. Here’s an example from an About.com article on tombstoning:
Really? Dead Bugs Drink Wine? Were they dead before or after they drank it? Either way, that’s pretty interesting… but not what the authors or editors intended!
There’s obviously a lot more to say about The Principle of Proximity, but it’s good to keep in mind that:
It is not enough to group things that should be grouped.
You must also avoid grouping things that should not be grouped.
And if you’re interested in helping SAFE dig up and replace those visual tombstones, drop them a line—I’m sure they’d appreciate it!
I just did a nice MySQL dump of about 10,000 spam comments, just from the last week here. Hundreds of them are getting through Akismet, and they’re dang smart, too.
So, we’ve axed ‘em. Went in and disabled all comments on all posts. I might have to build in a human check. Or we might leave comments off. We’ve loved interacting with all you people, but comments are a funny thing. I’m not sure any of us will miss them.
In helping a colleague prepare for a usability test, I found Jared Spool’s latest UIE Tips article timely and totally in synch with my own experience. Three questions NOT to ask during user research (paraphrased and embellished):
Don’t ask about the future. People don’t know what they would really do in hypothetical scenarios—even highly realistic ones.
Don’t ask how they’d design a feature. They either won’t know or won’t have good rationale. They know their process and to a degree they know their problems—focus on that, not their proposed solutions.
Don’t provide a (supposed) answer to your own question (“Did you do X because Y?”). Leading questions may be a staple of political pollsters, but they yield biased results. Don’t feed them reasons out of your own experience or assumptions—let them provide their own.
Hoping to write much more about the thousands of decisions that went into this, but for now come see our latest work on beta.lds.org. We’ll be adding features and new pages in big monthly bursts, with a funeral for the current site planned for October(ish)..
So here’s the results of that password changing survey. Let me preface this by saying that this survey was done purely to satisfy our curiosity. We are NOT looking to this survey to help make any decisions here at the Church. We acknowledge that this survey was not scientific and thus the results need to be taken with a grain of salt. That said, I still think that we learned some interesting things. Just don’t go around quoting statistics from this survey and expect them to stand up to scrutiny.
Another point that I want to make clear is that this survey doesn’t really address how secure our passwords are. We know that the best passwords are truly random characters and numbers without any logical order and the longer the better. Our survey doesn’t specifically figure out if you’re using a “secure password.” We only tired to figure out what happens when it comes time to change that password.
Question #1: When forced to change a password I… 42.98% – Just increment a number. Password1, Password2, Password3, etc 8.77% – Change a topic. Ford1, Chevy1, BMW1, etc 23.68% – Some other pattern (explain in comments below) 21.05% – Come up with a completely unique password 3.51% – Other
There really weren’t that many surprises in this question. I had anticipated that an overwhelming majority of people would use some sort of pattern. Only 21% of us come up with a unique password every time we change our password. That means that 75% of us are using some form of an “easy to remember” password.
Again, please don’t use this to infer a sense of the of general security of a system. “Easy to remember” ≠ “easy to guess.” An incremented password of th55myp55wrd3 is more secure than the unique password of stapler. That said if someone figures out the root portion of the incremented password that gives them a much smaller number of possibilities to try.
Question #2: How do you remember the new password? 69.30% – I use a pattern so it’s fairly easy to remember 10.53% – I have to write it down for a while, but eventually toss the paper 6.14% – I have to write it down and keep it until the next change 14.04% – Other
Based on the answers to the first question, it wasn’t surprising to see that most of us don’t need to write our passwords down. We know that writing passwords down is one of the least secure ways of remembering it. I think that is why we develop these patterns. We know that writing it down is bad, but remembering a bunch of random characters is hard, so we adapt.
From the comments it appears that many of us are using password management software like 1Password, LastPass, etc. Personally, I’ve been looking into these programs and they seem like a good solution. The theory is that they allow you to set a truly random password for each site. So no two sites use the same password. Sounds great, as long as every system (computer, mobile, etc.) you use has that software installed. The other downside is that if your laptop/mobile phone is stolen they only need to crack your master password to get access to everything. But I suppose that it’s easier to remember one complex password than hundreds of them.
Question #3: If you didn’t have to change your password (or at least MUCH less frequently) you would… 35.09% – Still do whatever easy option I did above 35.96% – Make a semi-complex password that would be more secure 28.95% – Make a considerably more complex password that would be more secure
Here’s one question that surprised me a bit. I’ll admit that I assumed most people would continue to do whatever is easiest. We’re human, we’re lazy, we’re creatures of habit. Surprisingly, nearly 65% of you would use a more complex (read: more secure) password if we didn’t have to change it so frequently. That’s probably the biggest take away from this survey. Changing passwords is supposed to make a system more secure, but making those changes too frequently could have the opposite effect.
Question#4: How often are you forced to upgrade? 2.63% – Every few weeks 6.14% – Every month 8.77% – > 1 month ≤ 2 months 50.88% – > 2 months ≤ 3 months 31.58% – More then 3 months
Question #5: Personal desire for security 5.36% – I don’t think the stuff in my account is that sensitive so I don’t need a complex password 41.07% – I understand why I need security, but I can’t try to remember a new complex password every X months, so I make it easy for me. 50.00% – If I could have the same password for > 1 year I would make it complex and thus more secure. 3.57% – I’d keep my password easy no matter what. My ability to remember is more important then my account security.
So this was probably a question we should have worked through a bit more. Personally, I would have answered with both the 2nd and 3rd options if possible, but we just kind of threw this together. Still the take away from this question is that we understand why we need to be secure, but we need to access stuff, so we compromise. But, if we didn’t have to change so frequently we’d compromise less.
You know who you are. You’re probably geeking out in jQuery as you’re reading this. If you can slice up a PSD, write clean and accessible markup, and javascript my face off – We Need You Yesterday.
We’re looking for 2 front-end developers (expert in HTML/CSS/Javascript). The contract is for 3 months in the Salt Lake City area and starts immediately. If you’re good, we might just keep you.
Send me an email with your resume and some examples of your work. Now get to it!
For those of you in SLC and not heading to Austin this week, come join us this Thursday at the Stimulate SLC Hack Night. Bring your laptops and sketchbooks and collaborate with a few dozen creative hackers.
Huge disclaimer: Stimulate isn’t affiliated with NT or the LDS Church, but Chris and I organized it.
There’s limited space so get in here. All the info’s at Hulabalub.
