Quantcast

Bruce McCarthy is Founder and Chief Product Person at UpUp Labs, where he and his team are at work on Reqqs - the smart roadmap tool for product people.

Sunday
Nov122006

Google docs: almost there

I've been searching for the perfect solution for note-taking and document sharing for a long time. I want something that's easy to use, that I can get to from anywhere, and that I can share selectively with others. I've used everything from email editors to online blogs and offline blog editors, from wikis to discussion forums, from Lotus Notes to Groove, from Outlook to Notepad, and from OneNote to eRoom.

They've all had their flaws and it seems like I've switched to a new solution for nearly every project as a result. But Google docs comes the closest yet to delivering my perfect solution. Here are the key attributes that resonate with me as a user:
  • Simple WYSIWYG editor (think MS Word without the feature clutter)
  • Online editor runs in browser
  • Offline editing mode (via interchange with Word and email)
  • Selective sharing (via email address or general publishing)

Easy editing

The simple editor is a given with most of these tools, but not all. Many popular wikis and discussion boards require you to learn html-like syntax to make bulleted lists, add bolding or italics, and embed links, for example. Good editors like you see in Google docs provide a simple toolbar above the typing area, containing buttons for these sorts of formatting options. Anyone familiar with MS Word will find this interface paradigm familiar and at the same time will be relieved that only the basics are included. 95% of us never (or very reluctantly) use styles or zoom or special viewing modes or any of the other options that clutter up the editing interface. Google docs gives you the essentials without the clutter.

Browser access

It's important for me to have a full-featured online editing capability. First, I find it simpler and more elegant to be able edit and store the document in the same interface. eRoom, for instance, is most often used as a repository for Office documents like Word docs and spreadsheets. So to edit an existing document I must download a local copy, then save it, then upload it again. With Google docs (and as with Lotus Notes, online blog editors and wikis), you click on the document, edit in place in the browser, and click save when you're done. Simple. And the cutting-edge AJAX interface gives you WYSIWYG editing right in the browser. (eRoom does have online editing of some document types, but they are not as easy to use or elegant as those in Google docs.)

Second, I want to make sure I have edit access from anywhere. Not every machine I use has MS Office or other specialized client software on it for editing. The most common example for me is my Mac. I use a couple of different Windows machines regularly (my work laptop and my home PC), but I also use an iMac at home (because it's the easiest way to live the digital lifestyle) and I don't have Office installed there. Outlook has Webmail access, but its Mac support is poor and you can't share Outlook notes.

Offline access 

At the same time, I do need an offline editing mode for those times I am not connected to the net. For me this happens every day for about two hours while I'm on the train commuting to and from the office. This is prime productive time for me because it's a predictable period I can sit with my laptop and not be disturbed. I can't use a browser-based editor when unconnected, though, and many times I've wanted to edit something stored in eRoom but forgotten to download it before heading to the train.

Google docs partially solves this problem by allowing interchange with email and Word docs (Excel documents with Google spreadsheets). Essentially, Word or your email editor becomes your offline editor. This works well in that these are familiar WYSIWYG tools you already have on at least some of your machines. In practice it falls down in a few areas. First, formatting doesn't always survive conversion 100% intact. I tried uploading a Word doc and the formatting looked pretty good. I then downloaded it as a Word doc again and I noted some of the graphics I'd pasted into Word had been lost and some of the text had shifted around the page a bit.

Email integration is a slick idea, but is also not completely reliable at this point. Google gives you a unique email address for your docs account. When you send an email to that address, it arrives as a new Google doc. Google has deftly converted your favorite email editor (including those from rival Webmail providers, Yahoo and MSN) into interfaces for their solution. For users of offline ediors like me (I use MS Outlook), this means Google has an effective offline editor as well. There are teething pains, of course. For example, one email I sent with a large PowerPoint attachment failed to arrive and I never got an error message or any sort of feedback.

The one offline editing feature that's missing is the ability to browse and access your docs when not connected. In that sense, integration with offline email editors is only one way. You can send an email to Google docs, but you can't use your email editor to look for, access or edit an existing document. I could keep Word documents open all day long for updating and upload them when I am done, but in practice this is no better than eRoom (except, of course, that Google docs is free).

Selective sharing 

Wikis, blogs, and most other forms of Web publishing are designed to publish to the world. If you want to restrict access to your content, you sometimes have the option to set a password for the site, but this binary approach to sharing content (access to all or nothing) makes it impossible to share, say, photos with your family and your ideas for the great American novel only with yourself. Lotus Notes and eRoom have more selective security models, but they are difficult to administer, with default groups you set up, exception rules, etc. I've used online wiki provider EditMe for a while and they recently added more granular security, but there is definitely a learning curve.

Google makes this as simple as possible, by using email. Once you've created a document you want to share, you simply enter the email addresses of people you want to share it with and they receive a message with a link to the document. You specify whether they should have read-only access or editing rights as well. This works particularly well if you are a Gmail user, as Google docs is integrated with Gmail's address book, making entering of email addresses for sharing quick and painless.

How is this different than just composing your thoughts in your favorite email editor and sending them to that person directly? Google docs is closer in concept to a wiki or blog than email. It's for content you want ongoing access to and possibly ongoing editing of. Email, in contrast, is ephemeral. Most people delete email after they've read it. Even those (like me) who file almost everything seldom refer to it afterword (like me). For instance, I use my personal wiki to record and publish the minutes of my neighborhood association board meetings, to record business and product ideas, and to take notes for

User>Driven. I also use Apple iLife to publish family photos and home improvement blog entries.

 

Note-taking, Web 2.0-style

Most people use MS Office for permanent documents and attach them to emails when they want to share them. The idea behind Google docs is to have a permanent home online for your documents so you and whoever else you designate can always access the latest version. It also allows for real-time collaborative editing (though I've never seen this sort of feature used effectively).

Google docs get 3 1/2  out of my four key criteria right for a note-taking and sharing application. Co-opting Office and email programs as alternative editors is very clever and effective as far as it goes. To become this user's regular solution, though, it needs an offline editing solution that will never leave me without access to my documents.

Monday
Jul102006

Protest over bussing

The Fourth of July celebration in my small Massachusetts town afforded a painful lesson in usability this year. This lesson was chiefly about poor signage, among other design problems, in the transportation of people to and from the celebration.

Like many American towns, mine put on a public fireworks display. It was held at our local recreation park, a large area with a man-made pond, playground, and bandstand. Because of the large crowd expected, the town used school busses to move people to the park from designated office parking la couple of miles away.

We arrived shortly before the fireworks began, and I was impressed with how quickly we were picked up and transported to the show. More and more people trickled in for the final half hour before the show began and everyone was in a good mood. The fireworks display was impressive, with a bigger finale and fancier explosions than in past years. The town seemed to have outdone itself.

It was only when the entire crowd got up to leave at once that the flaw in planning revealed itself. Once the show was over, everyone filed toward the busses in good order. When my family got there, though, we discovered a lot of confused people milling around, talking to each other and very few getting on busses. Apparently each bus was assigned to take people to one or two parking lots only and the bus drivers were refusing to let anyone not going to their specific lots onto their bus.

Aside from the fact that all the parking lots were within a short walk of each other, the real problem with this plan was the signs. After pushing my way through a crowd of confused people to the nearest bus and peering over the shoulders of several others, I discovered a tiny sign affixed to the bus at about 4 feet above the ground just to the left of the passenger door with laser printed letters in about 18-point type indicating which lot this bus was for. Well over a thousand people were all trying to squint at these signs all at the same time -- in the dark.

After spending quite a lot of time trying to get near enough to a few busses to discern a pattern in how they were labeled, we naturally discovered that we were at the opposite end of the line of busses from where we needed to be. And by the time we worked our way through the crowd, the sole bus allocated to our lot was full and we had to wait with several hundred other frustrated families.

And wait. In all the confusion, the first bus left about an hour after the fireworks ended.

So we waited for them to return. There was very nearly a riot, though, when we all discovered that they were returning and had begun parking in random order! The bus that pulled up where we had been patiently waiting with out children for over an hour now was not our bus! And since they were in random order, the bus driver initially told us that we'd have to go hunting (and squinting in the dark) for our bus all over again. Fortunately, the incredulous look the first person to hear this gave the driver seemed to impart some sense and after a moment's hesitation she let us all on.

All in all, it took us two hours to get home after the fireworks display in our own town. My children spent more time crying (much more) about wanting to go home and go to bed than they did ooing and aahing over the fireworks display.

There were clearly too few busses to take us all in one trip, but I think we could all understand that. The real usability problem was the in dividing the busses by parking lot and then labeling them so poorly. If the busses had been able to fill up from the front of the line and leave as they were filled without worrying about sorting us first -- or if the signs had at least been readable to allow us to do an effective job of sorting ourselves -- we would all have been home much, much sooner.

Design for usability is not limited to software and Websites. It's in everything we produce or plan for others to use. I think I will volunteer to design the signage for next year's celebration. Either that or watch the Boston Pops on TV!

Sunday
May142006

Eating my own dog food

I heard Patricia Seybold speak recently at ATG's Insight Live user conference in Las Vegas. I was there to speak about research I'd done with ATG customers on what sorts of hardware and software they used with ATG's solutions, and about new Customer Intelligence capabilities we are building into ATG solutions.

Patty was there to promote her new book Outside Innovation, which concerns a completely different kind of customer intelligence. In her book, she relates stories of how companies have engaged their customers in designing their products. One example from her talk struck me in particular.

She talked about how Staples responded to customers' inability to find things in the categorization scheme of their online store. Apparently they sent software to some of their best customers that allowed them to place items into the categories they liked. The customers themselves told Staples where the products should go -- and Staples listened. Not only did they rearrange the categories in the online store, but the effort was so successful, they rearranged the bricks and mortar stores to match.

What Staples did is a profound example of user-driven design. I've spoken so often about getting users into the design process that this story inspired me to ask for your participation in developing User>Driven, to practice what I preach or, as a friend used to say, to "eat my own dog food."

I've posted lists of improvements and potential stories for the site in the User>Driven Forum, and I'd like you to rearrange those lists in the priority order that works for you. I've also created a thread for general feedback on User>Driven.

This site not quite what you'd like it to be? Take control like Staples' customers did. Tell me what your priorities are in the User>Driven Forum.

Thursday
May042006

Paper prototyping

My first planned experience with user-driven design was at a seminar taught by Jared Spool of User Interface Engineering. The inimitable Jared had music blaring from the Squirrel Nut Zippers and spent about 3 hours explaining to us in his very animated way the benefits of paper prototyping.

Jared said that no matter how talented your team is, your first iteration of a design can only be a best guess at what will work for the users. You might get it 50% right on the first try.

Well, as  a newly-commissioned software product manager, I was all ears. The solution, Jared said, was to test the product before you build it. How? By simulating the product in a "paper prototype."

Paper prototyping has three main principles:

  1. Invest the least amount of energy possible in your prototype
  2. Put your prototype in front of real users
  3. Give them a realistic task and (this is key) don't help them complete it

The most expensive and time-consuming way to design something is to do the design, ship the product, and then start getting feedback. Many companies do this because they don't understand the design process. They figure if they hire good designers, they'll get good design in the first try, right?

If you assume instead that your first attempt at a product design will fall short, you'll want to invest as little time in version 1 as you can so you can get it into the hands of users quickly and then redesign it to incorporate feedback. The simplest, quickest way to simulate a product with a graphical interface is to draw it on paper.

Not only does a paper version of a screen take just a few minutes to draw (instead of hours of coding, followed by hours of QA), but because it only takes a few minutes to draw, you're not afraid to crumple it up and try again. It's painless to move a button from the top of the screen to the bottom if all you have to do is draw it.

If you've ever asked a developer if you can make just one more tiny little cosmetic change to a product late in the development cycle, you'll appreciate how much easier it is to change things before you've committed anything to code.

Hours instead of releases

This low-tech approach allows for quick iterations between feedback sessions that very rapidly improve your design -- sometimes over the course of hours. And here is where real-world users come in. It's a sad fact that most of the people working on your product (or selling it, or marketing it or running your company) won't ever use it. This means they are not capable of giving you real-world feedback. In order for each of your many design iterations to be better than the last in terms of its ability to serve real customers, the feedback you get must be from real users.

You've got to schedule a series of people who would really use your product to come in and review your design. Then you schedule time in between each appointment for your team to incorporate their feedback into a new paper design (moving buttons, swapping the order of screens, adding helpful hints, etc.) for the next user. With this approach, your design will get closer to the ideal with every iteration. Design. Test. Fix. Test. Fix. Test. Fix. Etc. The more iterations you have time for, the better the design.

Force them to use it

How you do the testing in each iteration is as important as when (before the product is created) and with whom (real users). It's not useful to put the screens in front of people and ask their opinion. Most users will respond to the esthetics and whether you seem to have all the features they expect. To get at whether the product really works for them, you have to force them to use it -- and you have to let them fail at using it. The way you do that is to develop use cases and then ask test subjects to walk through them.

Briefly, a use case is a description of a real-world set of tasks leading to a goal. If your product were bn.com, one use case might be a college student ordering college textbooks. Your use case should tell them they are a college student (which hopefully they really are), they want to buy their college textbooks, and they've been told by the school that the books are available from bn.com. You give them a dummy credit card number and let them loose on your design.

You show them your paper mockup of the home page and ask them to use their finger as the mouse and point to what they want to click on. Whatever link they follow, you provide the next (paper) page. If they want to type something in, you have them write it down. If the content of the page is dynamic (e.g., search results), you have at the ready small scraps of paper that you can assemble on the fly. And there's also no rule that says you can't draw something fresh right on the spot, if the user does something unexpected.

Helping is bad

At some point in this exercise, your test user will inevitably get stuck. They will fail to locate something you thought was obvious, they'll think they're done when they're not, or they'll just throw up their hands with no idea how to proceed. This is where you learn something, so pay close attention -- and don't help!

For the most part, people like to help. But the goal here is not to have them reach the end of the task, it is to see where they fail. Ask the user to think out loud as they walk through the site, to tell you what they are thinking and why they are doing each thing they are doing while they do it, but don't respond if they ask you questions. Find the first point of failure, make sure you understand what caused the problem, fix it, and test it again to find the next point of failure. Keep doing this until there are no more points of failure and you will have a usable design.

What have you forgotten?

Jared's seminar gave me a dramatic lesson in the value of this design approach. After the lecture, he broke us into teams and held a contest. Each team was to design a paper prototype of a touch-screen kiosk for ordering at Taco Bell. We were given paper, pencils, scissors, tape, and glue sticks, along with a list of menu items and prices. At the end, one member of each team was to become the test subject for another team. The team whose test subject completed their order the fastest would win.

I'd been doing different sorts of design for years, so I thought I could blow away the other teams. My team and I set to work and produced a design we were quite proud of. We even took the time to write out a bunch of item names and prices on strips of tape, which we could choose among to add to the paper "screen" during use to simulate a display of the order in progress.

Our test user moved through our paper screens with ease. She even remarked how much she liked our continuously updated order display. She completed all the steps, and then it happened. The moment of learning. She'd entered everything -- and we were ahead of all the other teams -- but we had forgotten the button for placing the order!

The rules said that if your user got stuck anywhere in the process, you had to fix your prototype and the user had to start over again at the beginning! So, we scrambled to add the missing button and (agonizingly) had our user start again. She breezed through the screens a second time, submitted her order successfully, and we were still the first team to finish.

Iterate or die 

We won, but I learned there is absolutely no substitute for real user testing. Get real users, make them use the design, and watch where they fail. Fix the design and test it again.

User-driven design is iterative design. It might not seem as inspired as something your genius of a designer comes up with after pulling an all-nighter, but the magic of that design will fall flat if no one can find the "place my order now" button. 

If you have any thoughts you'd like to share on this post -- or anything else about user-driven design -- I invite you to post your comments here or in the User>Driven Forum.

Page 1 ... 25 26 27 28 29