Usabilla Beta Continues to Improve

I’ve been watching Usabilla for some time now as a beta tester with the expectation of utilizing it on several projects. They’ve continued to make improvements to the app, with the help of our feedback. They’ve also posted new information on their site to familiarize users with their product. This is a review of my recent test with the latest revisions.

Creating Tests

The process is still quite simple: 1) Create a new test, 2) Add pages to test either from images you upload or using URLs, 3) Use the pre-defined tasks and add your own tasks, 4) Invite users to participate.

Test Session

I was initially drawn to Usabilla for it’s 5 second test capabilities, but also wanted to the ability to do more with some screens, e.g. ask users to answer questions in addition to simply showing where they’d click to do something. They provide this with the “add note” function.

At the beginning of a test session, the app acquaints users with the controls they’ll be using. The difference between points and notes is the one thing that I think could use more clarity. Even making the screen above call out, “This is a point” and “This is a note” more explicitly could serve as a sort of mini-tutorial to short-circuit any confusion and familiarize users even more before they start. I just wonder how much people actually read these things because when I started using Usabilla, it took me a few seconds to realize that I had to switch tools to use the annotation tool. It’s very simple and straightforward once you get it, but I feel you have to be reminded that it’s there.

I also thought that I might want a task to require users to answer a question with their click mark, so I wondered if it might be possible to provide only the annotation tool for some tasks. Or perhaps, the point tool could be accompanied with the annotation function? I’m not sure what would work best given all of the use cases, and would be careful of changes because what it does now is simple.

This is what it looks like to add points when completing a task/answering a question.

This is what it looks like when adding notes.

Usabilla does the simple stuff very well. The click to answer / point system works for me, and might be the best you can do with an unguided usability test. The annotation control has improved as well, and I think people who don’t want to add notes will simply use the point control. But in my test session, there were a lot of responses made using annotations, so I find it more than adequate enough for most needs and a pretty elegant solution, given that these tests run on autopilot.

There are a lot of features being asked for in their GetSatisfaction page. Hopefully there’s room for some of the features that are being asked about, e.g. can we test user flows by linking screens together or using linkage between live pages? I think these are great ideas, and if they figure out how to pull it off, it would be exciting to try.

I’d also be interested in some sort of light post-test survey functionality. That may be out of scope for Usabilla, but they provide a nice work-around in that the redirect URL at the end can be pointed to a survey.

The menubar shown in the test is another area that I hope will continue to improve, perhaps as a smaller, fixed bar. Again, the beauty of this tool is that it does a simple thing very well–gets feedback on screens using questions you ask. Asking for too much will mean harder work staying effective for that primary use case.

Analysis

After the test is complete, You can view results using the Analyze section. The pages tested are shown as thumbnails. Selecting a page displays tasks and allows you to select colors to display the click-point markers overlaid on your screen. Markers can be shown as points, clusters, and using heatmaps. Hovering over notes displays the note content.

I’ve provided some feedback suggesting improvements to the flow from Test tab to Analyze tab. Some minor things just need to be cleaned up to improve these interfaces for me, e.g. Analyze links from Test pages should go directly to the right page, Analysis page should use progressive disclosure, etc. Data from the results can also be exported as text.

Usabilla continues to improve with each version. They’re listening to feedback and responding to feature requests. The promise of doing remote usability testing with a tool like Usabilla is not that it will replace formal usability testing. But it fills a gap by providing a service to those who want to do many small tests, e.g. 5 second test, or who only want a few questions answered.

You can try Usabilla for free.

[Disclaimer: After participating in the beta of Usabilla, the company have begun to sponsor this site.]

http://usabilla.com/

What's broken about wireframes and how can we fix them?

Generally speaking I have 2 gripes with wireframes. One is that they're very limited and come with issues in terms of communicating design. Secondly, they're not fast and flexible enough as communication artifacts.

HTML wireframes and prototypes provide some relief from some of the issues, and I'd like to hear what other people are looking for when doing HTML wireframes in order to fix and overcome the limitations of wireframes made in graphics software.

First, here is my gripe list. And for clarity, I use OmniGraffle primarily to create wireframes now.

Limitations for communicating design

1) People have to learn to read low fidelity schematics

You end up with clumsy disclaimers about design, people focus on their rough aesthetics rather than on functionality, etc. This is why so many people find sketch-style artifacts useful. The "unfinished" quality allows people to get past the surface qualities because the final product obviously won't look like that.

2) People sometimes expect them to demonstrate final visual design

This is the other end of the fidelity spectrum. People just have a hard time with both gray box diagrams and with detailed wireframes. Some repeated education and introduction to the wireframe is needed to summarize the purpose it serves.

Limitations when producing wireframes

1) Components are not reusable as updatable instances

Some applications allow you to use stencils and external files imported into a document. But they don't have the behavior of instances, as Flash does, where updating the master object updates instances. You can fake this in some tools, and other tools provide real libraries, e.g. Fireworks. Flex's UI Component Library may come closest to what I'm looking for--library items that can be instantiated and properties customized. The extension of this is to allow the component to be saved and extended so it can be re-used, i.e. a private library.

2) Common behaviors have to be represented multiple times--CRUD, design pattern

A lot of these behaviors can be represented in a design pattern library perhaps. What I've done in the past is to create storyboards for common behaviors across a document, so that their behaviors need only be represented once. Something like this is useful if it can be used with the local library ideas mentioned above. Create a local library of components and they only need to be designed once. Insert where needed in the prototype and the behavior is identical. A separate document can be created to demonstrate all of these and perhaps organize them for developers to view.

3) Some people expect them to be updated constantly, which is hard given the re-use issues

The goal is to both make these easier to update globally and to make small changes. Issues related to this include version control and rolling back changes. This also would be an issue for library components. Documents and libraries can be backed up for brute force versioning, but use of version control systems would be ideal.

4) They're time consuming and therefore costly to make, as opposed to sketching.

I'm still not sure if HTML wireframes will come with time savings, but I am hopeful that their ability to demonstrate ideas more clearly and effectively wipes out those costs by allowing shorter iterations.

What are your gripes?

Do you have any other ideas about what needs to be fixed about wireframes? This is an effort at a "Pony" brainstorming meeting (as in "I want a pony!") to see what other people want to solve with html wireframes that graphic wireframes fail at.

If you want to participate in our project to assemble an HTML prototyping kit, please read our mission statement and find out how to get involved.

Barry Schwartz on the Paradox of Choice

Psychologist Barry Schwartz takes aim at a central tenet of western societies on TED: freedom of choice. In Schwartz’s estimation, choice has made us not freer but more paralyzed, not happier but more dissatisfied.

The idea that more choice leads to paralysis rather than happiness resonates strongly with me. I think about where I am in terms of my spiritual and psychological development, and I do feel dissatisfied when things aren’t perfect today and I find it troublesome that I think this way. But I do remember where choices of some things were limited, although that period may have been very short.

As a Westerner, I think the number of choices put in front of me for any particular consumer item has been overwhelmingly many. Schwartz says this abundance causes many of us to have difficulty making decisions. We become paralyzed. And even when we’re able to overcome the paralysis, we end up feeling less satisfied. The more options there are, the easier it is to regret choice.

I think this is terribly sad, but it is a reality we deal with as interface designers as well. As someone who is working on an incredibly complex piece of software—so complex that I struggle to understand some of the more powerful, yet obscure features—the challenge is enormous. If people experience this flood of choice and paralysis in their everyday experience, you can damn well be sure that they’re not going to tolerate it when they have to use your software to get their job done. Or maybe they’ll tolerate it and be pissed off all the time about it. So you’d better work extra hard not to piss them off.

I think this comes down to making decisions for people. If you have to have the obscure, less utilized feature, the challenge is to find a way to enable its use without creating a cognitive cost in what you present for the primary use cases. We utilize progressive disclosure for some of these things. It’s hard work making decisions to make things less prominent or to cut features.

I think about this great screenshot of the Zune from Giles Colborne’s “Secrets of Simplicity” presentation. When the Zune removed features it got better reviews. That may only be perceived improvement, but it most likely also reflects better decision making around what’s necessary rather than about keeping ahead of pace with the market in terms of growing features, something that Microsoft software is notorious for.

But that’s the job we have to do as UX designers arguing on behalf of the silent user. I think of this like being the lawyer representing a body of plaintiffs that’s suffered damaged due to neglect. Some software companies can defend the position that they’ve made decisions based on what they thought people wanted (more choice) and get away with that. The other aspect of choice is that people can also decide to stop patronizing you and buying your software. The smart companies take notice, become accountable, and invest in making things right even if its at a cost in the short term.

This the mentality we have to take, and the arguments we have to make when looking at the glut of decisions we present users with. We need to be accountable to those who pay us to use our products. The flip side of choice is this. More is not always better. Less is not exactly more. Best is providing the right options at the right time.

http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

Facebook Removes Rounded Corners

It’s not terribly newsworthy, but Facebook’s design team announced that they’ve stopped rounding corners on all elements. I noticed, however, that they kept the slight (3px?) rounding of names in the To: field of the messaging section. That somehow feels like a natural place for an exception to rounding corners for some reason. You know, so you don’t get impaled when backspacing in the field. Kidding. This is a quote from their announcement.

Since we introduced rounded corners to Facebook, their consistent use has been spotty at best. The corner radii vary, and it sometimes feels arbitrary which corners are rounded and which are not. Additionally, they add an extra layer of complexity to the code (note: IE, please add support for border-radius).

As part of the effort to simplify our visual style, the design team recently decided to go back to our square corner roots. In doing so, we hope to champion cleanliness and the razor cut look that Facebook is known for.

See. It’s a “razor cut” look. Pardon me while I roll my eyes loudly. Design-wise, it does have the boxy Facebook feeling of the original, without the muddy bluish gray backgrounds in the sidebars. It’s never been known for being beautiful, but I like that they’re being decisive about their identity and settling on a consistent style.

http://www.facebook.com/note.php?note_id=143248897792

Managing UI Complexity

Brandon Walkin’s article “Managing UI Complexity” offers some excellent pointers or reminders of concepts and techniques that help reduce complexity in an interface, including progressive diclosure, contextual actions, aligment and hierarchy. There’s an abundance of examples with screenshots and deconstruction of interfaces to demonstrate the techniques in practice.

http://www.brandonwalkin.com/blog/2009/08/10/managing-ui-complexity/

Conversational UX Design

[I]f you make it easy to talk to me, I will immediately be a lot more likely to keep talking.

Zeus Jones has a great write up about using conversational language and cues to invite users through interactions. The deconstruction of the lazy trial/registration process in Tumblr is used to demonstrate how this type of engagement makes the learning process natural and inviting. The discussion picks up on the Cluetrain meme of markets as conversations, positing that systems are conversations, and turning front ends into actors that use conversational language as interface. Afterall, if software is to be social, then it may as well learn social skills.

http://www.zeusjones.com/blog/2009/conversational-ux-design/

Keith Lang's Top 10 UX Myths

Keith Lang, co-founder of plasq.com, wrote a fantastic article for Think Vitamin about UX Myths. It’s full of references and examples debunking stuff we hear repeated enough times that they begin to go unquestioned.

The top 10 UX myth list:

  1. The Design Has to be Original
  2. People Read
  3. People Know What They Like
  4. Design Always with Implementation in Mind
  5. Can’t Decide? Make it a Preference
  6. If you Have Great Search, You Don’t Need Great Information Architecture
  7. UX Design Stops at the Edges of the Product
  8. Design to Avoid Clicks
  9. People Don’t Change
  10. If the Design is a Good One, You Don’t Need to Test It

Some of these become so ingrained, that it takes a lot of effort to convince clients or colleagues otherwise. I’ve struggled with many of these beliefs, holdig on to some of the earlier in my career, e.g. I remember heated debates about and broad versus deep and the number of click to get to destinations. I struggle with #2 people read, and #5 preferences and handling options. Those can be huge challenges when you’re looking for ways to simplify existing software.

There are so many nuggets here to be appreciated, and a few observations in UIs that I wasn’t aware of. Check it out. If any of the references are new, you’ll be surfing off the links for days.

http://carsonified.com/blog/design/top-10-ux-myths/