| |
|
|
|
|
Boxes and Arrows As we discussed in “part one”:http://www.boxesandarrows.com/view/building-the-ux, the skills in research, information architecture, interaction design, graphic design and writing define the recognized areas of User Experience design. However, there still remains much to discuss about what makes a UX team dreamy. Each UX Dreamteam has a finely tuned mix of skills and qualities, as varied as the environments in which they operate. Part two will address whether a person has the right ‘hard’ skills and ‘soft’ qualities like communication style, creativity and leadership ability to fit your particular organizational context. We’ll also touch on the quality of an individual’s personality that may or may not complement the others on your team. Personality Perhaps the most important consideration in forming your Dreamteam is mixing the personalities of your superstars. As mom used to say “It’s not just about how you look, it’s what’s inside that counts.” A candidate may look ideal on paper, but until you have them in front of you, talking and interacting, you won’t know if what is inside will be a fit. Your group spends almost as much time together as apart, they need to respect and like one another to work well together. Personality typing tests hold the promise of quantifying the immeasurable, but you would be ill advised to use them as part of the interview process. Myers Briggs, DISC and plenty of others use various axes to measure the intrinsic tendencies of a person. As cool as it sounds, the science is just not exact enough to act as the basis of any decision. This is not to say that these tests are not illuminating in their own right – they certainly foster greater understanding and empathy among teams. Generally speaking, though, people under pressure may answer personality tests as they think they should rather than honestly. Collaboration is a big part of design best practice and the ability to work well with teammates should be of paramount concern. Selflessness indicates that a candidate is a team player as they seek to raise not only their own reputation, but equally those with whom they work. Humility, humor and empathy are virtues particularly relevant to the creative industry and should be sought after in UX professionals. Each player on the Dreamteam accepts when they’re mistaken, keeps each other creatively entertained and feels for the users they serve. As much as any skill or quality we have already discussed and will explore in this article, finding the right personality type you need is the classic answer: ‘it depends’. It depends on the personalities of existing Dreamteamsters, the type of work they do, and on the organization into which they must fit. There is no magic formula, but there is one thing to always avoid: toxicity. Morale and productivity can be totally undermined by a “toxic person”:http://bipolar.about.com/od/support/a/070315_toxic.htm. Having one aboard can turn your Dreamteam into a nightmare. So, do your homework to avoid inadvertently hiring them. Screening Tips:Look for signs of toxicity by asking about previous work places and their interactions with teammates. Did they voluntarily leave the last job? Do they mainly talk badly about their last workplace? Remember, a toxic person is often manipulative and they may seem great on the surface, so check references. If you misjudge a new hire and you realize you have a toxic person aboard, waste no time in jettisoning them, no matter how skilled they may seem.
Most jobs in the UX Dreamteam involve a level of creativity and analysis, but it’s a rare gem who is a rock-star operator in both these modes. But visionaries and analysts are equally necessary, ensuring great ideas and the ability to organize and actualize them. A creative person doesn’t see a glass half empty or half full, but instead asks why it should be a glass at all. An ability to think laterally, meaning" to escape from a local optimum in order to move towards a more global optimum" (“Edward de Bono”:http://www.edwdebono.com/debono/lateral.htm) – is the talent from which innovation is born. A Dreamteam accesses their creativity readily and regularly to push beyond the obvious for an appropriately innovative solution. Ensure a proportion of creative genius in your Dreamteam to increase business success and thereby the team’s reputation. Your analytical superstars can process vast amounts of information and distill it into a concise and cohesive experience for the user. They are methodical, account for every detail, and question inconsistencies. They grow solutions by breaking a system into its component parts, then creatively reassemble it in logical order. Good analysts are passionate and detail-oriented when identifying patterns in data and behavior. Screening Tips:Given how ideas are often difficult to credit to the interviewee, gauge creativity from the dialogue and candor during the interview. A truly imaginative person effortlessly surprises you with a fresh, off-beat approach to old problems. Responses to tangential or seemingly random questions can help illuminate this quality. If they can link the absurd back to realistic solutions coherently and with humor, you can be sure there’s creativity within. Analytical people are interested in details. Does your candidate flinch at the idea of auditing the content of large information system? If they have they done data analysis before, did they jump into it enthusiastically? How did it go?
Managerial qualities are confused with experience in most professions, and UX is no different. Experience correlates with peer respect, but respect is not all a manager must command. Peter Merholz talks of managers needing to be either "T" shaped "Bar" shaped, referring to the profile of skills they possess. "T"-shaped people have a broad and shallow knowledge of most skills and go deep in only a few. "Bar"-shaped people do not plunge the depths of any expertise. As “he says”:http://www.peterme.com/?p=580, they are all about the connections between disciplines, and being able to articulate the power of that integration. An "I" shape would indicate deep knowledge in just one or two areas. This profile suggests an awesome specialist practitioner (yes, there is an "I" in Dreamteam!).Good bosses are quietly also coaches, therapists, facilitators, communicators, organizers and politicians. As leaders, they are comfortable in setting an agenda for others to fulfill while inspiring the Dreamteam to meet or beat that agenda. Your luminary leader provides ‘air cover’, also known as ‘running interference’. Making space for their reports to work by fending off interfering people or tasks, the manager ensures the Dreamteam is focused, not randomized. People who find less satisfaction in helping others to be effective are better placed as well-compensated senior practitioners. To presume that someone senior should be promoted into a management position is misguided. A manager’s UX skills are less important than their ability to co-ordinate a group of individuals and spot what your organization needs from them. Screening Tips:When seeking managerial talent, look for someone who will revel in the Dreamteam’s success, rather than their own. How have they "run interference" in the past? New managers sourced from within a team show a tendency to get the best out of others prior to their promotion. This is known as "acting up" and makes a good task to set potential managers to test their aptitude. If you’re looking for a practitioner, be sure they’re not fixated on being a manager, lest their ambitions undermine the effectiveness of your designated leader.
We all know guys who stand idly by, watching others do their work and wryly commenting, "You look after the details, I’m the big picture man.” Those who strategize with ‘blue sky’ ideas can raise the ire of people slaving at everyday tasks. Tactical skills are just as valuable as strategic. Each serves their purpose in envisioning and getting things done. Conceiving an entire system and determining what both the business and users get out of it are the domains of big picture people. It is hard to imagine success without their vision to work toward. These people can be creative or analytical but find implementation a chore. They are typically well informed of industry trends and can forecast the future through them. While vision is an awesome asset, without attentive "small picture" work, it’s an apparition. Strategists think one to five years ahead and beyond and are good at depicting a vision. Tactical people focus on day-to-day activity and on success in the one to six month timeframe. With the exception of think tanks, the organizational balance needs to skew toward small picture people in order to achieve success. Many startups and UX teams fail because of the inverse balance. Screening Tips:To find the detail-oriented, look for evidence of finishing products and a personal satisfaction in seeing all loose ends tied up. A strategic thinker will show evidence of helping others to see the wider context of what they’re doing, often through conceptual and architectural diagrams. Can they show you some? Also ask questions which illuminate how they’re plugged into where your organization’s industry and the wider UX field is headed.
In-house teams (aka "Innies") have needs different to external agencies that provide interface building/designing services or consultancy. An in-house team is working toward increasing profitability through UX. In many cases, the nature of projects does not change over time because there’s only one type of business to support. Exceptions exist, but in general those building in-house teams should discount candidates who need variety to thrive. The in-house Dreamteam is also better suited to agile development methodologies, which rely heavily on face-to-face contact. Unless a consultant is able to work on-site for the duration of the agile project, they will not be able to fulfill some of the tenets surrounding ‘less documentation, more talking’. Aside from communicating an absent author’s intentions, documentation is a mechanism used by agencies to cover their backside if a client claims poor diligence and won’t be abandoned willingly. Agencies don’t make much money from staff who aren’t comfortable playing the consultant role. Working under pressure, answering expertly on all subjects related and sometimes unrelated to the job requires a certain type of communication style and self-confidence. Agency staff (aka “outies”) must be broad-skilled and part salespeople to make their expertise and company’s value obvious to clients. This isn’t to say that these qualities aren’t good to have on the in-house UX Dreamteam, but they’re less critical to business success and can be compensated for in other ways. Screening Tips:Stack your in-house team with stars who are tactical, for their willingness to roll up their sleeves, dig-in and get enjoyment from attacking a long-term goal is what you need. Strategic thinking is also attractive, but you may want to emphasize this in your management function where vision is expected. Beware hiring those with purely "innie" experience for "outie" roles and vice versa. Outies may find innie work mundane and innies can struggle in the faster-paced, higher-pressure outie workplace. Outies need to have political and sales savvy to navigate varied organizations and present value. Confidence, plausibility and magnetism will be obvious – you’ll want to hire them before they’ve shown you their ample skills. Though be sure they have those too!
Hiring managers generally consider organizational context subconsciously when preparing their Dreamteam, usually feeling out the candidate with gut instinct rather than concrete comparisons. It helps to abstract the organization into something you can test applicants for compatibility with, like a “persona”;:http://en.wikipedia.org/wiki/Persona for instance, then you can envision a compatible teammate for that persona. Size, work processes, project types, employees, industry and brand among other things influence the organization’s personality. Some organizations are process-driven and others are more free-form. Process ensures that work complies with a to-do list prescribing smooth running and/or best practice. The less experienced use process like new bicycle riders use training wheels. Some people flourish within a controlled environment. Others feel hampered or oppressed by it. What are the processes used within your organization? What unique characteristics do individuals who operate within them need to be happy and successful? A Dreamteam’s number will impact the duties each superstar performs. Small organizations can have tasks similar in number to their larger counterparts, but spread them among fewer people. This inevitably means one fulfilling multiple roles. The graphic designer might double as the interface-layer coder. The Information Architect may also be the researcher and writer. If you are in a small organization, a ‘gun’ specialist with all their UX skills primarily in only one area may not be a good fit. Every workplace has a pace. Agile development or simply expeditious environments tend to be frenetic and mean working quickly. Some people don’t perform without time to pause, think, rework and perfect their work. Others will be frustrated if it takes a long time to get things done. They won’t always agree that crafting something perfectly, or documenting design thoroughly is time well spent. Sometimes perfection is expected, but timescales remain fixed. In this case, experience and coping well with stress is consequential. Screening Tips:What kind of personality does your office have? Who would get along best with that person? Prepare to win the best fit by making a list of organizational attributes and qualities that will complement these. Agile methodologies should be coupled with experienced folk who are natural communicators; as should organizations without process to guide activities. A quiet consensus builder might suit a contentious office, etc. Use the example below to get you started – be creative and modify the attributes as you see fit. Company Persona and Match Here’s an example of how you might break down how a potential new team member might fit in with your organization: Where do we go from here? Hiring UX staff is rarely easy, but now you can take a structured approach to identifying the skills and personal qualities your team needs within your organizational context. Like any craft, building the UX Dreamteam takes practice and the occasional mistake leads to growth as a hiring manager. Even when you think you’ve mastered it, there is still an element of luck to contend. You may be willing to compromise skills and qualities for someone who just feels right and your instincts shouldn’t be discounted. Allow them to inform your choices while thinking about the areas we’ve touched on to build the UX Dreamteam that will make your organization shine. Calling in the Big Guns by Will Evans 10 Jul 2008 at 10:00am
Before you can toss up a quick Hail Mary, marketing says that the opt-in for marketing solicitations has to be defaulted to yes, and you can feel your soul sucked out of your body through your nose as a simple one hour meeting turns into a 3 hour discussion over the pro’s and cons of inline validation while your stomach grumbles because you just missed lunch. I have heard this war story many times from many interaction designers and information architects, with little variation except in the details. What we need is air cover in this battle to design better forms. Now, it’s here. “Forms Suck!” And so Luke Wroblewski begins his new book on web form design with a canon shot, providing just the air cover and ammunition interaction designers need; and every review, including this one, begins with a first impression. Mine was: Boffo. (bof·fo (bf) slang, adj.: Extremely successful; great.) Wroblewski opens “Web Form Design” with a strategic exploration of why users interact with forms. News flash: It’s not because they enjoy it. Interaction designers need to confront the truth that a user’s goal is to get to some successful outcome on the other side of a form ? as quickly and painlessly as possible. We want our iPhone, tax return, or account with Facebook. We don’t want to fill out forms. bq. Forms suck. If you don’t believe me, try to find people who like filling them in. You may turn up an accountant who gets a rush when wrapping up a client’s tax return or perhaps a desk clerk who loves to tidy up office payroll. But for most of us, forms are just an annoyance. What we want to do is to vote, apply for a job, buy a book online, join a group, or get a rebate back from a recent purchase. Forms just stand in our way. Wroblewski has researched everything from the basics of good form design, to labels and most-direct route, delivering his explanations, patterns and recommendations with a casual urgency that avoids preaching. This book is a useful guide for both the novice interaction designer and the battle tested UX guru, offering salient, field tested examples of the good, bad, and often times ugly forms that have proliferated the web like so many mushrooms after a good rain. Wroblewski has also invited many seasoned professionals to contribute sidebars, including Caroline Jarrett’s no-nonsense perspective on designing great forms by advising us to “start thinking about people and relationships,” instead of just diving into labeling our forms and choosing where to put the Submit button. I especially appreciated her strategic guidelines for picking what questions should go into a form in the first place, which she aptly titles “Keep, Cut, Postpone, or Explain.” Wroblewski is aware of how challenging most readers will find good form design. It comes as a relief, for instance, when he writes that we should think less about forms as a means of filling a database, and more as a means of creating a meaningful conversation between the user and the company. He generally succeeds at adopting the warm tone of a confidant who can win you over with self-deprecating, you-too-can-make-dynamic-forms-every-day enthusiasm. The more subtle points of user-centered design or goal-driven design are not discussed explicitly; only the trained ear will detect them. Section one: “Form Structure” begins with an overview of why form design matters and describes the principles behind good form design, followed by Form Organization, Path to Completion, and Labels (hint: your form design should start from goals). Working quickly through strategy to tactics, Wroblewski gives numerous examples – within the context of usability studies – so that you are not left wondering whether these patterns are recommended based just on his opinion. Section two: “Form Elements,” is a useful, clearly written exploration of each of the components of form design: labels, fields, actions and messages (help, errors, success). Wroblewski attacks each one of these by defining particular problem spaces, and then shows good and bad solutions to the problems while highlighting how these solutions faired in controlled usability tests, including eye-tracking. He then finishes each chapter off with a succinct list of ‘Best Practices’ that I suggest are good enough to staple to the inside of your eyelids. Section three” “Form Interaction,” includes chapters on everything from Inline Validation to Selection-dependent Inputs (a barn burner). Here we move from the world of designing labels, alignment, and content to designing the actual complex interactions between the system—that wants to be fed like the plant in Little Shop of Horrors ?- and the world-weary user that just wants to get to the other side of the rainbow. As Wroblewski explains in his opening of chapter 9 “Inline Validation:” Despite our best efforts to format questions clearly and provide meaningful affordances for our inputs, some of our questions will always have more than one possible answer?Inline validation can provide several types of feedback: confirmation that an appropriate answer was given, suggestions for valid answers, and real-time updates designed to help people stay within necessary limits. These bits of feedback usually happen when people begin, continue, or stop entering answers within input fields. To establish communication between the user and the form, provide clear, easy-to-read feedback so that the user doesn’t get the “select a username or die” travesty that we see in registration forms all over the web. You know the ones: you type in your name, choose a username, enter your email address, and your password (twice), hit the submit button?and?bad things happen. The username is already taken. Worse, the form is cleared and you have to enter all that information all over again. Wroblewski provides advice for validation (without set-in-stone rules), and a bulleted list of best practices. The final, and perhaps most interesting chapter in the book, covers the topic of Gradual Engagement. This is particularly timely given the kudzu-like proliferation of Web 2.0 applications and services as well as social networking sites and micro-blogging sites. Instead of starting your engagement with a new company that all your friends are raving about with yet another registration form ? as Wroblewski writes: bq. “We can do better. In fact, I believe we can get people engaged with digital services in a way that tells them how they work and why they should care enough to use them.1 I also believe we can do this without explicitly making them fill out a sign-up form as a first step.” He continues by highlighting the benefits of moving a user through the application or service ? actually engaging with it, and seeing it’s benefits, while registration is either postponed, or handled behind the scenes. He explores web applications like JumpCut, where the user steps through the process of creating, uploading and editing their video—and only when they actually want to publish and share it, does the user encounter a form—at which point they have already learned the service, it’s benefits, and it’s value. This is certainly a more engaging experience than being confronted with a form and a captcha before ever realizing the value of the web application. He ends this compelling chapter by providing some advise and best practices : bq. When you’re exploring if gradual engagement might be right for your Web service, it’s important to consider how a series of interactions can explain how potential customers can use your service and why they should care. Gradual engagement isn’t well served by simply distributing each of your sign-up form input fields onto separate Web pages. Wroblewski showed three excellent examples of web applications that seem to very successfully utilize this new strategy for engaging new users while avoiding or at least postponing the ubiquitous registration process. This is certainly welcome news. The key is to rethink how new users become engaged with your company. Does the conversation start with a form? Gradually introducing new customers to your service and it’s benefits ? letting them actually use it and learn it first seems like a better way to start the conversation. I wish this chapter had more to it, as it covers an exciting exploration of web application design innovation. Wroblewski wrote a very compelling article in “UXmatters”:http://www.uxmatters.com/ back in 2006 titled, “The Complexity of Simplicity”:http://www.uxmatters.com/MT/archives/000151.php, which was a predecessor to this chapter of the book. After an extensive search online, this was about the only source I could find other than some blog posts referencing that article. One article on “ReadWriteWeb”:http://www.readwriteweb.com/, “Good UI Design: Make It Easy, Show Me You Care”:http://www.readwriteweb.com/archives/good_ui_design_make_it_easy_show_me_you_care.php,”” did include two more examples ? “FuseCal”:http://www.readwriteweb.com/archives/finally_sync_any_calendar_to_any_calendar.php, a calendar syncing online application, and “Twiddla”:http://www.twiddla.com/, an online whiteboarding service. Another spot that could have used improvement were in the last chapter. Perhaps this was either my reading of it or the way it was presented. _What’s Next_, certainly made me feel that he would be exploring his vision of the future of form design, and forms in general—which he certainly does in the section on the disappearing form, and proceeds into a very brief discussion of game-like elicitation methods (GEMS). These are welcome additions, I wish that he had gone a bit deeper into this chapter, especially about GEMS. It’s a fascinating discussion point, and we will see more examples in the coming year. I also wanted more resources and references to studies that a form designer, information architect or interaction designer could use to bolster their design decisions. Many good designers out there know how to design good forms. The hard part is the politics and the negotiation process with stakeholders—and numbers always help. I am reminded of a conversation I had over lunch about a month ago here in D.C. The UX professional was giving a short presentation on form design to an in-house crowd and was trying to subtly indicate the value that often times less is more in form design. He wanted to show to stakeholders that the concept that adding one, two, or four more form fields in a registration process has a cost, even if the design and development cost is minimal. I suggested that a simple info graphic that showed how, as the number of form fields increased, user signups decreased. His immediate reaction was that some stakeholders would immediately want to see metrics to back up the assertion. I am unaware of any numbers about fall-off rates, but from my professional experience tells me less is better than confronting a first-time potential user with a long form to complete. Perhaps it would be sufficient to include a “Further Reading” section divided up into sections like Academic Research, Field Studies, and Conference Papers. The book may not the best place to put something like this—I wonder if the online companion to this book has such a thing. Either way, it would be a valuable addition. You can get Web Form Design from “Rosenfeld Media”:http://rosenfeldmedia.com/books/webforms/ or “Amazon.com”:http://www.amazon.com/Web-Form-Design-Filling-Blanks/dp/B0018S232Q/boxesandarrows-20. Just keep in mind that, for the same price, Rosenfeld Media tosses in a nicely formatted digital version which you can use to quote from when you have to sell a good form design to a team that wants to bicker over form labels. Don’t forget the discount for Boxes and Arrows readers: Get a 10% discount by purchasing the book “directly from Rosenfeld Media”:http://rosenfeldmedia.com/books/webforms/. Just use the code WFDBA. Web Form Design: Filling in the Blanks On A Scale of 1 to 5 by Alex Kirtland, Aaron Schiff 18 Jun 2008 at 8:27pm Where would we be without rating and reputation systems these days? Take them away, and we wouldn’t know who to trust on eBay, what movies to pick on Netflix, or what books to buy on Amazon. Reputation systems (essentially a rating system for people) also help guide us through the labyrinth of individuals who make up our social web. Is he or she worthwhile to spend my time on? For pity’s sake, please don’t check out our reputation points before deciding whether to read this article. Rating and reputation systems have become standard tools in our design toolbox. But sometimes they are not well-understood. A recent post at the IxDA forum showed confusion about how and when to use rating systems. Much of the conversation was about whether to use stars or some other iconography. These can be important questions, but they miss the central point of ratings systems: to manage risk. So, when we think about rating and reputation systems, the first question to ask is not, “Am I using stars, bananas, or chili peppers?” but, “what risk is being managed?” What Is Risk? We desire certainty in our transactions. It’s just our nature. We want to know that the person we’re dealing with on eBay won’t cheat us. Or that Blues Brothers 2000 is a bad movie (1 star on Netflix). So risk, most simply (and broadly), arises when a transaction has a number of possible outcomes, some of which are undesirable, but the precise outcome cannot be determined in advance. Where Does Risk Come From? There are two main sources of risk that are important for rating and reputation systems: asymmetric information and uncertainty. Asymmetric information arises when one party to a transaction can not completely determine in advance the characteristics of the other party, and this information cannot credibly be communicated. The main question here is: can I, the buyer, trust you, the seller, to honestly complete the transaction we’re going to engage in? That means: will you take my money and run? Did you describe what you’re selling accurately? And so on. This unequal distribution of information between buyers and sellers is a characteristic of most transactions, even in transactions where fraud is not a concern. Online transactions make asymmetric information problems worse. No longer can we look the seller in the eye and make a judgment about their honesty. Nor can we physically inspect what we’re buying and get a feel of its quality. We need other ways to manage our risk generated by asymmetric information. The other source of risk is not knowing beforehand whether we’ll like the thing we’re buying. Here honesty and quality are not the issue, but rather our own personal tastes and the nature of the thing we’re buying. Movies, books, and wine are examples of experience goods, which we need to experience before we know their true value. For example, we’re partial to red wine from Italy, but that doesn’t mean we’ll like every bottle of Italian red wine we buy. Managing Risk with Design Among the ways to manage risk, two methods will be of interest to user experience designers: Signaling is where participants in a transaction communicate something meaningful about themselves. Reducing information costs involves reducing the time and effort it takes participants in a transaction to get meaningful information (such as: is this a good price? is this a quality good?). Reputation systems tend to enable signaling and are best utilized in evaluating people’s historical actions. In contrast, rating systems are a way of leveraging user feedback to reduce information costs and are best utilized in evaluating standard products or services. It is important to note that reputation systems are not the only way to signal (branding and media coverage are other means, among others), and rating systems are not the only means of reducing information costs (better search engines and product reviews also help, for example). But these two tools are becoming increasingly important, as they provide quick reference points that capture useful data. As we review various aspects of rating and reputation systems, the key questions to keep in mind are: Who is doing the rating? What, exactly, is being rated? If people are being rated, what behaviors are we trying to encourage or discourage? Who is doing the Rating? A random poll of several friends shows about half use the Amazon rating system when buying books and the other half ignore it. Why do they ignore it? Because they don’t know whether the people doing the rating are crackpots or if they have similar tastes to them. Amazon has tried to counteract some of these issues by using features such as “Real Name” and “helpfulness” ratings of the ratings themselves (see Figure 1). Figure 1: Amazon uses real names and helpfulness to communicate honesty of the review. This is good, but requires time to read and evaluate the ratings and reviews. It also doesn’t answer the question, how much is this person like me? Better is Netflix’s system (Figure 2), which is explicit about finding people like you, be they acknowledged friends or matched by algorithm. Figure 2: Netflix lets you know what people like you thought of a movie. Both these systems implicitly recognize that validation of the rating system itself is important. Ideally users should understand three things about the other people who are doing the rating: Are they honest and authentic? Are they like you in a way that is meaningful? Are they qualified to adequately rate the good or service in question? The last point is important. While less meaningful for rating systems of some experience goods (we’re all movie experts, after all), it is more important for things we understand less well. For example, while we might be able to say whether a doctor is friendly or not, we may be less able to fairly evaluate a doctor’s medical skills. What is being rated? Many rating systems are binary (thumbs up, thumbs down), or scaled (5 stars, 5 chili peppers, etc.), but this uni-dimensionality is inappropriate for complicated services or products which may have many characteristics. For example, Figure 3 depicts a rating system from the HP Activity Center and shows how not to do a rating system. Users select a project that interests them (e.g., how to make an Ireland Forever poster) and then complete it using materials they can purchase from HP (e.g., paper). A rating system is included, presumably to help you decide which project you should undertake in your valuable time. Figure 3: The rating system on the HP Activity Center site: what not to do. A moment’s reflection raises the following question: what is being rated? The final outcome of the project? The clarity of the instructions? How fun this project is? We honestly don’t know. Someone thoughtlessly included this rating system. Good rating systems also don’t inappropriately “flatten” the information that they collect into a single number. Products and services can have many characteristics, and not being clear on what characteristics are being rated, or inappropriately lumping all aspects into a single rating, is misleading and makes the rating meaningless. RateMDs, a physician rating site, uses a smiley face to tell us about how good the doctor is (Figure 4). Figure 4: RateMDs.com rating system for doctors. Simple? Yes. Appropriate? Perhaps not. Better is Vitals, a physician rating site that includes information about doctors’ years of experience, any disciplinary actions they might have, their education, and a patient rating system (Figure 5). Figure 5: The multi-dimensional rating system on Vitals.com. While Vitals has an overall rating, more important are the components of the system. Each variable – ease of appointment, promptness, etc. – reflects a point of concern that helps to evaluate physicians. When rating experiences, what is being rated is relatively clear. Did you enjoy the experience of consuming this good or not? Rating physical goods and products can be more complicated. An ad hoc analysis of Amazon’s rating system (Figure 6) should help explain. Figure 6: Amazon’s rating system is not always consistent. In this example the most helpful favorable and unfavorable reviews are highlighted. However, each review is addressing different variables. The favorable review talks about how easy it is to set up this router, while the unfavorable review talks about the lack of new features. These reviews are presented as comparable, but they are not. These raters were thinking about different characteristics of the router. The point here is that rating systems need to be appropriate for the goods or services that are being rated. A rating system for books cannot easily be applied to a rating system for routers, since the products are so entirely different in how we experience them. What aspects we rate need to be carefully selected, and based on the characteristics of the product or service being rated. What behaviors are we trying to encourage? Any rating of people is essentially a reputation system. Despite some people’s sensitivity to being rated, reputation systems are extremely valuable. Buyers need to know whom they can trust. Sellers need to be able to communicate – or signal based on their past actions – that they are trustworthy. This is particularly true online, where it’s common to do business with someone you don’t know. But designing a good reputation system is hard. eBay’s reputation system has had some problems, such as the practice of “defensive rating” (rate me well and I’ll rate you well; rate me bad and I’ll rate you worse). This defeats the purpose of a rating system, since it undermines the honesty of the people doing the rating, and eBay has had to address this flaw in their system. What started out as an open system now needs to permit anonymous ratings in order to save the reputation (as it were) of the reputation system. While designing a good reputation system is hard, it’s not impossible. There are five key things to keep in mind when designing a reputation system: 1. List the behaviors you want to encourage and those that you want to discourage It’s obvious what eBay wants to encourage (see Figure 7). A look at a detailed ratings page shows they want sellers to describe products accurately, communicate well (and often), ship in a reasonable time, and not charge unreasonably for shipping. (Not incidentally, you could also view these dimensions as source of risk in a transaction.) Figure 7: eBay encourages good behavior.
2. Be transparent Once you know the behaviors you want to encourage, you then need to be transparent about it. Your users need to know how they are being rated and on what basis. Often a reputation is distilled into a single number—say, reputation points—but it is impossible to look at a number and derive the formula that produced it. While Wikinvest (Figure 8) doesn’t show a formula (which would be ideal), they do indicate what actions you took to receive your point total. Figure 8: Wikinvest’s reputation system Any clarity that is added to a reputation system will make your users happy, and it will make them more likely to behave in the manner you desire. 3. Keep your reputation system flexible Any scoring system is open to abuse, and chances are that any reputation system you design will be abused in imaginative ways that you can’t predict. Therefore it’s important to keep your system flexible. If people begin behaving in ways that enhance their reputation but don’t enhance the community, the reputation system needs to be adjusted. Changing the weighting of certain behaviors is one way to adjust your system. Adding ratings (or points) for new behaviors is another. The difficulty here will be in keeping everything fair. People don’t like a shifting playing field, so tweaks are better than wholesale changes. And changes should also be communicated clearly. 4. Avoid negative reputations When possible, reputation systems should also be non-negative towards the individual. While negative reputations are important to protect people, negative reputations should not always be emphasized. This is specifically true in community sites where users generate much of the content, and not much is at stake (except perhaps your prestige). Looking at our example above (Figure 8), Wikinvest uses the term “Analyst” (a nice, non-offensive term … if you’re not in investment banking), to mean, “this person isn’t really contributing much.” 5. Reflect reality Systems sometimes fail on community sites when people belong to multiple communities and their complete reputations are not contained within any one of them. While there are exceptions, allowing reputations earned elsewhere to be imported can be a smart way to bring your system in line with reality and increase the value of information that it provides. Conclusion Our discussion of rating systems and reputation systems is certainly incomplete. We do hope that we’ve given a good description of risk in online transactions, and how understanding this can help user experience designers better manage risk via the design of more robust rating and reputation systems. In addition, we’d like to begin a repository of rating and reputation systems. If you find any that you’d like to share, feel free to submit them at http://101ratings.com/submit.php. In addition, you can also email any ideas or submissions to systems@usablemarkets.com. MindCanvas Review by Sarah A. Rice 18 Jun 2008 at 8:26pm MindCanvas describes itself as a remote research tool that uses Game-like Elicitation Methods (GEMs) to gather insights about customer’s thoughts and feelings. It was developed by Uzanto Consulting, a web product strategy firm. When I first learned about MindCanvas, I understood it to be an online card sorting tool. Happily, it’s much more than that. As a veteran IA consultant, I have used MindCanvas a handful of times during the course of different projects. I have also conducted card sorting exercises without the tool. I am thrilled to have a useful?and user-friendly?tool at my disposal. One of my main reasons for selecting MindCanvas was the reputation of one of its creators, Rashmi Sinha. She is well known and respected, and I felt assured that any tool designed by a fellow IA for IAs couldn’t be all that bad. I was right. MindCanvas provides open and closed card sorting capabilities, as well as a host of other UT tools: Divide-the-Dollar, Clicky, Sticky, Concept Test, and FreeList. Clicky and Sticky allow users to react to a wireframe or prototype by answering questions about images and content, or applying stickies (Post-it?like notes) with attributes to a visual image. FreeList and Divide-the-Dollar allow you to elicit product ideas and prioritize them by having participants list and rank the features they find most useful. All of these methods offer easy-to-use interfaces to help your research participants along. Deciding which MindCanvas method to use is one of the more complicated parts of the tool. It’s card sorting methods are good for validating a site’s navigation or information hierarchy. You can also explore user needs and values and gather feedback on brand and positioning by using some of its more specialized UT methods. MindCanvas’ website and supporting help wiki provide information on selecting the appropriate testing method for your website or product. Using MindCanvasThe basic process for using MindCanvas is as follows: After payment, sign an agreement to obtain a login and password. Decide which method (i.e. Sticky, FreeList, etc.) addresses your research needs. Create potential research questions and tasks based on the MindCanvas method you have selected. (I’ve used OpenSortand TreeSort). Upload questions to MindCanvas’ Workbench. Test the research study and make changes until you are satisfied with it. Send out the test site URL to your participants. Monitor the study (i.e. see how many people have completed all the tasks). When the study is concluded, send a report request to the MindCanvas team. Receive the reports in visual form and download raw data from the MindCanvas site. Embed reports into PowerPoint or Word document and review results with client. I usually take several days to review the reports before showing them to my consulting clients. Doing so allows me to more easily explain the results. (Here’s a pointer to anyone using MindCanvas: To view the results properly make sure PowerPoint is in “Slideshow” mode). StrengthsMindCanvas has a couple shining strengths I’d like to illuminate: An engaging, easy-to-use interface for your customers or end users. It’s fairly self-explanatory and makes routine UT tasks fun. Stellar data visualization tools once your study is completed. User Interface MindCanvas’ interface is what sets it apart from other UT software I’ve seen. Its creators took their inspiration from the world of digital gaming to develop an interface that’s engaging for the person using it, while gathering important data for researchers. Its card sorting methods employ a floating hand to deal cards, which are then sorted by users. Another method gives users virtual gold coins to vote for their favorite product features. These exercises are enhanced by accompanying sound effects. I’ve received numerous comments from users describing MindCanvas’ exercises as “fun”. They have also commented that while they don’t understand how these exercises will help me build a better website or software interface, they still enjoyed the tasks and were pleased at the conclusion of the test. The other online research tools I’ve reviewed offer more awkward interfaces. Sorting exercises take multiple steps or the online tasks are not intuitive and confuse research participants. I’m not interested in making my users become experts at online card sorting or other UT methods. I simply want to extract what they know or understand about a particular website or service. According to Jess McMullin of nForm User Experience Consulting, “MindCanvas is unmatched as a remote research tool in its ability to provide creative methods for gathering data [and] engaging participants…..” Data VisualizationAnother MindCanvas strength is its data output. Although you can obtain the raw data and analyze it yourself (assuming you have statistical software and know how to use it), the real benefit of MindCanvas is its easy-to-understand data visualizations, which showcase the results of your study. All my clients have received clear, easy-to-interpret answers to their research questions. The visualizations can be embedded into a PowerPoint slide or Word document, making them easily accessible. Your clients don’t have to rely on your interpretation of the data; they can interpret the data themselves if they choose. Every client who has viewed MindCanvas’ data visualizations has been impressed and wondered why it wasn’t used all along. Weaknesses I’ve used MindCanvas a handful of times and encountered some weaknesses: Study Size: If you have a large client with complex, statistically rigorous research needs, MindCanvas is not for you. It has a limit of 200 users per study. Two hundred is plenty for most of my research needs, but some of my clients want to go beyond that. Data Sorting: If you have complex user segmentation needs, MindCanvas has its limitations. It allows you to perform a single data sort to identify user sub-groups. For example, it’s easy to segment all male vs. female participants or all participants who are 21- to 50-years-old. If you need to segment 16- to 20-year-old females or men who only shop online (or any two parameters of your choice), you’ll need a different tool. There are ways around these limitations: You can create two separate research studies to deal with different users, or you can build more complex research questions to solicit the answers you need in order to sort the data required. However, these solutions have limitations of their own, so there is a trade-off. Pricing Structure: The current pricing structure is $499 per study, with each accompanying report $99. This is adequate for quick-and-dirty research to resolve obvious user issues, but the pricing structure doesn’t scale well. For example, if you run a single study and want multiple reports for different audience segments, each $99 report adds up quickly. It can be difficult to budget up front before the research study is even developed, leaving the door open for cost increases. If a simple card sorting tool is all that you need, check out WebSort, which costs $499 for three months of unlimited use and automatically generates a dendogram. (Please note that MindCanvas offers much more than card sorting). Data Analysis Bottleneck: Some of the back-end data analysis is done by a human, who works on a schedule. All data reports are generated once a week. If you get your report order request to Uzanto by the Tuesday deadline, results will be available by Thursday. This might not work with your tight project schedule, in which case, you’re out of luck. MindCanvas’s Workbench MindCanvas is currently offered in self-service mode. This means that you (or your researcher) need to become familiar with the finer points of MindCanvas’ Workbench for constructing studies. The upside is that some parts are made easy, like being able to “copy” another study in order to create your own (a handy feature), or creating as many preliminary studies as you like before distributing the real thing. Figure 1: Manage Activity The downside is that some interface elements in the study creation console are a bit mysterious. For example, under Manage Study, it’s unclear if the data has been downloaded 164 times or if there are 164 participants who have completed the study. The difference between Manage Study and Track Activity is also hazy. Manage Study allows you to specify where to send users after they have completed the study and limit the number of participants or the length of the study, while Track Activity informs you how many people have completed the study. The Download Tracking CSV gives you access to a text file with a list of all participant’s URL information and their start and stop times. Figure 2: Track Activity The Workbench allows access to MindCanvas’ powerful study creation module, but you can tell most of the design effort went into the end user’s interface, not the study designer’s. Luckily, there is a wiki available which answers a lot of questions and Uzanto consultants are very friendly and helpful with the occasional question. ConclusionThe IA community can finally say that we have a tool designed for us. For so long, we’ve had to take existing tools and try to use them in ways not intended by their designers, sometime with frustrating results and having to develop clever and complicated workarounds. These issues are no longer a problem. It’s a tool for us, made by one of us. It’s about time! Quick and Easy Flash Prototypes by Alexa Andrzejewski 1 Jun 2008 at 10:35am To tackle the classic “how to prototype rich interactions” problem, I developed a process for translating static screen designs (from wireframes to visual comps) into interactive experiences using Flash. Requiring some fairly basic ActionScript knowledge, these prototypes proved to be a quick yet powerful way to bring interaction designs to life. When asked if I could find a quick and easy way to prototype a web application my project team had wireframed in Visio, I first turned to PDF prototyping. Using a PDF of the wireframes as the base, I overlaid clickable elements and some interactive data entry fields. Everything was wonderful—until the client asked us to add color to the wireframes. The Visio document was updated, a new PDF had to be made… and all that interactivity had to be reapplied. (It is tedious and time-consuming to replace page content in a PDF.) Not wanting to repeat this tedious process again and again, I turned to Flash. I was excited to find that Flash not only felt more streamlined and intuitive when creating basic click-throughs, but it also offered almost limitless potential for prototyping rich interactions. With some basic ActionScript (a scripting language used in Flash to define interactions) knowledge and a bit of resourcefulness, I was able to create functional combo box navigations, type-ahead mechanisms, and eventually a complex, drag-and-drop scheduling application similar to Google Calendar. And whenever the screen designs changed, all I had to do was import the new background images, while the interactivity layers stayed happily in place, requiring only minimal tweaking. Quick and easy yet powerful and flexible The idea of working with Flash may seem daunting, but the effort required to create a basic click-through is comparable to that required by other applications, while the flexibility and potential for extending the prototype is far greater. (After all, Flash was designed for creating interactive applications, not presentations [like PowerPoint], diagrams [like Visio] or portable documents [like Acrobat].) Considering the additional benefits it offers, Flash prototyping is well-worth adding to your interaction design toolkit: Flash prototyping allows you to add interactivity to screen designs and wireframes you’ve already created. You don’t have to recreate the layouts in another application. Flash allows screen images to be updated without losing your interactive layers, which is much more difficult in PDF prototyping, as I described above. Flash includes a robust library of customizable user interface components that can be dropped into your prototype and used as they are to add realism (e.g., a text field you can actually type in) or programmed using ActionScript to serve as fully-functional interface controls. You can export prototypes as stand-alone applications (suitable for running from a thumb-drive at an on-site usability test where the Flash plugin may be blocked) or as HTML pages with embedded Flash (in which the browser can be used to scroll up and down through tall prototypes). You don’t have to hire a professional Flash developer to achieve all of this. (I’m certainly not a Flash expert.) You can create simple, yet believable, prototypes with very little knowledge of ActionScript. All it takes is resourcefulness, creativity, and experimentation. A valuable tool and impressive deliverable Flash prototypes can be both a valuable tool for project teams and an impressive deliverable for clients. At the consultancy where I first employed Flash prototyping, these prototypes quickly became an invaluable part of the design, testing and buy-in process for many projects, and clients loved them. Here’s why: By experiencing the interactions we were proposing, we were able to quickly sense when something that seemed good on paper didn’t feel right in reality. By testing realistic prototypes, which users perceived to fully-functional, we were able to collect accurate user feedback about how novel interactions (such as a type-ahead search) felt and functioned in a real context. By providing clients with functional demos, we were able to see our concepts move towards reality as clients enthusiastically used them to rally organizational support for concepts. Having learned a lot through trial and error in creating these prototypes, I’d now like to share the process I developed through a step-by-step tutorial. How to use this tutorial In this tutorial, you’ll be creating a practice prototype using static screen images from Facebook that I’ve annotated using Visio. You should be able to complete it in 1 hour or less. To see what you’ll be creating, you can try out the final prototype files: Download Flash Prototype for Mac (Andrzejewski_Prototype_Mac.app) Download Flash Prototype for Windows (Andrzejewski_Prototype_Windows.exe) You’ll also want to download the files needed to complete this tutorial: Download Source Files (Andrzejewski_SourceFiles.zip) If you don’t have Flash CS3 or higher, you can download a 30-day, fully-functional trial from: https://www.adobe.com/cfusion/tdrc/index.cfm?product=flash The major steps of this tutorial are in bold. If you have some Flash experience, you may be able to complete the tutorial using the bold steps and the annotations on the screens. For those who are new to Flash, I’ve provided detailed sub-steps and definitions. Table of Tutorial Steps 1. Create a new prototype template 2. Import images 3. Label layers 4. Create new layer 5. Create reusable button 6. Create layer for interactive elements 7. Create basic click-through 8. Add a conditional button 9. Create an invisible button 10. Test your prototype 11-17. Export your prototype Preparing screen designs for prototyping To prepare for Flash prototyping, you’ll need to have images showing each possible screen and state in the scenarios you want to demonstrate. Often, you’ll have already created many of these screen designs in the wireframing phase of your project. The fidelity of these images may range from wireframes to visual design comps, depending on your prototyping needs. It doesn’t matter what software you use to create your images (e.g., Visio, Illustrator, Photoshop, etc.), as long as you can export them as raster images (e.g., GIF, PNG, JPG). While images have already been prepared for you in this tutorial, here are some helpful tips for creating and exporting screen designs for use in Flash: Creating the screens Create neat layouts using grids and guides to keep items aligned from page to page to prevent inappropriate jumpiness (if only part of a page is supposed to be changing, such as when a menu appears, and the entire page shifts a little, it will detract from the prototype’s realism). Test page-to-page alignment by viewing images full-screen. Ensure that images are all the exact same size by using a common background image or canvas size for all screens. In Visio and other page layout applications, you must be sure to remove or hide anything that protrudes outside of this background before exporting. Placing annotations that don’t belong in the prototype and anything else that will exist outside of the content area (page titles, footers) on a separate layer allows them to hidden before exporting the images. Planning interactivity Add a unique identifier to each screen or page that, unlike the page numbering (if you’re using a page layout program), will not change. You’ll be saving each screen as a file named after this identifier (e.g., “W05.png”). Using these identifiers, if your page ordering changes or you add or delete pages, you’ll still know which page corresponds with which exported image later. Mark up the screens with callouts explaining everything that should be interactive and what should happen when elements are interacted with. For a basic click-through, most of these callouts will point to an element and read, “Go to X” (where X is the target page identifier). Make sure these callouts don’t extend outside of the image area. These callouts will make the Flash work much easier, and the callout version of the prototype makes a useful “practice prototype” that can help future users learn how to navigate the prototype. You’ll re-export the images and create a version of the prototype without callouts later. Saving or exporting images Save or export each screen as an image that will fit on a screen without scaling (preferably a lossless file such as GIF or PNG) using the page identifier as the filename. If you’re using vector-based software (like Visio), make sure the resolution of the exported files is set so that the resulting images will fit on the screen without scaling or scrolling. If your screen dimensions are 1024×768 points, for example, and you want the resulting images to be 1024×768 pixels, you would need to set the export resolution to 72×72 pixels/in. Welcome to Flash Note: If you don’t see some of these panels, use the Window menu to locate and turn them on. You’ll be introduced to each of these elements and to key principles of ActionScript as you work through this tutorial. In the Appendices at the end of this document, you’ll find a handy reference guide and summary of everything you’ll have learned about Flash and ActionScript. Setting up the Flash document The images needed to complete this tutorial from scratch can be found in the SourceImagesAnnotated folder of this zip file: Download Source Files (Andrzejewski_SourceFiles.zip) While setting up the Flash document may feel tedious, what’s exciting about Flash prototyping is that after you’ve set up a document once, you can save your work as a template for future prototypes so that you don’t have to start from scratch. All you’d have to do to start a new prototype is import a new set of images with the same filenames and add or remove keyframes as needed depending on the number of screens. If you’re already familiar with Flash basics and would like to skip to creating interactions, you can download an already-set-up template and begin working through the tutorial from the “Basic principles of interaction” section. Creating a new prototype template 1. Create a new Flash document that uses ActionScript 2.0 and has a 1024px by 768px stage. 1.1. Open Flash and create a new Flash File (ActionScript 2.0). ActionScript 2.0 vs. ActionScript 3.0 The latest version of ActionScript is ActionScript 3.0, a much more sophisticated but unfortunately a little harder to comprehend rendition of the language. Because AS 2.0 is a little more direct and intuitive (you can add scripts directly to buttons and objects), I recommend starting there. In fact, if you’re only using Flash for simple applications (like most prototypes will be), AS 2.0 is all you really need. If you eventually want to catch up with the AS 3.0 trend, understanding AS 2.0 first can help you make the conceptual leap to AS 3.0. When working in ActionScript 2.0, you’ll want to make sure that tutorials and scripts you find online and in books are compatible. Look for tutorials written for Flash MX 2004, Flash 8, or Flash CS3 using ActionScript 2.0. 1.2. To define the size of the stage, in the Properties Panel, click the button next to "Size" that shows its current dimensions. Change the dimensions to the size, in pixels, of your exported screen designs—1024px by 768px in this tutorial. Press "OK.” The Stage is your visual workspace or canvas. This is where you’ll specify where objects appear. Objects in the grey area outside the stage will not be visible when the exported flash movie is viewed at the correct size. 2. Import the images to keyframes by using Import to Stage and selecting the first file in the sequence. Flash will automatically prompt you to import the rest of the files and place each image on its own keyframe. 2.1. From the File menu, go to File > Import > Import to Stage. Browse to the folder where your images are located and select only the first image in the series—“W01.png.” Click "Import." 2.2. A dialog will appear asking if you want to import all of the images in the sequence. Click “Yes.” All of the images will be imported to your Library and automatically placed on separate keyframes in the timeline. The Timeline is where you define when objects appear or disappear from the stage. The timeline contains frames and keyframes which can be on multiple, independent layers. The layers in Flash work in an identical fashion to layers in Photoshop. Frames are displayed as blocks. They are grey when they contain content and white when they are empty. Keyframes are frames marked with circles or dots. A keyframe is a frame where a change can occur without affecting the previous frames. Changes made on keyframes persist until the next keyframe unless “tweening” is used to fill in the blanks. You can also add commands (ActionScript) to keyframes, which will be executed when the player reaches that frame. 2.3. Note that when you click to select one of the screen images, you’ll notice that the properties of this image are shown in the Properties Panel, including its X and Y position on the stage (measured from the upper-left corner by default). The X and Y positions should both be “0” by default. If you ever move one of the images out of place accidentally, you can use the Properties Panel to place it back in the upper-right corner by re-entering “0,0” as its position. The Properties Panel is context-sensitive—it shows/allows you to set properties for the last frame or instance that you selected. It is shown at the bottom of the Flash interface. 3. Name the current layer, “Wireframes.” Label each keyframe using the image’s identifier. Insert four frames between every keyframe to make these labels visible. 3.1. In the Layers area at the top of the workspace, double-click on the words, "Layer 1" and type "Wireframes." Press Enter to commit the change. 3.2. Click on the first keyframe to highlight it. 3.3. Press F5 four times to insert four frames after this keyframe. 3.4. With the first keyframe still selected, in the Properties Panel, change “” to the image’s identifier, “W01” (remember, ActionScript is case sensitive). Frame Labels can be assigned to keyframes so that they can be referred to using ActionScript. It is generally better to refer to frame labels in ActionScript than to frame numbers because frame numbers are subject to change as you add or remove frames. 3.5. Click on the second keyframe to highlight it. Insert four frames after it and label it “W02.” Repeat for the remaining keyframes, including the final one. This part may seem a little tedious, but you should not have to repeat it again unless you insert additional screens. You’ll be able to update these images without recreating the keyframes and labels in the future. The Properties Panel is where you can assign frame labels to frames and instance names to instances. 4. Create a new layer called, “Frame Actions.” Make sure the Flash movie does not automatically play by adding a “stop();” action to the first frame. 4.1. Right-click or Ctrl+click (Mac) on the first layer’s name and choose “Insert Layer.” 4.2. Rename the new layer, “Frame Actions.” 4.3. Select the first keyframe in this new layer. 4.4. Go to Window > Actions to turn on the Actions Panel. The Actions Panel is context-sensitive—it shows/allows you to add scripts to the last frame or instance that you selected. Look at the tab name near the bottom of the Actions Panel to verify what you are adding actions to. 4.5. With the first keyframe selected, type the following in the Actions Panel: stop(); Notice that a small “a" appears in the middle of the keyframe to indicate that actions will be triggered when that frame plays. ActionScript is case sensitive. Semicolons should be used at the end of every statement (generally every line). Frame Actions are attached to keyframes and are triggered when that frame is reached. Functions are built-in actions that you can call on using keywords. These commands are keywords followed by parentheses in which specific details can be added if necessary. Creating a reusable button 5. Create a button symbol. Make the button invisible—an invisible button is clickable but does not display anything on the stage when the Flash file is compiled: It has a clickable area (a “Hit” state) but no visible states (Up, Over, and Down are all blank). This button should be a rectangle and the size of an average clickable area in your prototype. You’ll be able to resize instances of this button as needed. You will be using this button overlay to simulate most interactions. 5.1. Go to “Insert > New Symbol…” Symbols are objects that can be used and reused. They are similar to Shapes in Visio and Stencils in Omnigraffle. Symbols include imported content, Movie Clips (objects that can have their own, independent timelines), Buttons (special movie clips with four frames in which four possible button states can be created), and Graphics (objects that may contain drawings and/or imported images). 5.2. In the dialog that appears, name it "invisibleButton" and choose the type "Button." 5.3. Notice in the Edit Bar that you are now editing “invisibleButton.” This button’s “timeline” consists of four labeled frames. Each frame represents a unique button state. Typically, you would draw what the button looks like normally in the “Up” frame, you’d draw the rollover state in the “Over” frame, and you’d draw the pressed state in the “Down” frame. “Hit” is an invisible state used to designate the clickable area of a button. Since you want your button to be invisible, you will only be creating the “Hit” state. Right-click or Ctrl+click (Mac) on the frame labeled, “Hit” and choose “Insert Keyframe.” The Edit Bar (Navigation Area) indicates which timeline you are currently viewing. In this tutorial, you will generally be working on the main timeline, labeled “Scene 1” by default, but you will eventually be creating objects that have their own, independent timelines. These objects can be nested inside of each other. When you are inside an object’s timeline, a breadcrumb trail will indicate where you are in the grand scheme of things, e.g., Scene 1 > CarObject > WheelObject. 5.4. Using the Rectangle Tool and Fill Color picker if necessary, draw a solid-colored box on this keyframe. The color does not matter, as it will not be visible. It also doesn’t matter exactly what shape and size it is—you’ll be resizing each instance as needed. Just make it the size of a typical button in your prototype. The Tools Bar contains tools you can use to create and manipulate graphics and objects on the stage. 5.5. In the Edit Bar, click the Back Arrow or "Scene 1" to go back to the main movie. 5.6. Your "invisibleButton" symbol should appear in the Library Panel. Creating a layer for interactive elements 6. Add another layer to your movie, called “Interaction,” for buttons and controls. In this layer, insert one keyframe per screen. 6.1. Right-click or Ctrl+click (Mac) on the “Wireframes” layer’s name and choose “Insert Layer.” 6.2. Rename the new layer, “Interaction.” 6.3. Lock the “Wireframes” layer by clicking in the padlock icon column to prevent accidental changes. 6.4. Right-click or Ctrl+click (MAC) on the frame above the keyframe labeled, “W02” and choose “Insert Keyframe.” Repeat, inserting a keyframe in this layer above every labeled keyframe. Basic principles of interactivity I’ve provided a Flash file in which all the steps to this point have been completed so that you can experiment with the more interesting aspects of Flash prototyping. If you’d like to start the tutorial from this point, open the file called FlashPrototype_Template.fla from this zip file: Download Source Files (Andrzejewski_SourceFiles.zip) Creating a basic click-through 7. Place invisible buttons over all the “go to X” elements in the images (the ones specified using green callouts). Add gotoAndStop(“frameLabel); actions to each button, telling Flash to go to the frame label specified in the annotations when that button is released. 7.1. Click on the first keyframe of the Interaction layer. 7.2. Drag an instance of the invisibleButton onto the stage and drop it over the “Edit” button in the screen design. It should appear to be a transparent, blue area. You can use the Free Transform Tool (which you can find in the Tools bar) to make it cover just the area that should be clickable. Instances are unique occurrences of symbols in your Flash movie. You can drag as many instances of a symbol into your movie as you like. If you update the symbol, all of its instances will be updated as well, however, certain properties (such as scaling and positioning) can be customized on an instance-by-instance basis. Later you’ll learn how to name instances so you can refer to them specifically using ActionScript. 7.3. Next you are going to make the button interactive. When you add an action to an object (vs. to a keyframe, as you did earlier), it must be contained within an “Event Handler” so that Flash knows when to execute the action. With the button selected, type this Event Handler in the Actions Panel: on(release) { } Event Handlers are used to specify behaviors that trigger actions. Actions contained within an event handler’s curly braces will be triggered only when the event preceding them occurs (e.g., when an button is pressed and when it’s released). 7.4. All of the actions that should happen when the button is clicked and then released should go within the two curly braces. You’re going to use the gotoAndStop(“frameLabel”) function to tell the prototype to go to the frame labeled “W02” when the button is clicked and released. on(release) { // When this event occurs… gotoAndStop(“W02”); // these actions should be triggered. } Curly braces can be used to group statements. Comments that don’t affect the code can be added by preceding comment text with two forward slashes. 7.5. To ensure that the main timeline is controlled (vs. the timeline of the button the script is attached to), you can precede gotoAndStop with the name of the timeline you’re targeting. The main timeline is referred to as the “_root” in ActionScript. The final script should read: on(release) { _root.gotoAndStop(“W02”); } Actions are context-sensitive. They act on whichever movie or timeline they are attached to. If actions are placed in the main timeline, they’ll act on the main movie. If they’re placed on a timeline within an object, they’ll only act on that object unless otherwise specified. To target specific timelines and objects, refer explicitly to the main movie as “_root” and other objects by their assigned “Instance Names.” If you’re unsure which object an action applies to, use explicit targets to ensure your actions will work as intended. You’ll learn more about Target Paths later. 7.6. If you go to Control > Test Movie (Ctrl+Enter on PC, Apple+Enter on Mac), you should see that the button symbol is invisible, but that you can still click on it to go to frame “W02.” It gives you the impression that the “Edit” link is working—your pointer should change to a hand cursor, and clicking the link should take you to frame “W02.” 7.7. On keyframes W02 through W04, wherever you see a green, “go to X” callout, add an invisible button with the appropriate script. The easiest way to do this is to copy and paste the button you’ve already created. This creates a new instance of the button while preserving the script you’ve added to it. All you have to do is change the destination frame label. 7.8. Test your prototype (Ctrl+Enter on PC, Apple+Enter on Mac). You should be able to follow the trail of green callouts through the first five frames. That’s all there is to creating a basic click-through using Flash. The prototype at this point should be comparable to what you could create in Visio, PowerPoint or Acrobat. What makes Flash a worthwhile prototyping tool, however, is that it makes it easy to add realism and “smarts” to your prototypes. Flash’s “Components Library” offers a robust collection of customizable user interface components that can be dropped into your prototype and used as they are to add realism (e.g., a text field you can actually type in) or programmed using ActionScript to serve as fully-functional interface controls. Using one of these components and some simple ActionScript, you’ll next learn how to add basic logic to your prototype. Adding a conditional button There are many applications for conditional buttons in prototypes, including demonstrating error handling. 8. Add a CheckBox component named “termsBox” to frame “W05” of the “Interaction” layer. 8.1. Select the keyframe in the “Interaction” layer above the frame labeled “W05.” 8.2. Open the Components library (Window > Components). The Components Panel contains a special library of user interface objects, such as radio buttons and combo boxes, and have customizable properties. These properties can be edited in the Parameters tab of the Properties Panel and/or changed using ActionScript. 8.3. In the “User Interface” folder, you’ll find the CheckBox component. Drag it onto the screen and place it over top of the check box in the image. 8.4. In the Properties tab, give the Instance Name, “termsBox” to this checkbox. An Instance Name can be assigned by selecting an instance and entering a unique name in the Instance Name field in the Properties Panel. Since a symbol in your library can be used in your Flash movie multiple times, each occurrence needs to have a unique name if you want to address it using ActionScript. 8.5. With the check box selected, in the Properties Panel, click the Parameters Tab. Select the “Label” field in the Parameters Tab and delete the label text. The Parameters tab of the Properties Panel is where you can edit the special properties of components. Each property is listed on a separate line. 9. Create an invisible button that determines whether the check box is selected or not and sends the prototype to the appropriate screen. 9.1. Drag an invisible button over the "Upload Picture" button on frame “W05.” 9.2. Select this button, and in the Actions Panel, add an event handler: on(release) { } 9.3. Within this event handler, you’re going to add a conditional statement, an “if Statement,” to check whether “termsBox” is selected. The condition contained within the “if statement” will be tested when the event (on release) occurs. It is constructed as follows: on(release) { if(CONDITION) { // If this condition is met… // perform all actions contained within these curly braces. } else { // Otherwise… // do these actions. } } The If Statement describes a condition that must be met for certain action(s) to be performed. It can optionally be followed by an “else” statement specifies what to do otherwise. 9.4. The condition that you’re checking for is whether the “selected” property of “termsBox” is “true.” To refer to properties of objects, use the object’s target path, followed by the name of the property (for example, _root.termsBox.selected). Target Paths are like web URLs or file paths, only they use dots (.) instead of slashes to indicate hierarchy. Eventually you’ll be using ActionScript to address movies inside of other movies. An easy way to do so is using “absolute paths,” which indicate the location of an object relative to the main movie (the “root”) using objects’ instance names. (For example, to address an object with the instance name “spokes,” you might write: _root.car.wheels.spokes) You can also use “relative paths,” which you can learn more about in Flash’s documentation. Properties of an object are special keywords that Flash recognizes. You can evaluate or change properties of an object using ActionScript. Components, movie clips and other types of objects all have unique properties. You can look up a particular object type’s properties and their possible values in Flash’s documentation. 9.5. To test whether something is equal to something else, you’ll use the “equals” operator, which consists of two equals signs. Your condition will read: on(release) { if(_root.termsBox.selected == true) { } else { } } Operators are used in If Statements to compare one value to another in the format, “if(x OPERATOR y).” The most common operators are: == equals > is greater than < is less than != is not equal to <= is less than or equal to >= is greater than or equal to 9.6. The complete script that will be placed on the button, which includes the actions that should happen when the condition is met or not met, is: on(release) { if(_root.termsBox.selected true) { _root.gotoAndStop("W07"); } else { _root.gotoAndStop("W06"); } } 9.7. Repeat steps 8 and 9 on the next keyframe, “W06,” only name the checkbox “termsBox2” and add this script to the button: on(release) { if(_root.termsBox2.selected == true) { _root.gotoAndStop("W07"); } } 10. Test your prototype (Ctrl+Enter on PC, Apple+Enter on Mac). Try selecting the checkbox and clicking the button. Test it again and see what happens when it is not selected. You should be able to complete the entire first part of the prototype. 10.1. If it doesn’t seem to work, you may want to: 10.2. Make sure your scripts were attached to the button, NOT to the checkbox or to the keyframe. 10.3. Check that your syntax is correct (don’t forget your {,}, and ;). 10.4. Ensure that your buttons point to the correct frame labels. Exporting your prototype If you made it this far, good job! You’ve learned some of the fundamentals of Flash and ActionScript and have created a simple, yet smart prototype. All that’s left is exporting the prototype as a stand-alone file that can be shared with clients and usability testers. To do this: 11. Go to File > Publish Settings. Choose “Windows Projector” or “Macintosh Projector” (or both), enter a file name, and press “Publish” to create a standalone, self-executing file of your prototype. It will be created in whatever folder the Flash file is in. While the annotations make the prototype easy to test and navigate, it wouldn’t be very challenging for test participants! To make a version of the prototype that is not annotated: 12. Remove or hide the annotations in the software you used to create the screens. 13. Export or save each of the screens to a new folder using the same file names that you used before. Flash doesn’t care what folder an image comes from, if it has the same name, it considers it to be the same image. 14. In Flash, use “Save As…” to create a new copy of the prototype. 15. Go to “File > Import > Import to Library” and import all of the final images at once (use Ctrl+A or Apple+A to select all). Since the names of these images match the names of the images you imported previously, Flash will ask you whether you want to replace the existing items. Since this is exactly what you want, select “Replace existing items” and press “OK.” 16. Click through each keyframe to make sure the prototype looks right (the buttons are aligned properly and the screens are updated). 17. You can now publish another copy of the prototype without the annotations by going to “File > Publish Settings” and giving the files new names. Open Andrzejewski_Prototype_Mac.app or Andrzejewski_Prototype_Windows.exe to see the final prototype. You can also open FlashPrototype_Completed.fla from Andrzejewski_SourceFiles.zip to see what the final Flash file should look like. Resourcefulness, creativity, and experimentation Using only the principles learned in this tutorial and a little resourcefulness, creativity, and experimentation, you can create quite robust prototypes. In fact, using just what you’ve already learned, you could conceivably simulate rich interactions ranging from fly-out menus to type-ahead search. Look for a follow-up article that will show you more examples of what’s possible. The wonderful thing about Flash is that Flash prototypes can be as simple or as complex as they need to be. Start building your click-through prototypes in Flash. Once you’ve built a few of those, try a scenario that involves a little logic. When a more complex situation arises (“Could you make this area turn yellow when you drag that icon over it?”), do some research on sites like ActionScript.org to see if you can find an easy way to show it or at least fake it. While you may not be able to take full advantage of Flash’s prototyping potential immediately, the benefits of using Flash, even when creating simple prototypes, make it a worthwhile addition to any interaction designer’s toolkit. Appendix A: The Flash Interface Note: If you don’t see some of these panels, use the Window menu to locate and turn them on. The Stage is your visual workspace or canvas. This is where you’ll specify where objects appear. Objects in the grey area outside the stage will not be visible when the exported flash movie is viewed at the correct size. The Timeline is where you define when objects appear or disappear from the stage. The timeline contains frames and keyframes which can be on multiple, independent layers. Frames are displayed as blocks. They are grey when they contain content and white when they are empty. Keyframes are frames marked with circles or dots. A keyframe is a frame where a change can occur without affecting the previous frames. Changes made on keyframes persist until the next keyframe unless “tweening” is used to fill in the blanks. You can also add commands (ActionScript) to keyframes, which will be executed when the player reaches that frame. Frame Labels can be assigned to keyframes so that they can be referred to using ActionScript. It is generally better to refer to frame labels in ActionScript than to f |