Archive for the ‘Design’ Category
One of the hardest things about designing web applications is presenting the multitude of types of information that is necessary at any one time. What do you display? What do you leave out? What information is more or less important than other information? If a piece of information is actionable, how do you visually inform the user of that?
Recently Twitter redesigned their interface using a new 2 panel layout where the sidebar dynamically changes, allowing for deeper inspection into the tweets that show up in your timeline. From a design standpoint there are a number of things that are great about this. The proportions (using the golden ratio) are excellent. The metaphor of a slide out panel is excellent. The exprience over “old Twitter” for reading conversation is vastly better.
However, there are 2 things that specifically bug me about the new design: what I’d call the over stylization of the content and an over abundance of information.
This is a conversation in the side panel between two people I know. The first problem is that I think this is too much information. Here is what I see here: close link with icon, 3 tweets in two distinct styles with avatars, usernames, real names, timestamps, API client names and conversation links that link to the same conversation I’m viewing. There is also a user profile, which is in the same style as a tweet except the user’s bio is in italics. There is also links to use the original tweet in all the functions Twitter provides and the panel even goes on to list out other tweets from @bleything, however I have chosen to crop those out. Keeping in mind that my original intention was to view a conversation, and I came upon that conversation by clicking on a link in a original tweet, my goals are fulfilled but I’m also bombarded with more extraneous information than the original conversation contained.
Second, although there are probably less than 1000 characters here, and less than 420 characters of the information I requested when I wanted to view the conversation, there are no less than 12 distinct combinations of font weight, color and size.
Lets compare this with a “conversation view” from the Echofon Mac desktop app.
I find Echofon’s conversation much easier to read, and if I want more information, such as the API Client used to post the tweet or the user’s bio, I don’t mind digging deeper through the pathways I already know exist in the app. If I like to do something with one of the tweets, hidden controls appear when I mouse over. And even though there are graphics, the UI here is cleaner and only contains 2 text styles. Literally every piece of information or action provided in the new Twitter conversation is accessible via either 1 mouse click or hover.
Designing applications is always about more than what the app look like. It’s how the app works, what information it presents, and making sure the user can easily and clearly achieve their goals.
According to wikipedia as much as 10% of males (~15 million people in the US) have red-green color blindness. Why is that important? Well, for me personally, it’s important because I’m in that 10%. For a designer, it’s important because that’s probably more than the number of people who use, say, Safari and Chrome to browser your site. Do you care if your site works in Safari and Chrome? Do you care if it’s useable to people with color blindness?
I was reminded of this when I checked out Google Wave recently. When I signed in, I had 1 contact: the person that invited me. Their presence was shown by either a red or a green dot. Not an icon, but a dot. Not a large dot, a small dot.
So here’s the problem: I have no clue, litterally none, whether that person is there or not, because I can’t tell if that’s red or if that’s green.
Now, I’ve had this conversation so many times I can tell you what you’re thinking. You want to ask me, “What color is it?”. I can’t tell you. They are either green or red, but I don’t know. In fact, I can’t even tell if they are the same or different colors. Both of the dots look green, unless I think they are red, then they look red. I know, it doesn’t make sense. I literally can’t tell what color they are. I’m actually red-green-brown color blind, so they could be brown and I’d have no idea. All I know is: Google, you’re doing it wrong.
Facebook on the other hand, did it mostly ok. The blue moon is great for away. A green dot for available? That’s just lazy (and 2 different metaphors).
Here’s an example of a red/green combo I can differentiate and one I can’t.
One of the core tenants of Agile/XP/TDD/Getting Real/Lean (etc) is doing the simplest thing that could possibly work. TDD says you should write a test and then only write enough code to make it pass. Lean says you should think about “minimal marketable features”. Paul Graham says you should launch just as soon as you have 1 feature that anyone would care about (here and here). Why is this so important? The fact of the matter is that 80% of your users use 20% of your app. That is to say, most people don’t care about most of what you have built. So why build it?
It turns out it’s really hard to know what people want before you make it. There are certainly ways to mitigate it, user observation testing, paper prototyping, but sometimes these things end up taking more time than just doing the simplest thing that could possibly work. In the end, you just need to build it, get it out there and see if anyone cares.
Well, the other side of this coin is that it’s also really hard to limit yourself to doing the simplest thing that could possibly work. You have to say “no” to many things and many people, including yourself, and people just aren’t good at that. No one wants to be the guy that always “puts down others ideas”.
I’m very happy to be seeing a new trend in web apps, minimalism. I can only hope, that it continues to pervade all corners of software, both web based and desktop based. The tip of the spear seems to be the “helvetification” of popular apps. Some examples:
So what is so interesting about some new skins for some web apps? Is it just that I really like Helvetica? Well, I do like Helvetica, but the really interesting thing about these skins is not that they change the fonts and colors, it’s that they actually hide or remove significant parts of the apps. I’ve been using Helvetireader for probably over a year now, and I can’t stand to use google reader without it. I *hate* what GReader has become. It’s got tons of stuff I could care less about (probably say, 80% of it’s functionality). Starred Items? I use delicious. Trends? Really? And my favorite “Browse for stuff”. Uh, what? Isn’t that what using the internet is? What if Google Reader was the simplest thing that could possibly work? I think it would look like Helvetireader.
But Wait, There’s more!
So how does a couple skins for a couple web apps me that this is a trend? Well my friends, I didn’t think it did until I saw this:
What is this? It looks like facebook, but they’ve gotten rid of all the crap I don’t care about. Lite.Facebook.com is supposed to be a version for “low bandwidth users”, but boy it sure does look like a minimal version of Facebook to me, and I like it. Compare it to say, myspace, and we’re talking Donald Judd levels of minimalism. And have you seen an Amazon Kindle? What about Readability from Arc90 (which happens to be really popular)? All of a sudden, we’re starting to get into trend categories, and I haven’t even mentioned how minimalism is the entire strategy of Apple, 37Signals, Twitter, and Tumblr.
But Features Are Good!
Well, features can be good, but they can also be terrible. Recently, an interesting sounding website called “Gist” launched. What does Gist do? “Gist is designed to help the professional email user who often opens up their inbox only to feel like it’s helplessly out of control” (via ReadWriteWeb). When I think of designing a site that is supposed to “take control” of something which is in chaos, I think of clean, minimal, organization. I would think that this tool would help me get to inbox zero, where there’s nothing in my email inbox but whitespace and the freedom to actually get my work done. So when I see screen shots like the one to the right, I can’t but help to think, “Is this really the simplest thing that could possibly work?” This is a site that’s coming out of beta today. Not something that has been around for a decade. How would anyone know where to look, or what any of those boxes do?
Minimalism != the simplest thing that could possibly work
I could give you a bunch of definitions from famous artists and architects about minimalism, but I’m going to just say that minimalism isn’t the simplest thing that could possibly work, it’s when you optimize tsttcpw. The important point here is that it’s important here is that if you do more than tsttcpw, then you’re much less likely to rip out the parts that no one cares about. And I hope it’s apparent that, people want you to remove this crap. They don’t want more features, they want better experiences. They want that 20% of your application to be 100% of your focus, and they want the 20% to get better, not slowly become 18%, then 12%, then 10% because you keep adding crap they don’t care about. Minimalism, whether it’s in design, or any thing else, is taking that 20% and making it 100%.
Over at HackerNews “prateekdayal” asks:
I run an online music community with decent traffic and usage. When we started out, I had no background in web (and usability) and have learnt a lot in the last two years. I can now tell whats lacking in the current design (aesthetics/usability/interaction wise) but still don’t know if I can design from scratch. I do have a designer (to help with graphics) but he is good only with skinning so I have to do the usability and interaction design work.
What is the best way out of this situation given that I can’t hire external help (for financial reasons of-course). I have been thinking of reading some good books on web design patterns and following standard practices. Does that work well?
The biggest thing to manage in a redesign is risk. Risk you alienate your user base or do something that negatively impacts revenue, or whatever you’re most afraid of.
The easiest way to manage it is to shorten your feedback cycle (not user feedback, any type of feedback) to the smallest possible interval. When talking about design, this means you need to spend the least amount of time on the design you can before you put it in front of someone that exemplifies your average user (persona).
This is usually done through some sort of lo-fi mock up or wireframe first. To do an effective job at that, you probably first want to evaluate your information architecture. However, this whole process shouldn’t take more than a day or two of work. That means you may only “waste” a day of work if your direction ends up not working out. You haven’t involved a designer, you haven’t pushed a single pixel, and you definitely haven’t written any code, but you’re already getting into a feedback loop.
To test a wireframe in front of a user, you want to do something called “wizard of oz” testing. This is a process where you take paper versions of your wireframes, and put them in front of a user. You can cut up hte prototypes to make the pieces easier to change out as you let the user “use” your wireframes. Don’t worry about how rough your wireframes are as you’ll find that people are pretty forgiving when involved in woz testing.
Another great thing about wireframes is that it’s extremely fast to iterate on a them. You can sometimes make small changes while you have the user right there doing the test. Larger changes will probably only take a few hours. Again, this is a feedback loop on changes of 10 minutes to 4 hours.
This whole process might take you 3 or 4 days of work, but the feedback loop it creates may save you 3-4 months of work down the road. It’s probably also going to save you money when it comes time to actually do a design (which you want to again test with the users) and implement your changes (which you can test through bucket testing).
Each time you can create a feedback loop throughout the process, you’re decreasing the risk of the redesign. It’s not dissimilar to writing unit tests to make technical refactorings more manageable. Unit tests are the ultimate in development feedback loops and decrease the risk that changes you make to your code base are going to break unexpected other parts of the code base. The same things can be said for user testing feedback loops for visual and UX designers.
I recently watched @garyvee’s keynote at Big Omaha. It’s great, and he makes a really great point in it that I’m going to pervert to the next level:
Social networking isn’t social networking, it’s business. The internet has won. TV is dead. Newspapers are really dead. And the best way to conduct business on the internet is through social networking. (paraphrasing)
You can see it here: http://www.vimeo.com/4671951 (8:30 in)
Now, he goes on to say it’s not actually Twitter or Facebook, but more that you need to start blogging. I totally don’t disagree, but I am going to argue that you can’t ignore Twitter or Facebook.
If you are a content producer, you can’t ignore Twitter or Facebook because they are, by far, the easiest way to get positive viral metrics going for your content. Each retweet, “like” and comment you get is going to spread your content wider and wider via methods as strong or stronger than traditional “word of mouth”. And, frankly, you aren’t handcuffed to google to come back and scrape your content for keywords.
But bigger, if you have any sort of user generated content, ignoring Facebook and Twitter is practically suicide. Both services now have login solutions, which then allow you to post the activity of your users back to the services. This is great for you, since it has the ability to spread your new UGC virally, but your users may also love it because they are probably looking for some sort of recognition of their contributions to your site. If someone “shares” something on your site, they probably want to “share” it somewhere else.
There are 3 keys to doing it “right”.
First, all of your user generated content MUST have a unique url. Without a unique url, you can’t effectively share these actions.
Second, you must ask for permission. If this isn’t obvious, you must have been in a cave when Beacon-gate went down.
Finally, you must provide both primary and secondary participation. So if someone uploads something your service, you must let them share that back to facebook or twitter, and you must give the people that come back to you through the share to contribute directly to what was shared. If they, for example, “upload a video” (primary participation) and you tweet for them about it, then you have to have some way to engage the people coming to see the video (secondary participation). Whether that’s comments, or “likes” or a star rating, you have to engage your new traffic, of they will just bounce. And two thumbs up if you give them a great path to explore your site from here.
Whether you are producing content or have a service where others produce content, you can’t ignore the social networks. But don’t think of them as competition, think of them as distribution channels for your actions or your users actions. And make sure you engage the interest you gain from them, or it will all go away.
Recently, a group of folks (including myself) from AboutUs.org attended a workshop called “Agile Product Design with Jeff Patton“. Jeff is a really smart guy who has been doing some great work to bring Agile software development techniques to the product design and user-centered design fields.
Let’s step back and look at how most software and websites are developed. Companies often start a new software development cycle by having their business people identify a market opportunity. The business analysts and marketing people sit around and come up with either a new product or a feature that they can sell to their customers. Then they get the designers in, who make a “sweet” interface for it. Finally, a big specification file, describing the new feature and how it’s supposed to work, gets handed off to the developers. They’re supposed to make it all work.
This is what software people call the waterfall, because each step pours into the next. There are many problems with this process, but the biggest is that if any of the assumptions made at any one step are wrong, you don’t know until you get to the end of the entire development cycle. You’ve wasted a lot of time and resources.
Another frequent consequence of the waterfall method is that the final product can vary significantly from what the business analysts thought they getting. That’s because there was no opportunity to check back with the business case during the development cycle.
Here at AboutUs, we’ve always used the Agile method of software development. Now, with Jeff’s help, we feel like we’ve got a very cool improvement to Agile that helps us define what we’re going to build, how it’s going to work, and how it’s going to deliver value.
The Product Shaped Hole
Jeff’s process starts out by identifying who your customers are. This is user-centered design. At AboutUs, we have identified 14-15 different types of customer who use our site, each for a different set of reasons. We have fleshed these types out into profiles that we call “personas.”
Next we started to identify which tasks each customer type wanted to perform on our site. These tasks range from “logging in to edit,” to “reviewing recent edits for abuse,” to using new features we are still developing or would like to develop.
We can take these tasks, turn them into “stories,” and build a “story map” that describes the personas and their activities. Our business goals govern the entire process. They tell us which personas matter, and therefore, which tasks matter. That in turns informs every development choice we make.
So what’s really cool about this story map is that it’s a physical object that everyone can see. It reminds us continually of our business goals and the people who use our site. It governs everything we do, right down to each small, actionable chunk of software, and each of these becomes its own particular story.
Some of these stories have been delivered — our site does lots of stuff already — and we still have plenty of stories we want to complete this week, next month and within the next year.
The coolest thing about this story map is that it’s still alive. You can see what’s done, what we still want to do, and, if you’re the type to read between the lines, what we haven’t thought about. And it’s those unfinished and unthought-of stories that are the “product shaped hole.”
This isn’t a complete description of Agile user-centered design. I haven’t covered paper-prototyping, sketchboarding, walking skeletons or other cool techniques. But story maps have really changed how I think about software and Agile, and it’s going to change how we build things at AboutUs.