Thursday, November 13, 2008

Look At Your Own Product

I had UX Office Hours at StartPad again today. Two of the people that I talked with today were building very different products, and we had very different discussions about them, but the takeaways were very similar. I promised not to publish details, so what I write today will be a bit vague.

The first person is building a web service for Windows users that is supposed to be an integral part of their workday. He'd built a lot of behind-the-scenes infrastructure plus a Windows application for his users. The good news was that it all worked pretty well. But the bad news was that he had built an interface that is similar to some of the parts of Windows and Office that users find the most confusing.

The other person is building a Facebook application. The good news was that he has a unique value proposition which I think will go over really well with users. But, before new users get to the value proposition itself, he's asking them to refer their friends, then he was giving them lots of messaging about the value before delivering any actual value.

Both developers had made the assumption that what was good for somebody else was good for them. Yes, Windows and Office are very successful, but that doesn't mean that any particular pieces of their interfaces are good, nor does it mean that emulating those pieces is good for another product. Similarly, there are tons of Facebook apps in which the very first thing you do is invite your friends -- send them imaginary chocolates, virtual flowers, or make them a knight in your kingdom. But, that doesn't mean that's the right thing to do for all applications. In both cases, the result of these assumptions was a number of unnecessary obstacles placed in front of potential users. And, as I've said before, every obstacle is a reason for users to go away. Instead of looking at how other products do things, they need to look at their own product -- put themselves in their users' shoes and think about what will drive adoption.

On the positive side, both products had resisted the temptation to broaden their reach. They were both focused on doing one thing really well and I have to say that it's great to see it (one of them had even implemented and then removed a de-focusing feature). As a result, I think both of them will have a relatively easy time modifying their products to better reflect their users.

My next office hours are December 11th, 2:00-6:00PM.

Friday, October 31, 2008

Twittering Puzzles

This is really cool to see in my Twitter stream:


I like this because it's a very nice, simple way to spread the word about Puzzazz and increase viral signups. Simply set up twitter in your Puzzazz preferences, and you'll automatically get a tweet each time you solve a puzzle. I don't tweet misses, only solves, so you never get embarrassed.

There are two other recent changes to make Puzzazz even friendlier. You can subscribe to the Puzzazz feed in your blog reader, or you can sign up to get puzzles emailed to you every morning.

Thursday, October 16, 2008

Lose the Landing Page

This month, I'm mostly blogging on thisDev about my 30-day adventure to build a consumer web service from scratch. Today's topic is about user experience and I thought it's interesting enough to cross-post.

It's about the landing page, that stalwart of web sites that serves as a gateway (or a roadblock) to the rest of your site. If you're thinking about having a landing page on your web site, the short version is: don't.

For more details, read 19 Days: Lose the Landing Page.

Monday, September 29, 2008

Designing the Puzzazz Logo

One of the most popular posts on my web site is about logos: One Thing About Logos. I'll have to admit it surprised me, but, more than six months after I posted it, it still gets hits every day from people trying to figure out how to design a logo, or how to get somebody else to design a logo for them.

So, here's another thing about logos.


This is the logo that I created for my new puzzle web site, Puzzazz (which you can read about here). The first thing I did was define what I wanted the logo to convey. Puzzling, a sense of fun, solid, but not too professional.

Next, I put the word Puzzazz into a lot of different typefaces -- about one hundred in all. I really wanted to get a feel for the word and what would reflect my values. This was really useful, but I didn't pick the font just yet, although I'd narrowed it down to a set of about a dozen sans serif and lightly serifed fonts. Instead, I turned to what the entire logo was going to be.

With most logos, you have two basic options -- an icon or symbol plus text, or just text, possibly stylized or incorporating an icon as a letter. For an icon, you really need a solid icon and I just couldn't see that here. Most of the icons I could think of were tied to a specific puzzle type and the only one I had that wasn't was a "?" symbol -- and that just didn't work with Puzzazz. So, I started looking at the letters and what I could do with them.

Puzzazz has four Zs in it. Do you know how many words have four Zs in them? Not counting "pizzazz," which was the inspiration for Puzzazz, there are two (that's a bonus puzzle right there). But the four Z's are both an opportunity and a problem. I spent a lot of time creating Zs. I took Zs out of a bunch of the fonts I was considering and tweaked them. I created some really cool Zs and some really cool ZZ pairs. But, basically, they were all too cool. The Zs were so neat that the other letters were overshadowed and the whole word became harder to read. If I pumped up the volume on the other letters, the whole word just became wacky. So, I realized the Zs were more of a problem than an opportunity and I had to make them pretty normal.

So, I turned to the P, which isn't too surprising. After all, when a logo has a special letter, probably nine times out of ten, it's the first letter. It was at this point that the idea of combing the P with a ? occurred to me. I drew a few and realized it was time to figure out the overall look. So, I went to my narrowed-down list of fonts and picked one. Here's the font I ended up with:


If this doesn't look familiar, it should -- it's Arial Bold. But, if you compare the letter forms to what I ended up with, you'll see they're all different. Still I liked the overall letterforms and it's a lot easier when you have a starting point than if you start from scratch. First, I adjusted the weight of the letters to something I liked better, and I reshaped the Zs to decrease their heaviness and take away the rigidness that I feel the Arial Zs have. The angularity and steeper vertical lines also makes the negative space in the two ZZ pairs more irregular and more interesting, which is important to keep those letters from dominating. Next, I created the P, figuring out the size so I could get the ? in there and make sure both the P and the ? were completely readable without interfering with each other. Finally, I replaced the A with a completely new letter modeled on the U, which eliminated the visual breaks around the A and gave the whole word a more uniform look. With the logo almost complete, I tried a bunch of different sizes for the P (relative to the other letters) to see what would give me the best look, and I ran the logo by a bunch of people to get feedback on the sizing.

Now I was ready for color. I tried a bunch and liked a lot of them, so I decided to use them all and not have an official color for the logo. On the web site, you'll see the logo in 9 different colors. And here it is in another color:


Finally, as befits a logo for an internet site, I created a favicon of the P:


So how did I do? Let's review the key things that I said any good logo should have:

It's about one thing. The P is it.

There can be a second element for flavor, but it has to be subservient to the one thing. The rest of the letters, even the Zs, are not a second element -- they're just letters which fit the word, which was the whole point of drawing them. You could argue that the colors are a second element, but that's certainly subservient since, at any given time, you only see the logo in one color.

The logo must reflect the identity. Let's see...
Puzzling - What could be more puzzling than a question mark? And embedding it inside the P means that some people don't notice it immediately, which provides a nice discovery moment for them.
A sense of fun - I think the ? conveys this a bit and the colors help.
Solid - The weight of the letters conveys solidity. The Zs are simpler than many, which reinforces that.
Not too professional - The pointed corners on the Zs and the curves of the U and A help pull the logo back from being too professional.

The logo must look good in black & white. Got it, though I do think it looks great in color.

No tiny detail. Check.

I'm happy with it.

Friday, September 26, 2008

Takeaways From UX Office Hours

I had my first User Experience Office Hours today at StartPad. The idea is that, once a month, I'll spend half a day helping whoever shows up with user experience issues. It's free and I don't get anything for it (in fact, if you count parking, it costs me). I'm doing it largely to give back to the community, but I'm not oblivious to the fact that my efforts might indirectly contribute to a future consulting gig or even a job. Even better, maybe I'll benefit because somebody else with skills that I don't have will step up and end up helping me in the future.

One interesting thing today was how different and how similar my four visitors today were. Because I didn't say I was going to blog about it, I'm going to have to omit the details this time around.

Two of the people had completely unpolished user interfaces and two people had user interfaces that were attractive already. The four products were in four completely separate areas with radically different user bases. Two were pretty early and two were getting ready to ship.

Three of the four shared a common problem -- they were doing more than one thing. Here's a good rule: Do one thing and do it really well. This is a good rule for UX in general -- focus your UI on what you want to enable for your users and make every part of your UI resolve around it. But, this is a particularly good rule for startups. You simply don't have the time or luxury to do two or more things.

Put another way, your startup is making a bet. What is that bet? Figure it out and go all in. Don't make two bets or five bets. If you believe that your widget is going to change the world, don't also build an anti-widget just in case you're wrong. That's a way to fail even if you're right.

Not surprisingly, all four really needed to understand their potential users better. This is an issue even at big companies. There are lots of techniques for this, but, fundamentally, they all boil down to this: if you were a user, what would you want? One guy's project is for use by experts in a particular domain. He didn't even know how lucky he is -- there is no UI easier to design than one that's for experts. Experts know the domain, so you don't have to explain anything to them. They're willing to learn your product if it makes them more efficient. If you're a developer, think what you want from your IDE. Raw speed. Same here. This doesn't mean you should make it ugly, but looks certainly aren't the high order bit.

In another case, a small company had built some really cool technology which integrates with software from a certain large company. But, they're trying so hard to fit in that they don't stand out. In a large sense, their company is predicated on the notion that the big piece of software isn't satisfying the needs of some users. I think they're right. Yet, their small product looks too much like the big product. In terms of the user interface, it's similar in more ways than it's different. And they need to be different -- if the big product isn't satisfying user needs, they need to be less like it, not more like it. They need to understand those dissatisfied users, figure out how what they've built will satisfy those users, and put that front and center. Unfortunately, it's hard work, so this problem was the one where I was the least helpful.

All in all, I think it went well. I learned a few things myself and I certainly hope my visitors found it useful. Future office hours will be on the third Thursday of the month, so that makes the next one Thursday, October 16th, from 2-6PM at StartPad. Maybe I'll see you there.

Wednesday, August 27, 2008

What's a Mockup For?

Back when I was at Microsoft, I participated in a couple of UI design competitions. Someday, I'll write about the one where we had 15 minutes to design an interface from scratch in front of a live audience. But, today, I'm writing about one where we had the luxury of a whole week to design an interface from scratch.

I was assigned, at random, to a team of four people, competing against three other teams of four people each. We were given the challenge on Monday morning and we had to present it to the entire group on Friday. I have to confess I can't remember exactly what the challenge was, but it was something to do with databases.

We had to analyze the situation to determine the key pain points, come up with an approach to address those pain points, design the user interface that would accomplish that, and create a complete presentation with showcased our interface and explained why it was the best possible solution. We had a decent, balanced team, with people with different strengths, so it was not hard for us to do those first few things. By Tuesday, we knew what we wanted to accomplish and we had sketched out a design on the whiteboard in my office. We were on our way! But, while many teams had artists, our team didn't have one. We'd seen some pretty slick presentations in previous weeks and we knew there was no way to pull that off.

We decided that our best course of action was to present hand-drawn interfaces, much like we had on my whiteboard. So, after trying a few different techniques, we ended up drawing pieces of the interface by hand, scanning them in and then adding text in PowerPoint. It made for a pretty effective presentation. It got our points across, but the drawings didn't look like we were trying to show off.

Recently, I ran across a tool designed to make UI mockups that captures the same spirit. It's called Balsamiq Mockups. This week, I needed to draw some UI mockups and I thought I'd give it a try. First the bad news: Balsamiq is not a perfect product. It has some interface flaws that make it clunkier to use than it should be. Case in point: rather than a toolbar or a fixed property pane, Balsamiq Mockups has a "Properties Inspector" which appears and disappears, moves around, and changes its content depending on what you have selected and where. When it first appears, it's basically a gray-on-gray mess and nothing in it is targetable until you move the mouse pointer over it. It's a bad attempt at interface innovation (and a bit surprising for a product for people creating interfaces).

But don't let the bad news discourage you. The fact is that it's a pretty good start. He's got a healthy set of interface elements, a good way of editing them quickly and efficiently, and a nice automatic gridding system that helps you lay out your interface elements. And, none of the flaws got in the way of my knocking out some pretty decent-looking mockups in just a few minutes, much faster than it would have been in the tools I use most frequently -- Photoshop, Illustrator, PowerPoint, or even just typing text (which is probably my most common mockup creation tool). The example below was done in about a minute. And the Balsamiq Mockups results accomplished exactly what I wanted to accomplish -- they let me play with my concepts and get my points across.


I'm hoping that the author (who refers to himself as "one guy in his studio") fixes some of the flaws and resists the temptation to make it into the next great UI design tool instead of a great mockup tool.

It's important to remember that a mockup is just that -- a mockup. It's not the final UI. There are times for pixel-perfect mockups and there are times for concept mockups. We already have some great products for the former; it's nice to see someone build a product around the latter. Now we just have to figure out when we should be using each tool.

Tuesday, July 29, 2008

Spam from GMail

I really like how GMail matches its advertisements to the content of my email. In this case, I had just marked an email as spam: