Process

Guidelines For Design Guidelines

by Paul Sherman on January 8, 2010 · 1 comment

in Everything Else

This post grew out of my response to a question on the IxDA discussion board. Russ Wilson, fellow Austinite, UX VP at a large software co., and all-around good guy, posed this question:

I’d like to get people’s opinions on the value of “company-wide” design guidelines (for software applications/websites)?In theory, design guidelines could help to remove design bottlenecks by empowering others to create and apply the guidelines… but in reality they can also be hard to implement, confusing,restrictive, etc.

My response was:

…I can share some lessons I’ve learned while building guidelines and leading teams that produced and consumed guidelines.

1. Treat design guidelines as a design problem in and of itself. Make the guidelines findable, learnable, usable (and memorable) for the intended consumers. This means you need to understand your users’ needs. Some questions to ask yourself and your team are:

* Do they need to know the why behind the guidelines, or do they just need to know how to be compliant?

* Consider whether they (and therefore you) are constrained by the UI toolkit and available controls. That is, do they need implementation-specific guidelines? This is more typical for platform-specific software and certain web-delivered apps. Or do you have degrees of freedom more typical of web-based apps?

2. Make sure people can quickly and easily access the digital assets they’ll need to successfully implement the guidelines. Provide links to the assets (i.e., images, controls, CSS, code snippets, etc.) that will help designers and devs to implement the guidelines. Put the relevant links as close as possible to the guideline. Basically, put on your Tufte hat. (What can I say, I’m almost done with “Beautiful Evidence” so I’m looking at everything through Tuftian lenses right now.)

3. Make it so people can discuss and annotate the guidelines. Also, it’s constructive when the community can submit examples of how they’ve implemented or adapted guidelines. At some point you may find it useful to convert a community submission into a full guideline.

4. Examples examples examples. (And more examples.) It’s often helpful to mock up one of your organization’s existing applications to illustrate one or more guidelines. If nothing else, the team can then practice “cargo cult design” and just emulate your example.

5. Socialize the guidelines…but also socialize a release plan for future guideline changes. Design and dev teams absolutely hate to find out that they’ve complied with R1.0 of the guidelines, but you’ve rev’ed them to R1.1 or 2.0. If you’re making changes to the guidelines, make sure people know when the changes will be rolled out. And of course provide as many sneak peaks as you can.

6. Make sure that you coordinate with the folks who own the visual aspects of your organization’s brand. A little synergy here goes a long way. And they’re usually a great source of brand digital assets.

I thought this was blog-worthy, so I decided to post it. I’d love to hear about others’ experiences in this area of design and user experience management.

{ 1 comment }

UXmatters Article: Testing Your Own Designs Redux

by Andreas Bossard on January 4, 2010 · 2 comments

in Design

This is just a quick pointer to my latest UXmatters column, which is a follow-on to my article from September about the perils and pitfalls of testing your own designs.

In this follow-on, I revisited some of my more bombastic points about testing one’s own designs. Thanks to some excellent comments by several colleagues (and colleague-slash-wife), I modified and built upon my original recommendations and provide some modified guidelines. Here’s the summary guidelines. To understand the reasoning behind them, go read the whole article.

Guideline 1—When testing your own designs, don’t think of it as a test to pass or fail, think of it as part of your design process.

Guideline 1a—Test early, test as often as possible, and test lo-fi prototypes rather than making usability testing a make-or-break event in your design lifecycle.

Guideline 2—When testing your own designs, you should seek disconfirming evidence, but be alert for joys and delighters, too.

Guideline 3—When you’re trying to solve a design problem, usability testing serves design. It’s a tool. Use it to improve your design, not to justify your actions.

Comments about these guidelines? Email me via UsabilityBlog, or comment at UXmatters.

Testing Your Own Designs Redux ::? Paul Sherman via UXmatters

{ 2 comments }

My UXmatters.com Article On Testing Your Own Designs

by Paul Sherman on September 22, 2009 · 1 comment

in Everything Else

In my last post I advised that my pending UXmatters.com article would be covering the topic of whether designers can usability test their own designs. The article is now available here. In it I presented feedback from several people about the wisdom of testing one’s own designs, and generated some recommendations for how to do it well if you find yourself in the position of having to test one’s own design.

Quoting myself:

When testing your own designs,? always concentrate on the negative.

To focus on the negative aspects of your design, try to keep yourself focused on your long-term goal, which is to solve your users’ problems.

I also discussed how to recognize when your design should be scrapped instead of modified:

If your users are unable to grasp the task at hand or are experiencing repeated failures and missteps when navigating your design, you should consider? rethinking the entire design.

Hopefully you’ll find this article useful. Also, the comments in my previous UsabilityBlog post are very instructive. Have a look.? Here’s another link to them.

{ 1 comment }

Low-Rent Usability Tech Tip: Remote Usability Testing With Observers Watching

by Paul Sherman on August 29, 2009 · 10 comments

in Everything Else

Today’s post is a simple little usability testing “tech tip.” It’ll help you run a remote usability test with a participant running an app or browser on your test machine while other remote observers are watching the session.

My investigation into this started when I was asked to conduct remote usability test sessions for my client. (I am an independent user experience consultant who does both interaction design and usability testing.) The client asked if they would be able to listen and watch the test sessions in real time.

Now I know that there’s probably an expensive software package or two out there that would give me the capabilities I needed, but I wasn’t in the mood to spend $800 – $1,2000 USD on something I may not use for another few months. So I poked around the Internetz and discussion groups (including the usability listerv that dares not speak its name…) looking for guidance on how to run usability test sessions with a combo of tools that met my requirements.

In my search I found a suggestion for employing GoToMyPC for participants to access the test system. The reasons for using it were pretty compelling: GoToMyPC offers extremely low latency and high performance. And most importantly for me as the test moderator, it lets me and the participant trade off control of the test system in a modeless manner. That is, when I want to quickly trade control of the test system I can do it on GTMPC without having to go to a menu and select “give (or take) control.”

That still left me with the problem of how to allow observers to watch. Then it occurred to me that any old online meeting service would do; all I’d have to do is run it on the test system, invite the observers to the meeting, and distribute a phone conference bridge to all parties.

So I tried it this week, and it worked like a charm: the test participant had low latency and high performance as they used the application, I had the ability to assume control from the participant as needed without wasting time and unduly interrupting the flow of the test; and observers could watch the test session unfold in real time. (They could also pass me questions via the meeting chat capability or via out-of-band IM.)

So, here’s the deets: for remote usability testing with remote observers, here’s what you need:

  • A GoToMyPC account
  • An online meeting account (most if not any will do)
  • A phone conference bridge

And here’s how you set everything up. Please note that this requires that you be sitting at the test system; aka the target PC for GTMPC:

  • Designate your test system as the target PC for the GTMPC service. This is the PC you want to remotely control.
  • Temporarily change your GTMPC login, password and target PC access code for use with the test participants. You’ll be sending them these credentials, so make sure you’re not using your “standard” personal usernames and passwords.
  • When you’re ready to run a test session, convene an online meeting from the test system with your observers, and allow the observers to view the test system’s desktop.
  • Send your test participant a link to gotomypc.com, with instructions on how to log in and enter the test system’s access code. (It’s pretty easy, there’s not much to it.)
  • The test participant will then be signed in to the GTMPC service and can control the test system…as can you, so be careful not to “wrestle” for the mouse too much.
  • Run the test session.

I’m sure there’s more tricks you could be add on to this basic setup. Here’s one idea: you could record the session using the online meeting service’s recording capabilities.

And it also seems possible to get the remote test participant’s face into the picture somehow, as many online meeting services provide web cam integration. Note that this would require inviting the test participant to the online meeting as well as having them sign into the test system via GTMPC, so be careful before testing this capability. Not to be an alarmist or anything, but on the face of it I’m guessing that this could easily tear a hole in the space-time continuum and open a portal to parallel universes. Or something like that. Just sayin’.

{ 10 comments }

ProductCamp Austin Summer 2009 – User Experience Presos

by Paul Sherman on August 26, 2009 · 1 comment

in Design

For some reason this slipped my mind for the last two weeks. On August 15th I delivered two talks at ProductCamp Austin 2009. Before I link you to the talks I wanted to give hat tips to the crew who put together this ProductCamp. It was a fantastic, energetic, and crowd-driven “un”conference, and I highly recommend attending one if you get the chance. They’re springing up in many major metro areas, so finding one shouldn’t be hard. You can learn more about BarCamps at this site.

The first talk I gave was “How To Achieve A Great User Experience For Enterprise Software” and the second was “From Personas To Production: The Role of Personas, Design Briefs, Stories, Storyboards, and Wireframes in the Ideation – Design – Build Process.” The second one had more people than the enterprise talk; which I guess shouldn’t really surprise me as the enterprise talk is more specialized. But the enterprise attendees were full of good questions and there was lots of good within-audience discussion. The feedback I’ve gotten on these two has ranged from slightly to strongly positive. So I’ll put them in the “win” column.

Oh and my past presentations are also available on Slideshare.net here.

{ 1 comment }

New UXMatters Article: 8 Things You Should Be Doing In Your UX Practice, But Probably Aren’t

by Paul Sherman on July 20, 2009 · 1 comment

in Experience Strategy

So I’m seeing a nice little Twitter spike about my latest UXmatters article “8 Things You Should Be Doing In Your UX Practice, But Probably Aren’t.”

It was a column borne of equal parts desperation and writers’ block. Then I remembered how much mileage Cracked.com gets out of the “X Things” format, and decided to try a UX-specific version. You take your inspiration where you can get it, right? Honest truth, I had low expectations for myself.

The funny thing was when I finished it, I realized that the article didn’t actively suck. In fact it was kinda decent. Of course, it helped that I had some good advice and suggestions from Susan Hura, John Rhodes, and Dan Szuc. But no one said I couldn’t turn to friends/colleagues/wife for a little inspiration.

So here’s a little taste of the article; for more go to the site and check it out yourself. Quoting me:

…here are 8 things you should be doing to improve and grow in your professional practice, but that you’re probably not doing—or not doing enough:

  • Communicate simply
  • Read, read, read
  • Pick a new UX tool and experiment with it
  • Hold a UX stand-down and operational review
  • Stretch yourself outside of user experience
  • Think about your UX career path
  • Repurpose your UX assets
  • Depart from script on user research visits

I hope you enjoy the article, and feel free to comment either here or at UXmatters if you have more things to suggest.

8 Things You Should Be Doing In Your Personal UX Practice… :: ? Paul Sherman

{ 1 comment }

My UPA09 “UX Kit” Presentation & Bonus Audience Comments

by Paul Sherman on June 15, 2009 · 9 comments

in Design, Experience Strategy

Today I’m posting the presentation and source document from my UPA2009 presentation “A Kit For Building User Experience Teams in R&D Organizations.” The talk went very well; nearly everyone in the (somewhat small but whatever) audience spoke up and contributed.

Happily, when I posted links to this content on Twitter I got about a half-dozen retweets, which for a second-stringer like me is not too shabby. So I think you’ll like this preso and the kit doc, which I’ve released under a Creative Commons Attribution-Share Alike 3.0 United States License. BTW you can learn more about this license and what it means at http://creativecommons.org/licenses/by-sa/3.0/us/. Basically, it means you are welcome to make use of the content as long as you attribute it to me and you share any derivative works under the same license. Which I think is more than fair, and leads to boatloads of good UX karma besides.

And here’s a little bonus: I asked my friend and session chair Lyle Kantrovich (@lkantrov for the Twitterati in the crowd) to take notes on the audience comments and contributions; which he peevishly (kidding! I meant happily) did. I’ve posted his notes below.

Before I link you out to the content you might be interested in the “story behind the story” of this presentation. About 7 or 8 months ago I decided to submit to UPA2009, and scoured my hard drive for something appropriate. I realized that I had created a comprehensive resource while at Sage that detailed how to staff, budget and run a user experience team at a medium-to-large software organization. I figured that this was as good a submission as any. Plus, it really fit my whole “get the organizational structure and processes right” theme. If you’ve been reading me for any length of time you know I have a passion for this area of our field, having trained in social/organizational psychology and built several teams over the past 12 years.

So I submitted a proposal, which went something like this:

This submission provides an overview of a “User Experience Kit” that one user-centered design team developed as an implementation guide for other product teams within their global organization. This kit was first released in mid-2007 within the organization, and has been used in the organization to guide the creation of four additional teams since then. The primary audience for this presentation is people who are able to drive change in their organizations and have the authority to support those changes with allocation of resources.

And it got accepted. Yay.

Of course I put off writing the presentation for months, but not for the usual reason (i.e., pure procrastination). As the day of the talk drew nearer, it became clear to me that the kit itself was a really boring story. And I don’t do boring. I HATE boring. I have high standards for presenting, I do it well, and I was stressing out about how boring this talk was shaping up to be.

That is, until I realized that the more interesting story was *why* I had to create a UX implementation guide/kit, what it said about my then-organization (and other organizations), and what we as a field should be doing about it.

And then everything was alright, I wrote some entertaining slides (keep on the lookout for “Captain Obvious”) and I gave a kick-@ss talk.

So, without further ado, here’s what I covered in my talk:

  • The sad truth about the need for a “UX kit”
  • A bit about the kit itself
  • An extended discussion about launching UX teams and spreading UX in medium to large orgs

As I mentioned above, Lyle was kind enough to capture discussion notes, which I’m including immediately below. However, I recommend looking at the preso first (either in .pdf format or on SlideShare) and getting the kit source doc before reading the discussion notes.

Thanks again Lyle for capturing the audience comments. Here they are:

  • Come back with data to show the value of what happened during UX processes.
  • Be more of a teacher – share UX? techniques (aka “UX freeze-tag”).
  • Be flexible.
  • Triage projects early on – to discuss how UX can help.
  • Focus on convincing people who can be convinced.
  • Have an open-door policy on usability lab.
  • Create an internal blog with test highlight clips.
  • Conduct a quarterly UI workshop.
  • Stay relevant – you know if you’re relevant by # of people coming to you.
  • Focus on money/budget & key influencers in the organization.
  • UX has to manage a lot of different things at the same time.
  • “Customer Experience Bar Raiser Review Board”? – executives that help set UX direction.
  • Selfishly share the glory – co-present success stories with clients/partners.
  • Find a mentor/peer outside your organization to learn from, commiserate with and share with.
  • Find an aspirational (design/product) example – something that reflects what you’d like the UX to look like.

A Kit For Building UX Teams [preso pdf]? [kit doc]? ::? Paul Sherman

{ 9 comments }

Design and Process Links Galore

by Paul Sherman on February 12, 2009 · 0 comments

in Design

Hat tip to Ghost in the Pixel’s Uday Gajender for putting together this well organized resource page. Nicely done.

And Whitney Quesenbery of WQUsability tweeted this UX toolkit-slash-process map, which I’m dutifully blogging here. Credit where it’s due: the page indicates that the toolkit was created by Bas Leurs, Peter Conradie, Joel Laumans, and Rosalieke Verboom of Rotterdam University.

{ 0 comments }