seen + learned
Showing posts with label social media. Show all posts
Showing posts with label social media. Show all posts

Doodle4 heuristic review and interface consultation

Posted: Monday, November 17, 2014 | Posted by Debby Levinson | Labels: , , , , 0 comments

Doodle4 is a new app for promoting causes through making and sharing doodles. Pitched at teen Facebook users, the app’s powerful doodling tool and easy sharing process make it simple and fun to build awareness of a cause by creating doodling “challenges” for friends to pass around.

Nimble Partners collaborated with the Doodle4 team to first provide a heuristic review of an alpha interface on web and mobile devices. We walked through the app as “Ione,” a lightweight persona we developed of a teen interested in banning styrofoam containers in her community. The walkthrough uncovered opportunities to improve the flow of use, wording, and engagement. We followed up the review with rapid iterations of sketches to provide specific recommendations for improvements. We remained on the team as iterations were made through beta launch.

Services provided:

  • Heuristic review
  • UI sketches
  • User experience consulting

Doodle4 designer Ryen Leung provides a great overview of this fun tool in the first five minutes of this video:

Goodbye, Delicious

Posted: Wednesday, September 11, 2013 | Posted by Debby Levinson | Labels: , , , , , 1 comments

Social bookmarking service Delicious has just turned ten, and to celebrate their anniversary, the company is launching a beta redesign at next.delicious.com.

Unfortunately, this is the redesign that's convinced me Delicious and I have to finally part ways.

I've used multiple accounts on Delicious for more than six years. While I never took advantage of its social features even before AVOS acquired the company from Yahoo! in April 2011, I liked how easy it was to store and track bookmarks of all sorts, and how clean and usable its interface was.

Yahoo! made some half-hearted attempts at redesigning Delicious before selling it off; the last Yahoo! design is still active at previous.delicious.com.
ETA: Last paragraph stricken, as we heard from AVOS that previous.delicious.com's design was their initial one, not Yahoo!'s last one. My mistake.
previous.delicious.com
previous.delicious.com (UI prior to September 2011)

This design is a little too boxy for my taste, but at least my bookmarks and the date I bookmarked them take center stage, and the search finds numerous relevant results. The current design, however, puts far too much emphasis on a previewing area, throwing off the visual hierarchy:

current delicious.com
delicious.com (UI after September 2011)

I don't like it, but I was able to live with it, at least until I discovered how badly the new application architecture had broken search – which no longer returns as many relevant results as the old search on previous.delicious.com – and that you could no longer edit a bookmark to fix an out-of-date or incorrect link – an astonishing omission for a bookmarking application.

So when I heard Delicious was being redesigned for its anniversary, I hoped these major usability issues would be addressed, along with its disappointing visuals.

Nope.

next.delicious.com
next.delicious.com (beta UI, launch date TBD as of this blog post)

What's working:

  • The simple typography in blue and shades of gray is easy on the eyes.
  • Delicious' corporate blue has always been a particularly pretty shade of the color.
  • Links get an appropriate amount of space in the layout relative to their importance in the visual hierarchy.
  • And ... no, that's it.

What's not working:
  • The vibrant blue in the left column is too strong, drawing attention away from the link area.
  • The mysterious histogram below the user's name, which presumably represents activity over time, but which is wholly non-interactive and therefore utterly useless. (It's presumably an attempt to call back to Yahoo!-era Delicious' history graph feature.)
  • Equally mysterious dual numbers (not shown in this screenshot) that may accompany a bookmark identify whether you were the first user to save a specific link – not that anyone will guess that's what the extra number means without rolling over it for a tooltip.
  • Contrast of the "search" type in its form field is so poor – a mere 1.3:1 ratio, according to Colour Contrast Analyser, when 5:1 is the minimum to hit AA accessibility ratings – that even I, with my 20/20 corrected vision, nearly couldn't tell I was looking at a search box. Heaven help a user who's actually visually impaired but can generally get by without a screen reader.
  • And the unforgivable sins: search still doesn't work as well as it did on previous.delicious.com, and you still can't edit a link.

Worse, there are new usability problems with this design. Consider the tag cloud for a user like me, with 147 tags I can display above my links:

tag cloud with 147 tags
Small tag cloud on next.delicious.com

versus the default view of a tag cloud for another longtime user, with over 2,000 tags:
tag cloud with many tags
Default next.delicious.com tag cloud size for a user with many tags

I hope this user likes scrolling to see his bookmarks.

Presumably the product team assumes that users with this many tags will simply search for a tag rather than relying on their tag cloud to locate things. This would be a fair assumption, except that I'm willing to bet that there are many users who have similarly named tags after years of Delicious autocomplete suggestions (for example, I have "knit," "knitting," and "knitting_patterns"), and being able to browse your tag library is handy for locating bookmarks that may not be filed quite where you expect.

Tag bundles, introduced before Yahoo! sold off the company, were one way of dealing with that problem: they allowed users to create groups of related tags, so if I wanted, I could quickly see just my knitting- or CSS-related tags. To create a bundle in the previous.delicious.com interface, you were shown a list of tags to choose from, which eliminated guesswork and ensured you were likely to catch all the tags related to a given concept.
tag bundle interface on previous.delicious.com
previous.delicious.com's tag bundle creation interface

The beta Delicious UI unfortunately replicates the current one: the tag selection interface relies purely on autocomplete, and while this makes for an uncluttered interface, it's useless for people with long lists of tags. Without the list of tags to rely on, you're bound to miss tags you would want to include in the bundle.
tag bundle interface on next.delicious.com
next.delicious.com's tag bundle interface

I give up. It's my job to help organizations use good design to enhance usability, and this design is neither good nor usable – in fact, it's so anti-usability I'm switching entirely to Pinboard, which has virtually no visual design, but does what I need it to do quickly and intuitively.

I doubt I'll be the only one to finally pack up and go.

Making "Support" helpful - some tips for Twitter

Posted: Tuesday, July 6, 2010 | Posted by Debby Levinson | Labels: , 0 comments

We all run into problems now and then using technology – heck, I'm a pretty tech-savvy person myself, and even I sometimes have to contact tech support. And when I do, there is nothing I find more infuriating and representative of poor customer support practices and user experience than hiding vital support information.

Consider a recent example of this: we're having problems getting our tweets to load on the Nimble Partners home page. I've worked tech support myself, so I know that the first step is to try to reproduce the bug and isolate the problem. Since nothing about our code had changed, and nothing about seaofclouds' script had changed either, I suspected the problem was with our Twitter stream. This was easily tested by successfully loading another public Twitter stream onto our home page.

So, now I knew that @nimblepartners was the most likely source of error. Next thing to do: check Twitter's support documentation and Google for potential explanations. I couldn't find anything, so finally I realized I'd have to file a support ticket. Twitter's support website allows you to log in and check the status of your current tickets, but there's one critically important thing it doesn't easily let you do: file a ticket.

That's right: you can spend all day looking through the otherwise well-designed ticket review pages, but if there's an obvious link to file a ticket, I never found one. After many frustrating minutes, I finally gave up and Googled for how to file a ticket, which eventually got me the right link – on an externally hosted site totally separate from Twitter's Support site. (Update: days later, I discovered that FAQs about account abuse and a small selection of other issues have links to the ticket form – but there's no consistent placement for or treatment of a link area.)

I understand why companies want to drive customers to online documentation: it's vastly cheaper than having a human provide assistance, and most of the time, a good FAQ will solve most of the problems. But there's no reason to hide or bury vital contact information – all this does is annoy your user base, and for a company like Twitter that seems to pride itself on interface simplicity and a friendly, inviting user experience, this kind of hide-and-seek game is antithetical to the way they're trying to present themselves.

One possible solution: make the link available on support FAQ pages as part of a consistently placed and worded "did this answer help you?" area at the end of each question. This hides the link from the casual emailer who rarely bothers to click into or read the support questions, but still makes it available for people who genuinely need assistance. Ultimately, it's counterproductive to annoy customers by implying you don't want to talk to them – an ironic result for a company whose basic mission is to promote communication.

Guest post on designing web-based communities for professionals

Posted: Friday, March 19, 2010 | Posted by Tania Schlatter | Labels: , , , 0 comments

We are pleased to contribute a post about design to Leader Networks' blog, Building Online Communities for Business. We've worked with Vanessa on a few projects, and it is always a pleasure. Vanessa's interest in and knowledge of communities of practice pre-dates the web. She's translated her expertise on the topic from the offline world to the online world, well, expertly.

Designing Web-Based Communities for Professionals

Posted on 09 July 2010. Tags: 
Designing online communities for business is a subtle blend of creating the right business model, a clear understanding and service of member needs and a usable interface that enables professionals to focus on engagement.
Too often, however, the design of professional communities draw inspiration from consumer communities and try to mirror the user experience they experience on non-work based social applications. Frequently, there are far too many bells and whistles – gratuitous features – built into the design of B2B communities that can get in the way of successful use of the community of practice.
While sexy widgets are neat playthings for users who are browsing communities for social or fun reasons, in a workplace setting, they just serve as distractions to getting the job done, the information shared or found, or the connection accomplished to solve a business problem. One of the main reasons why online communities for business often fail to provide a meaningful user experience is a lack of understanding about best practice design for professionals.
With this in mind, I have invited my colleague, Tania Schlatter, to be a guest blogger and share her thoughts on building online communities for business from a design perspective. Tania is co-founder of Nimble Partners, and an award-winning designer who focuses on human-centered websites and applications.
Now onto Tania’s thoughts about context and guidelines to keep in mind when creating user interface requirements, selecting a designer or firm, and overseeing the design and production of an online community for professionals…
What’s unique about designing for a professional community?
Professional online communities don’t need slick features and interfaces to be vibrant and successful. In fact, online communities such as Usenet were at the heart of the birth of the Internet in 1980 and were successful in plain text – before there were graphical web browsers. Usenet newsgroups were lists of topics discussed by reading messages and responding to them in text. Even now, there are active online professional communities that use only text-based mailing lists for interaction, but they are dwindling as the number of graphical tools increases and the cost of developing with them goes down. Yet the essential ingredient remains the same today as it was in 1980 – passionate contributors – which has nothing to do with technical platforms, interface widgets and their design.
The proliferation of low-cost tools has created the expectation that a “best in class” community will usually employ the latest technology. How do you navigate this gap between what’s needed and what’s expected?
What is are the first strategic steps in the design process?
Before you make decisions about features and visual design, you need to know who is interested in your community and what their preferred tools and methods of communication are.
For example, executives we talked to in supply chain management were interested in being able to contact peers with whom they share an academic research partner, but they do not want to do so in real-time. How do we know this? When designing a partner-only site for sponsors of MIT’s Center for Transportation and Logistics, we talked with executives and asked them to select the most interesting content and features from a list of possibilities. We also asked what kind of information and interactions they wanted, and how they expected to use the site. Before talking with the execs, the client was considering a chat feature. Afterwards, we realized that partners were much more interested in robust search features, a discussion section and summaries of research. Had we pinned the site interaction on chat, it would have failed.
The key to taking advantage of the tools available today is to base the community’s feature set on user behavior and how the tools fit their objectives. Learning about your community members in the planning stage allows you to make informed decisions throughout the design, development and management of the site. It helps ensure that the look and feel and features you offer match what users need and want.
Interviews
When planning the community, it is essential to get input from representative users. There are a number of ways to do this quickly and inexpensively, although they may require a fair amount of management to identify participants and schedule interview sessions.
Identify 8-12 potential community members with whom your team has a rapport. Ideally, meet with them one-on-one briefly in person or schedule a 15-minute call. Find out what social media tools they are currently using for business, when and why they use them, what their pressing concerns are, and if/how those needs are being met. This number of interviews will provide a good range of input while still being manageable. If you have a community with a diverse set of user types, such as a community for lawyers that covers many specialties, you may need to interview 3-4 representatives of each major group.
Document what you know
  • Document the business perspective: identify and articulate the organization’s goals for the community. What will make it successful? Are there metrics?
  • Develop user scenarios. User scenarios are stories about who will come to the site and why, told from the user perspective. They should be composites of what you learned from the interviews and should define the most common examples of what people will be looking for and sharing, and the situation of use. You can create these with your own team or with the help of a community builder or user experience designer. Developing scenarios is a good test of concepts – if your scenarios feel forced, the team will know there may not yet be compelling reasons for people to use the community.
Visual design
Your community’s overall look and feel should generally be simple, straightforward and convey aspects of the parent brand to keep the focus on interaction and content. But “simple” doesn’t mean “undesigned“ – every element, intentional or not, will communicate.
At a minimum, the design of the community should include:
  • logo or unique typographic treatment for the name of the community (Identity)
  • color palette
  • graphic style for navigation
  • typographic treatment of all text including heads
Home page and profile page templates for INmobile.org
invitation-only community for executives in the
wireless industry.
Does the community need to look like the corporate web site?
Unless you’re creating a stand-alone community unconnected to a business or organization, the design of the community should relate to the parent organization’s logo, typography, and other brand elements. Chances are that community members are aware of the connection to a parent brand or sponsor, and that this is a key reason they’re drawn to the community. A familiar look will help people feel comfortable and confident that the community possesses the same high-quality characteristics of the parent brand or organization.
Communities often have a growing body of content. How should the content be structured?
Even blogs and communities need a solid information architecture. In an online community, this may take the form of categories for features and discussion forums, as well as tags that help users narrow in on the content that most interests them. Search is an essential and expected feature, and ideally provides more than just keyword-based results, such as results organized by type – article, discussion topic, video, etc.
To develop the information structure, list and prioritize features and content based on what you’ve learned, and have the designer or developer create a prototype or wireframe sketches. These are great tools for usability testing, and will allow the team to explore options for the best ways to engage your community members.
Wireframe sketch for a home page for partner executives 
of MIT’s CTL Program
What are the most important features to have in the community?
Remember the success of text-only communities? Include only the essential features that you know will allow people to find information, share it and exchange ideas in a way that fits their situation and the parent organization’s goals.
For example, features that show activity are likely to encourage participation, like a crowded restaurant: “everyone’s here – it must be good.” Other features are a less certain win. Josh Porter, a designer who specializes in community UIs, recommends the use of ranking contributors (“reputation points”). In his experience, successful communities hold participants accountable for their contributions, and the possibility of recognition encourages “good” behavior and discourages “bad” behavior. In my experience, like real-time chat, a feature like this is never an automatic “must have” – it can make or break a community, and should be implemented only if it fits the culture of your community and facilitates sharing.
After the community has been designed, what needs to happen to maintain it?
The key to maintaining your site’s design is consistency: using the color palette, type styles and page templates when adding content or making any changes. These elements are a rulebook for ensuring your community continues to look neat and professional. Make sure your designer provides a style guide or other document explaining how to keep the site looking great, and that the developer is willing and available to make changes if and when needed.
Also published on Leader Network's blog: http://blog.leadernetworks.com/2010/03/designing-web-based-communities-for.html