Todd Moy, Senior User Experience Designer
Bio
As an advocate for the end user, Todd conducts user research, requirements analysis and usability testing to create organized, well-structured Web sites that visitors enjoy exploring. Before coming to Capstrat, Todd worked as a senior systems analyst at Countrywide, Inc., working with users to translate requirements into technical architectures for Web applications and intranet portals. In his position as financial analyst at the Naval Sea Systems Command in Washington, D.C., he helped develop and implement NAVSEA’s first unified financial reporting structure. As the portfolio manager for financial management, he drove a 31% reduction in software systems and provided authoritative decisions on IT investment, with regard to congressional provisions and limitations. Todd’s diverse background also includes advertising and graphic design. Prior to his job with the Navy, Todd was a graphic and Web designer at the Mobile Ad Group in New York City. He created large-format outdoor advertising for more than 50 national and regional clients and planned campaign strategies using traffic routing, population and market demographic data. Todd earned a master’s in management of information technology from the University of Virginia and a bachelor’s degree in fine art with a minor in information systems from Old Dominion University. He graduated summa cum laude.Articles
-
Why Chatroulette's days are numbered
I'm not gonna lie. I had a ton of fun with Chatroulette.com today. If you don't know about it, essentially it's a webcam site where you get randomly assigned someone else to video chat with. You'd be surprised at how much fun it is to act for the camera--to an unknown audience--and with no repercussions.
For example, at Capstrat, we:
- faked old people trying to change the channel
- staged skits which included a life-size Pillsbury doughboy head
- and much more...
Other folks also took creative liberties, saying they would:
- caricature the other people
- ask people to emulate smiley faces
- and so on...
Chatroulette is undeniably fun for a few hours. Heck, part of the fun was the "roulette" aspect, which I'll get into later. Will it last more than a month? Nope. It will soon get panned and relegated to the annals of web memes.
Chatroulette's bullet
If you play Chatroulette long enough, you'll find that you have about a 1 in 20 chance of seeing someone doing disturbing acts or saying unspeakable things. I won't go into it here, but expect to see things you cannot un-see or un-read.If you participate, this is what you must endure.
You will be exposed to the rawest of human sentiment and action. Why?
No Social Identity
Chatroulette does not require any login or, by extension, require any actions to be tied to a social identity. Users are truly anonymous and can participate with no barrier to entry, save for having a Web cam.
With no identity or reputation tying them to their actions, users are free to do as they please. Even unmentionable acts. There's no way to ban people and there are no community guidelines.
Without identity or rules for interaction, a social site risks falling into a mudpit of tirades, personal affronts and lewd behavior. There's no incentive or disincentive to act properly, so why should people?
I'm an optimist and believe most people are inherently good, but there will always be a population that challenges this assumption. We have to account for these ruffians.
Where to go from here
When you create any social system, think deeply about how to deal with the edge cases. These are those folks who want to act in a way that's contrary to your principles. In particular, you should:
- Create short, understandable community guidelines. Be human and avoid legalese.
- Implement social identity schemes like accounts. Make people accountable for their actions.
- Build in community moderation. Let your users help you flag and cull away the riff-raff.
These are just the blocking and tackling tactics you can use to help your community thrive. The Yahoo Design Pattern library and the book Designing Social interfaces provide more exhaustive tips on designing social sites.
-
Tom Selleck Waterfall Sandwich
This is why Web 2.0 is awesome. Not because of twittering, citizen journalism, AJAX or wet shadows. Nope. It's because someone somewhere now has a platform to follow their dream. Dreams like making pictures of Tom Selleck, waterfalls and sandwiches.
-
UX Tip: Banish Your Users
I constantly hear sentences like "users want such-and-such." I cringe every time. This might sound strange coming from a user experience designer.
Users are not vague outsiders. To misquote Charlton Heston, users are made of people. They're specific types of people, with names and lives. And consciously or not, these folks have to decide whether your product helps them accomplish their goals.
So, you need to know them intimately.
Let's role play.
Pretend you have a recipe Web site. Think your "users" are people who want recipes? Nope. They're people like Mary.
Mary is an unmarried mother of two. She works double-shifts when she can and is studying for her GED. She needs to feed her kids a cheap, nutritious dinner in under one hour because she has to study from 9pm to 12am.
You can picture her right? She might sound like someone you know. You can empathize with her deeply. And since you now know her, you can make informed decisions on her behalf.
Building for Mary.
So back to the recipe site. Assuming people like Mary are your priority, you might decide to:
- Build your database around easy-to-prepare meals.
- Show ingredient substitutions, in case she doesn't have something on hand. Help her minimize trips to the grocery store.
- Add a "Find recipes that use..." search tool, so she can find recipes that use ingredients in her pantry.
- Allow recipes to be filtered by total prep and cook time.
- Write a series of articles called "One Pan Dinners."
- List nutritional data with comparisons to daily allowances.
- Let her scale ingredients by the number of servings.
- Create a tool that scrapes Kroger's sale items and emails her a customized weekly menu, replete with shopping list and coupons.
Furthermore, this newfound focus helps you decide what not to invest in. Knowing Mary, you might not:
- Spend time adding recipes that use squid ink and other Iron Chef-caliber ingredients.
- Court advertisers like Viking ranges, Le Creuset or Whole Foods.
- Build a MySommelier app for recommending wine pairings.
Here's the point.
Real people use your product, not users. If you can't describe them like they are your next-door neighbor, then you can't design for them. Get to know them intimately and banish the word user from design discussions.
Need more convincing?
Sam Farber saw his arthritic wife struggling to control a carrot peeler. With this person and her situation in mind, he started prototyping kitchen utensils that were singularly focused on ergonomics. After testing and refining with real people, his work became the OXO Good Grips line. By considering real people deeply, his kitchen utensils redefined a household commodity and created a new market.
-
Progress bar alternatives in the UI
A few posts ago, I talked about the pseudo-formula :
Behavior = function(people, environment).
Succinctly, to elicit a certain behavior you can manipulate the environmental variables. People are who they are and it's hard to coerce them in to behaving a certain way.
When I wrote that original post, I was thinking mostly about functionality. You can change the features you offer, such that you channel people's behavior. If a certain behavior is desirable, then build out tools to support it.But is that enough?
On a recent project, I was thinking about how to subtly encourage people to complete an action. The behavior we wanted was engagement: reading content on a site and completing certain activities. Drawing from patterns used on LinkedIn and online dating sites, we settled on a progress bar to encourage certain types of interaction. Surprisingly enough, knowing that you're "incomplete" is an incentive to perform the next suggested action. This is especially true if that action substantially changes the completeness.
But on thing still nagged at me. The site was designed to be very personal. The progress bar, on the other hand is a bit cold. It unemotionally calculates the height of a bar based on elementary math. So I started thinking. People tend to be attracted to faces. What if the progress bar was humanized a bit?
Below are four comparisons of the same data. The first is the pure math, where completeness is expressed as a percentage. The second is a typical thermometer, which shows the completion differential. The third and fourth make this a bit more human. The third simply adds features, giving it more personality and expressive qualities. The fourth takes a static image and brings it out of the blur and into clarity.
With the last two, you lose a bit of the differential--i.e. your degree of completeness. But in the process, I think, you gain something a bit more humane and ludic.
What do you think?
-
An Improved Twitter UI?
Part of what makes Twitter so enjoyable is how simple it seems. Let's face it--Twitter is a single text field where you type in your allowance of 140 characters. That's it. But under the covers is a set of commands, some sanctioned and some not. In the periphery are other sites and applications that layer on features which tie into Twitter's API. The Twitter platform itself is quite rich in terms of features.
Just for fun, I thought I'd see what Twitter might look like if it exposed some of the more commonly used features directly in the interface. Things like:
- messaging users both public and private
- providing a URL minification service
- allowing image attachments
- retweeting
- scheduling future tweets
- specifying hashtags
- Abandoned the 140 character limit
- Let people favorite tweets
- Threw in a social bookmarking widget for good luck.
Note: the redesign is a parody. I'm quite aware there are obvious IxD problems.
-
A modest proposal for marketing
What I'm about to say might be be considered treason, seeing as how I'm writing this on Field Notes. But I'm throwing it out there to open discussion.
What would happen if companies simply took their marketing dollars and reinvested them in their business?What would happen if...
- an online retailer on-shored their call centers and hired more phone reps?
- a car insurance company used the funds to lower rates and pay more claims without hassle?
- a product company applied the funds to improving their product?
- a mutual fund paid its customers back in lower maintenance fees?
The scenarios above are somewhat fictitious. But the funny thing is, some similar companies exist. And some of them are pretty successful too. American Funds is one of the largest mutual fund companies with a commitment to low management costs. Zappos.com is a star retailer with a world-class call center and return policy (and one whose 800 number is easy to find!).
Now, their success cannot be solely attributed to a small marketing footprint--but their decision to forgo these costs is not trivial either. So would this strategy be good for other companies?
Proponents might argue that this is a good thing. Why not use the money to make a better product, improve the experience, or differentiate on price? Surely, the resulting goodwill and word-of-mouth would step in for the formal messaging.
But would it? Detractors might say such efforts are doomed to being unnoticed. They might argue that companies like Zappos are edge cases. Or there might be differences in business models that make such a proposition implausible.
What do you think?
I have my own opinion, but I want to hear yours. Is redirecting marketing dollars back into the business a good thing? What do you lose in the process?
- an online retailer on-shored their call centers and hired more phone reps?
-
WAI-ARIA: a high level summary
Making sites accessible for disabled users has always been an afterthought. Right now, making sites usable for low-vision and blind users is a cobbled together assortment of best practices and hacks. Image alt tags, semantic markup, and "skip to content" links are a few of the techniques we use to address the problem.
The problem is that these were added after the fact--and that they were designed for the static Web. It comes with it a number of problems.- Custom components are common. You can make a thumb-slider out of a set of DIVs and some images, for example. But the only elements that are natively navigable through the keyboard are links and form elements.
- In-page state changes, such as AJAX updates are also common. To assistive technology users, however, it can be difficult or impossible to determine what has changed on a page.
Enter WAI-ARIA
Web Accessibility Initiative’s Accessible Rich Internet Applications (WAI-ARIA) is a specification designed to provide better hooks for assistive technology (AT) devices. To Web developers, it's a set of attributes that bolt on to the HTML elements you know and love.
These attributes help you provide instructions to AT devices, such as:
- Describe what objects are, using Roles. For example, you can define how one set of DIVs is a section vs. another set of DIVs, which represents a progress bar. This helps navigability of the page by providing much-needed context.
- Describe the States of objects, like "this progress bar is at 34%."
- Make any element keyboard focusable -- or not. This overrides the tabindex attribute and allows it to be applied to any visible element. Users can tab more effectively though the areas of your page.
- Designate places on a page to receive updates and changes with Live Regions. This is kind of analogous to the yellow fade technique, which is commonly used to visually indicate a state change on an AJAX-y page.
Support TodaySupport for ARIA is strong and building, with Firefox 3, Opera, WebKit / Safari, and IE 8 actively implementing this spec. Freedom Scientific's JAWS screenreader is also building in support.
Adding ARIA attributes won't break current pages , or obsolete old browsers from your site. It only makes inaccessible widgets more accessible. It will, however, make your pages invalid XHTML or HTML. This is because those namespaces do not acknowledge these new attributes. HTML 5 is expected to include these, whenever it comes out. Nonetheless, the idea of avoiding ARIA because it doesn't validate is a weak argument.
If you're designing a site that you expect will receive traffic from visually impaired users, it makes sense to check out ARIA. -
What happens when you give employees 100% instead of 20% time?
Meetup.com was facing issues about two years ago. Their service, which enables people to discover other like-minded folks, was gaining traction. They started growing in response. Meetup went from a startup with a handful of employees to one that totaled around 60.
In this lurch-y adolescence, they began looking to big businesses for organizational and management models. Processes and structure were put in place. Two governance panels were created. A 16 step release process was enacted.
All of this was designed to to instill greater quality and help Meetup handle its growing pains. Yet the opposite occurred. Releases of new functionality to Meetup.com were stalled. People were at each other's throats. They were becoming less responsive to their customers. Employee morale tanked.So began "What happens when your give employees 100% instead of 20% time? ", a panel hosted by two of the brass from Meetup.com at SXSW09 . What continued over the next hour was incredibly compelling. In the next few paragraphs, I'll recap what I heard.
Confronting the problem.To confront the problem, executive management convened a two week marathon meeting. The goal was to walk out with a plan to reclaim the spirit of Meetup's beginnings. For two weeks they deliberated and, at the end, they walked out without an answer.
But coming out totally empty-handed wasn't doable. The execs decided they would stall for a bit longer. To the staff, they announced that all work on Meetup would cease. In its place, they would hold a six week hackathon.
The Hackathon.The hackathon was simple. Any employee could work on whatever they wanted--given three basic rules.
- Your project had to help out the Meetup community. This limited off-strategy projects.
- You had to convince three other people to work on this with you. This limited pet projects.
- You had to impress your team. This encouraged cool ideas.
Employees could also volunteer to work on any project suggested by their peers.
After presenting this plan to the staff, management excused themselves from the discussions. After less than an hour, ideas were flowing and groups forming. Over the next six weeks, teams collected and commandeered board rooms. People moved desks. Titles and seniority were cast away. In their place, people began to organize based on who was best able to execute their piece of the project.
At the end of the hackathon, lots of projects were in flight and making progress. Nothing was released yet, but the volume and quality of work accomplished was staggering. But sensing the end, employees started asking questions about what was next. Would they revert back to their old norms?The honeymoon is over...or is it?
In the six weeks, there was little solid direction on how Meetup would be run in the future. The management team looked back at the hackathon. A lot of work had been done to date. Could the business keep working like this?
The team drew up five pages--on 8 pt type--of reasons why it wouldn't work. "How do you measure and reward employees?" "How do you keep on strategy?" "How do you get VC funds when you have no real roadmap?" These were all questions with no answer.
Out of these five pages though, the realized most were edge cases. If they could handle these as they occurred--rather than being prematurely defensive--this might work.
100% time.At Google, those in engineering roles get 20% of their time to devote to projects they personally want to do. At Meetup, the idea is 100% time. Employees both propose and self-select the projects they want to work on. Teams form and disband based on what interests their members.
Teams can choose whatever methodology they want to work in: agile, waterfall, whatever. They choose how they want to manage communication. Management helps in setting goals and holding people accountable, but the freedom for day-to-day execution rests solely in the hands of those in the trenches.
Where they're at.The speakers were very quick (and humble) to point out they had only been at this for about 18 months. They didn't know how it would scale. There are some product consistency issues. Performance management is still a bit nebulous.
What's your take?
But the side effect is that employee morale has improved. They're more responsive to their customers. The Meetup.com product, they believe, is better overall.Let's hear your opinions in the comments below.
-
B = f (P, E) : Guiding the user experience
I'm usually not a big fan of pseudo-science when it tries to masquerade as the real thing. So, when I heard about the following formula, I was incredulous.Behavior = f(Person, Environment)
Essentially, what this is saying is that behavior is a function of both people and the environment they work within. Despite the formulaic approach, I appreciate the intent and "succinctness" it brings.
People.
People have instrinsic and extrinsic motivations. These may be supported by your product. The challenge is to marry their goals with your own. Human nature is hard to change; in many ways, you have little or no control over this factor.Environment.
Environment is your site and the actions it provides. Think of it as the rails on which your users ride. You have control over this through the features you expose and what you allow people to do. These need to match up with the peoples' motivations.Behavior.
Behavior is the net result of your work. It's what you want people to do on the site. You can only indirectly address this, through the environment.To use an example, Flickr's environment is one of photo publishing and sharing. The behavior they want to elicit is photo sharing. They guide the behavior by building out an array of things you can do with your images. You can group them by tag, by collection, by set. You can send them to a group, search by location, explore by "interestingness." Flickr demotes the importance of messaging friends, fiddling with your profile and other actions not focused on photo sharing. By directly focusing on a limited set behaviors and supporting only those with robust features, they keep the purpose of the site from becoming dilute.
Takeaway
The takeaway is that encouraging users to behave in a certain way requires acknowledging motivations and selectively building out features to suport. This is common sense to most of us, but sometimes we lose sight of this. Think about this the next time you feel like your site needs to be social, needs a blog, should use Twitter, or whatever the latest techno-fad is. -
Let Your Users Bail: four usability testing ideas
At SXSW 09 , I listened to a panel* of UX game designers talk about the unique challenges around building games. Much of their discussion, however, applied to usability testing in other software. Four big takeaways that I heard:Let testers bail
Usability tests--especially structured task tests--often put the participant in an artificial situation. While the task may be representative, the user may spend more time on the task than normal. In fact they might keep banging away at the task even if, in reality, they would have bailed a long time ago. At the onset of a usability test, give the participant a "stop word" so that they can clue you in to where they would have abandoned your site.
Let go of the formality.
Some clients are forever looking for formalized tests. These include a "magic" number of users, tested during a specific set of time, and using very structured and repeatable tasks. While there are merits to this approach, it's important to recognize that conducting tests is not the end game. Making the product better is.
So grab your neighbor, your friends and family, and evaluate the design without a whole lot of hullabaloo. Its better to get some data often than a lot late. Remember that, despite usability testing having roots in science--it is most often not scientific. That's a good thing because it gives you more flexibility in test execution.
Test in person
There are definite kinesthetic and verbal reactions that users have to products, which can't be observed remotely. Erica Firment noted one that she sees often is the "eye flash," or the point at which the user's eyes widen in enjoyment. Jason Schklar noted hearing the repeated smack of the joystick against a controller as evidence that the gamers were playing in a way less subtle than expected.
Go into the wild
Usability is as much about analyzing reactions to your products in the wild. So, set up Google Alerts, Twitter searches, etc. to automatically scan and report on problem phrases you anticipate your users saying. This can help you get a leg up on those people who aren't submitting trouble tickets, but are being vocal about problems your product has.
All Articles