Showing posts with label prototyping. Show all posts
Showing posts with label prototyping. Show all posts

Monday, January 13, 2014

UIEtips: Announcing our Favorite Articles of 2013

via UIE Brain Sparks http://www.uie.com/brainsparks/2013/12/19/uietips-announcing-our-favorite-articles-of-2013/

December 19th, 2013
Over the past year we published more than 35 articles. Here are 6 of our favorites in no particular order:

What Makes an Experience Seem Innovative?

There are so many better things we could be doing with our time than standing in line. But if we step out of the line, we lose our opportunity to get the service we want. Who would’ve thought you could innovate around something as simple as waiting in line?
Here’s an excerpt from the article:
Since customers think standing and waiting is a necessary evil without alternatives, they may not complain about it. Organizations that focus on the specific activities to resolve their perceived customer objective, may overlook the deep frustration from tool time that’s happening in the gaps between those activities.
Teams that study the entire experience look into those gaps to see from where the deep frustration emerges. Addressing that frustration, when no other product or service has done so, will look innovative to the customer.

Feedback Illuminates the Rules

In this article, Dan Saffer discusses how a good microinteraction immediately shares a result with a user. It lets them know the next steps to take or if they’re going in the right direction.
Here’s an excerpt from the article:
Let’s take a microinteraction appliance like a dishwasher as an example. The dishwasher process goes something like this: a user selects a setting, turns the dishwasher on, the dishwasher washes the dishes and stops. If someone opens the dishwasher midprocess, it complains. Now, if the dishwasher has a screen, each of these actions could be accompanied by a message on the screen (“Washing Dishes. 20 minutes until complete.”). If there is no screen, there might be only LEDs and sounds to convey these messages. One option might be that an LED blinks while the dishwasher is running, and a chime sounds when the washing cycle is completed.

Extraordinarily Radical Redesign Strategies

In this article, Jared Spool discusses how it is common for companies to completely change their website design all at once versus gradually. But it often causes havoc for the user. There’s a strong case for making your redesign practically unnoticeable and slowly releasing small aspects of it.
Here’s an excerpt from the article:
It’s your most loyal customers who will hate your flip-the-switch redesign the most. Designers are quick to declare, “Users hate change.” But that’s not it at all.
Your loyal users have invested a lot over the years mastering your current design, to the point where they are fast and efficient with everything they need to do. When you change it, even with something you want to label “new and improved,” all of that investment is flushed down the drain.

Meetings: The Canary in the Culture Coal Mine

We all know that a company’s culture is a key factor to its success. Culture isn’t something you can whip up or easily change, but its presences will define what is and is not possible to accomplish. In this article, Kevin Hoffman talks about understanding the effects of an organization’s culture on its processes and outcome.
Here’s an excerpt from the article:
The culture of a group or a project team is like water to fish: it is invisible yet everywhere, and it defines what is and is not possible to accomplish. Understanding or changing any aspect of a culture requires immense focused effort and luck.

A Typical UX Team of One Job Description

In this article, Leah Buley discusses the various ways one can spot a UX team-of-one situation. Few UX jobs are advertised as a team-of-one gig, but there are usually telltale signs that give them away.
Here’s an excerpt from the article:
To get a sense of what your colleagues do and don’t know about user experience, take them out to lunch and have a casual conversation. Consider a “Bathroom UX” campaign to promote a broader understanding of the roles and functions of user experience. Employers expect UX practitioners to be able to back up their recommendations and show their work. Employers also might expect the user experience practitioner to challenge and persuade others in the organization to adopt new approaches. UX teams of one sometimes have to be diplomatic, informed, and well-meaning meddlers.

Five Prevalent Pitfalls when Prototyping

There are five common traps teams fall into with their prototyping efforts. Using prototypes is key when designing, but are you falling into some of the frequent traps with your prototyping efforts? Learn about 5 typical traps and how to prevent them.
Here’s an excerpt from the article:
A great prototype can sell an idea better than a specification or other form of describing the design. Seeing the design in action and playing with it brings the underlying ideas to life.
It’s no wonder that we focus so much on what the prototype will look like and how it will work. We want to achieve that wow factor with the key decision makers and stakeholders on the project.
As important as the working prototype is, it’s not the most important outcome of a prototyping effort. What’s more important is what the team learns from the prototyping process.

UIEtips: Explore These 7 Great Podcasts from 2013

via UIE Brain Sparks http://www.uie.com/brainsparks/2013/12/23/uietips-explore-these-7-great-podcasts-from-2013/

December 23rd, 2013
This past year we featured some fantastic podcasts from a variety of UX luminaries. It was difficult to cull the list but we managed to do just that. Here for your listening pleasure are our favorite podcasts from 2013.

Designing Microinteractions

Dan Saffer photoDo you think about the ringer on your phone and the ability to turn it off? Dan Saffer uses this example to kick off his book Microinteractions. Silencing the ringer on your phone is a common feature. If that feature is clunky or hard to find, it interferes with needing to silence it quickly, in a crowded movie theater for example. These tiny interactions that surround the main functionality are integral to rounding out the entire experience.

Lean UX: Escaping Product Requirement Hell

Jeff Gothelf photoAssumptions tend to be the downfall of many research projects. Jeff Gothelf suggests starting with an attitude that you’re testing a hypothesis which leads to a more open discussion. The main thing is, hypotheses, just like design, can change. Being flexible and iterative in your design process encourages an environment of collaboration.

When Responsive Design Meets the Real World

Jason Grigsby photoResponsive web design allows the notion of “one web” to be a reality. Designers are increasingly able to sell to their organization the idea of delivering content to multiple platforms. Putting it into practice is another story. Jason Grigsby, co-founder of Cloud Four, says that it is easier to sell the idea of responsive web design than to do it well.

Prototyping for Mobile Designs

Kelly Goto photoBuilding a prototype is a great way to test your design early on with users. Whether you choose to go for a high-fidelity representation, or go lo-fi with paper, you can learn a lot about the usability of your site. Often, teams are concerned with which technique or tool to use because of the litany that are available. Kelly Goto, founder of Gotomedia, suggests that the importance of the tool lies more with when you use it than why.

Using Scenarios to Design Intuitive Experiences

Kim Goodwin photoScenarios can represent the ideal picture of a user’s experience with a product or service because you can see how and when they’ll interact. However, a scenario is often missing the details of what’s going on at this moment in time and that can be a sticking point. This is where the value of the journey map emerges. Kim Goodwin has years of experience teaching teams how to create and work with personas and scenarios.

Adapting Your Content for Mobile

Karen McGrane photoContent touches all aspects of a design. Having presentation independent content allows for it to adapt to different screens and devices. Karen McGrane suggests that having the specifics of how the content will be structured in place first, allows for the freedom and flexibility to make the right design choices. Karen says that thinking about content first, over how it will appear, helps ensure you’re communicating the right message.

Accessibility as a Design Tool

Derek Featherstone photoAccessibility is important, but somewhere along the way it got an undeserved reputation for being ugly, costly, and driven only by technical-compliance requirements. Making it an integral part of your design early creates something that is beautiful, inexpensive, and user experience-driven. Derek Featherstone of Simply Accessible believes that implementing accessibility into your designs will flat out make for better design.

Friday, November 1, 2013

UIEtips: Five Prevalent Pitfalls when Prototyping

Nathan Curtis, one of the geniuses at the design firm EightShapes, likes to say “Don’t tell me, Show me.” When talking about a design, Nathan wants to see (and possibly play with) a prototype to better understand what’s being proposed.
Nathan’s not the only one. Prototypes are a fabulous way to explore ideas with a team. They shorten the time between “This is what we’re thinking...” and “Oh, I get it.”
In our work with design teams, we see a lot of teams using prototypes today. We’re also seeing many of those same teams fall into traps that reduce the effectiveness of their prototyping efforts. Here’s five of the most common ones we see.

Pitfall #1: Focus on the Deliverable, not on the Learning

A great prototype can sell an idea better than a specification or other form of describing the design. Seeing the design in action and playing with it brings the underlying ideas to life.
It’s no wonder that we focus so much on what the prototype will look like and how it will work. We want to achieve that wow factor with the key decision makers and stakeholders on the project.
As important as the working prototype is, it’s not the most important outcome of a prototyping effort. What’s more imporant is what the team learns from the prototyping process.
You can learn a lot in a variety of different areas when building out a prototype:
Learning about the problem
  • What do we now know about what we’re trying to design for?
  • How did building the prototype change our perceptions of how to solve the problem?
  • What parts of the problem are easily solved?
  • What parts of the problem remain big challenges?
Learning about our users
  • What new things do we now understand about our users?
  • What new questions do we have about them?
  • What will be easy for users to do with our design?
  • What might still be messy for them to accomplish?
Learning about the materials
  • What will be easy to implement?
  • What will be a challenge to pull off well?
  • What new skills do we have to master to get the best design?
Learning about potential solutions
  • What design alternatives are there?
  • Which of those alternatives provide the best outcomes?
  • Why do the less appealing outcomes fail the design?
  • What elements might be useful design patterns going forward?
We love seeing teams present both the prototypes and what they learned. Some teams create an open diary of the prototype project, talking about what they’ve learned as they’ve learned it. By pushing the focus on what they are learning, they make everyone around them smarter about what they’re trying to accomplish with the final design.

Pitfall #2: Too Much Converging; Not Enough Diverging

It’s tempting to fall in love at first sight with an idea that’s a huge improvement over anything you’ve done before. We see teams do this all the time. Once they’re in love, they declare “That’s the one!” and start perfecting and refining the idea.
Selecting and idea and refining it is the convergence part of the prototyping process. Skilled teams know to hold off on that, staying in the divergence part of the prototyping process much longer.
When diverging, the team doesn’t settle on a single design idea. Instead, they ask how else they could solve problem, trying as many ideas as they can. What if we did it this way? What if we used this other approach? These questions help bring up alternatives that might not have been considered before.
By spending more time diverging, the team learns more about the problem space and the potential solutions. When they compare one approach to another, they learn the dimensions and quality of what could make a good design. Asking which alternative is better brings out discussion about the nuance of the problem and the potential solutions that wouldn’t happen if they didn’t have the comparison point.
Of course, trying out lots of alternatives means having prototyping tools and techniques that are fast and flexible, which is where our next pitfall comes in.

Pitfall #3: Working in the Wrong Fidelity

Prototypes come in all shapes and sizes, from whiteboard or napkin sketches all the way up to can’t-tell-if-it’s-real uber realistic running software. You can use a pen and paper, a simple drawing tool like Omnigraffle (though Omnigraffle is always much harder for me than I think it should be), or design-in-the-browser jQuery, CSS, and HTML.
It’s tempting to jump quickly to something that will look like the final design. This would have the right looking icons and typography. It would have highly-stylized layouts and sophisticated color palettes. (Who doesn’t want sophisticated color palettes?)
A great designer, however, chooses the right fidelity for where they’re at with the design. Lower fidelity, like a pen-and-paper sketch, produces a different kind of reaction and critique than higher fidelity, like a jQuery rendition. (This is why tools like Balsamiq try hard to fake a lower fidelity.)
Low fidelity prototypes are faster and easier to create. They are perfect for the divergence part of the project. Sketching out 20 variations and posting them side-by-side on the wall gives the team a nice perspective on what the possibilities are. “Oooh. What if we combined this thing here with that thing there?”
High fidelity prototypes are slower to create, but yield more subtlety and nuance. They give off the feel and are easier to compare to the details of the scenarios. “What happens when our user runs into that special circumstance? How does the design handle that case?”
Choosing the right fidelity for the project’s current needs is essential to the success of the project and the value of the prototype.

Pitfall #4: Too Little Evaluating

You can break a prototype iteration into four distinct stages:
Planning — What do we want to learn from this round of prototypes? How will we tell if we’re getting closer to a final design?
Implementing — Building the prototype or prototypes.
Measuring — Collecting data, such as opinions or usage information, to tell us how well the prototype performed.
Learning — Look back at the iteration and discover what we now know that we didn’t know before, and what questions we now want to answer in the next iteration.
Those last two stages — measuring and learning — are how we evaluate the prototype we’ve built. Many teams create prototypes without ever evaluating them, or even thinking that they should.
When you skip the evaluation stages, you can’t tell what you’ve learned from the prototype effort. Evaluation doesn’t have to be difficult. It can be a simple critique, asking, “does this do what we were trying to do?” Or it can consist of a scenario walkthrough or a simple usability test.
The best teams know how they’ll evaluate the prototype before they build it. This helps them pick the right fidelity for the iteration, getting them quickly to the best results.

Pitfall #5: Fixating On A Single Prototyping Tool

Some prototyping tools, like Axure or iRise, have a lot of promise. However, they also take time to master. Even becoming proficient at sketching or using jQuery takes time and effort.
Because of the effort, some teams want to find one tool and use it for everything. Their thinking, they tell us, is that they need to recoup that learning investment, so they plan to use it for everything.
However, the best teams don’t limit themselves to just one prototyping tool. They’re constantly sharpening their skills on different tools. (Pro trip: hold regular “prototypathons” where small teams compete with tools they’re uncomfortable with.) They look at every type of fidelity, so they’re prepared to meet any challenge.
Proficiency in any tool comes with practice. Spreading out that proficiency with a bunch of tools delivers flexibility. It all comes down to rehearsing and variation.

Getting the Most from Prototyping

Prototyping, on the surface, looks like making something that works. But that’s a narrow view.
Prototyping is rendering ideas to understand them better. It’s a way for the team to dive deep into the process of design and their understanding of the problem to solve. It’s an effective way to show progress throughout the project cycle, not only by having something substantive to display, but by creating a vehicle to talk about the decisions the team is working through.
Avoiding these common pitfalls helps teams get more from their prototyping process. In turn, that produces better designs.

Want to learn more?

While you consider the prototypes your team creates, and how to avoid these pitfalls, you’ll want to be sure you have the right fidelity for the research you’re conducting. Next week, Carolyn Snyder returns to the virtual seminar program to present Prototypes: Choosing the “Right” Fidelity for Your Research. Carolyn will show you which project variables to consider when choosing what to test in the first place, and then how to create an effective prototype that minimizes work and maximizes learning. Learn more about Carolyn’s seminar here.

jared spoolAbout the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems.

via UIE Brain Sparks http://www.uie.com/brainsparks/2013/10/30/uietips-pitfalls_prototyping/

Wednesday, September 11, 2013

Walt Disney: The World’s First UX Designer

I'm a huge fan of the Walt Disney park experience, and my family has traveled to Walt Disney World and Disneyland multiple times. The service we’ve received has always been exceptional, and I return from every visit with at least one extra-special memory.
The reason the Disney experience is so consistently good is a focus on quality, detail, and the customer. For the Walt Disney Company, that focus came from the man whose name is above the door.
Walt Disney was an innovator, a creative force, and a brilliant businessman. But even more than that, I consider Walt Disney the first user experience designer, for reasons I will explain.

It’s Always Been About the Experience

The key to the Disney Park experience is immersion: everything is designed down to the exact detail. Cast members are trained on how to treat customers with very specific instructions on how to do even the minutest actions, like waving and smiling.
Where there was once orange groves and swampland, there are now virtual worlds that guests can explore. A manufactured wonderland created with one goal in mind: to entertain and bring joy to visitors.
I first realized that Disney was a user experience pioneer as I was watched a video of him introducing “The Florida Project” to the world—a project that became Walt Disney World. At one point, Disney described the plan for the Experimental Prototype Community of Tomorrow (or EPCOT) as “an experimental prototypethat is always in the state of becoming, a place where the latest technology can be used to improve the lives of people.” If that isn’t what UX is in a nutshell, I don’t know what is.
He said this in 1966.

Design like Walt

In building out the Disney theme parks, Walt Disney and his deign team (which he named Imagineers) established many best practices that we user experience designers can follow as well. Here are some of them:
Make special moments: Disney and his team had a sharp focus on creating a unique experience that guests could not get anywhere else. This focus on making as many special moments as possible resulted in happy (and repeat) customers. Human beings retain bad memories more than good, so providing happy moments results in people revisiting in a desire to relive or recapture those special moments.
Always be plussing: Disney was never completely satisfied. He always asked for more, always pushed his team to bring more to the table. He called this "plussing," incrementally improving details and elements of an experience. It wasn't "adding more stuff"—which so many companies do—it was making a good experience better; making sure the sound effects on the Pirates of the Caribbean ride were loud enough to rattle the riders; making sure that the Tiki Birds were able to have dozens of different gestures, not just ten. It was aspirational, and I think it’s the right way to approach design. Imagine if all designers and developers did their work with this type of attitude.
Give customers options: Walt didn't design one different locale with the original Disneyland: he made four of them, each with a different theme and different experiences. By doing so he was able to appeal to more people, and also allow for people to either stay in one "land" (such as Adventureland) for an entire visit, or use the "hub" to quickly jump from there to Tommorowland, or another area.
Image courtesy Frank Horst
You can see this idea reflected in countless different UIs today (different views, different ways ofsearching, different options for advanced users, etc.). It may seem obvious today, but Disney came up with the idea and did it first.
Fix things that don't work: The grand opening of Disneyland was, in many respects, a disaster. They ran out of food, rides broke down, counterfeit tickets were being used to get into the park, and the asphalt sidewalks had not finished curing in many places. Though I'm pretty sure there was some yelling involved, Disney met with his team, did a postmortem, and fixed things. We need to follow that example, be self-conscious and objective about our designs, and fix what isn’t working.
Take risks: As briefly noted above, Disney sunk a tremendous amount of his own money in two projects: a full-length animated film called Snow White and the Seven Dwarfs, and Disneyland. Both projects brought him to the brink of losing it all, and both projects were huge successes. We need to take risks with what we design, and “aim for the fence” just like Disney did, because great risk also brings great reward.
Hire smart people: Disney surrounded himself with incredibly talented people and let them do their thing. Though he had to approve almost all the details, he knew that he needed top-notch people to execute his vision and to bring new perspectives to the table. Follow Disney’s lead when it comes to building your team.
Direction like this convinces me that Disney was the world's first UX designer.tweet this

Innovate: Disney innovated both filmmaking and resort experiences, creating the multi-plane camera for film and a complex series of animatronic robots for his parks. He could have gone the safe route and not pushed the envelope, but he did, and we all benefited. Where can you innovate in your design work? What new ideas or interactions can you bring to the table?
Use data to make things better (and maximize profits): Disney looked at traffic patterns and sales data from his parks to change things. Sold out of ice cream in Frontierland last week? Double the number of ice cream stands there this week. Too many people in line for Splash Mountain? Redesign the queue to make sure that the people have extra shade and fans. Disney was one of the first people to look at analytical data to influence business decisions. Like Walt, UX professionals should leverage analytical data to inform their understanding of users and supplement qualitative user research.
Test, refine, then test again: Disney sent friends and family on rides like Jungle Cruise before they opened to elicit feedback and fine-tune the experience. It's exactly what we do as user experience professionals, and he did it 50 years ago.

Mickey’s 10 Commandments

Imagineering President Marty Sklar formally documented some of Disney’s advice and direction for his team, naming them “Mickey’s 10 Commandments.” Like the best practices detailed above, Disney applied these principles every day, and they are applicable to much of what we do in UX:
1. Know your audience: "Don't bore people, talk down to them, or lose them by assuming that they know what you know." This is absolutely necessary in UX design—without a deep understanding of your users you can't create a solution that solves their problems or adds value to their lives.
2. Wear your guest's shoes: "Insist that designers, staff, and your board members experience your facility as visitors as often as possible." This approach increases the empathy your design team has for your users, making the designs you create more appropriate and helpful.
3. Organize the flow of people and ideas: "Use good storytelling techniques; tell good stories not lectures; lay out your exhibit with a clear logic." Storytelling is a vitally important skill in UX, not just when explaining your final design solution to stakeholders, but also in your designs themselves—especially if you’re trying to describe an offering to new customers.
4. Create a weenie: "Lead visitors from one area to another by creating visual magnets and giving visitors rewards for making the journey." Imagineers called these magnets “weenies”–objects that are large enough to see from a distance and interesting enough to draw their attention. Very good advice, and when designing a "stepped" process providing a 'weenie' to follow will result in lower abandon rates and increased customer satisfaction.
5. Communicate with visual literacy: "Make good use of all the non-verbal ways of communication—color, shape, form, texture." We are currently having a big debate in the UX design community about skeumorphism (the use of real-world visual metaphors in a user experience) and this commandment aligns with the argument advocating such an approach. Skeumorphism done well helps people learn new experiences because of the visual cues that remind them of real-world metaphors reflected in the design. Of course, skeumorphism done badly is ... well, pretty awful and unhelpful.
6. Avoid overload: "Resist the temptation to tell too much, to have too many objects; don't force people to swallow more than they can digest, try to stimulate and provide guidance to those who want more." Cognitive overload is one of the major issues that can occur when a UI is "overdesigned" with too many options. This commandment is great advice to avoid that type of situation.
7. Tell one story at a time: "If you have a lot of information, divide it into distinct, logical, organized stories; people can absorb and retain information more clearly if the path to the next concept is clear and logical." This is information architecture 101, and direction like this convinces me that Disney was the world's first user experience designer.
Ad by College of Creative Studies:
8. Avoid contradiction: "Clear institutional identity helps give you the competitive edge. [The] public needs to know who you are and what differentiates you from other institutions they may have seen." Disney thought about branding before most people even knew what the term meant. When designing, don’t look at brand as a separate thing to be applied at the end—it’s a crucial part of the total experience.
9. For every ounce of treatment, provide a ton of fun: "How do you woo people from all other temptations? Give people plenty of opportunity to enjoy themselves by emphasizing ways that let people participate in the experience and by making your environment rich and appealing to all senses." The concepts of gamification and immersive experiences are direct descendants of ideas like this.
10. Keep it up: "Never underestimate the importance of cleanliness and routine maintenance, people expect to get a good show every time, people will comment more on broken and dirty stuff." This is less applicable to UX design, but an absolute golden rule when it comes to process and service design. Always do your best, follow your process and deliver quality.

Keep Moving Forward

As noted above, Walt Disney famously said that he wanted his parks to never be finished—that he wanted it to evolve and grow over time. He said the key is to always keep moving forward, to make the good better, to continue to improve things, and to strive to make things better.
This isn't just a great philosophy for user experience professionals to develop, it reminds us all to keep moving forward.
via UX Magazine http://uxmag.com/articles/walt-disney-the-worlds-first-ux-designer