Most clients and projects require the design researchers to state a predetermined sample size of users. Researchers often find it hard to justify to clients and business stakeholders on the choice of their sample size of users. Suggesting a very small sample size may make the client think that the research recommendations might not be impactful enough whereas, a very large sample size inflates the time and budget for the study. One of the many reasons for this conundrum may be that design research is often confused with market research and hence often assessed with the standards of market research. This report by Human Factors International superbly explains how they are different.

Well, theoretically a design research study can involve a minimum of 3 users to around 100+ users. Undoubtedly, the quality of insights drawn from such a range of users might differ nevertheless there is a combination of factors I believe one should consider when ascertaining the number of users. Let’s have a look at these factors in detail.

The Scope of the Design Study

The most important factor to consider is to determine what are we trying to accomplish through the study. The scope of the study can be:

a. To design a product from scratch and doing exploratory design research

When the focus is on discovering needs and opportunities for a product then, we need to maximize the number of users. This is because exploratory studies require to examine the entire spectrum of the target audience who might be existing or potential users of the product and also all possible behaviors, processes and interactions of these users with their operable environment which can lead to the creation of a new experience. Creating new experiences is like a gamble researchers and designers are taking. One can never be 100% assured that it’s going to work. Hence, the more the number of users, the better will be the statistical evidence to support the design hypotheses and ensure that the new experience is indeed a delightful one. However, the limiting factor of budget and time for the study can again constrain and influence the number of users for the study which I have covered later in the article.

b. To find solutions to problems of an already existing product and doing validatory research, eg. usability testing, identifying new features etc.

When we are finding potential solutions to difficulties with current design system then, we can go with a fewer number of participants. When probing for usability problems with an interface, sometimes the magic number of 5 users can do the trick as explained by this NN group article. However, when probing for new feature capabilities or studying the current state of the system then, sometimes one may need more than 5 users. In such cases, the decisions boil down to considering other factors such as characteristics of the study population, resources for the study, etc which I have discussed below..

Characteristics of the Study Population

It is uncommon to have just one kind of users of a product. Moreover, it is quite possible that the user groups may not be predefined and the research may further explore the various user categories in the study population. It is also possible that the target population might comprise users from various countries, cultures and even speaking many languages. Therefore, the more diversified a study population we are examining, the more the number of users will be required to get a comprehensive picture through the study. In other words, we will need multiple user representatives for each persona group or user type we are designing for. I recommend beginning with a minimum of three users to consider for each user type and then increase the number of users uniformly for each category depending on product and domain complexity.

Resources at Disposal

In reality, budget and time always dictate the sample size for research. In addition to conducting a research study, a researcher needs to budget time for recruiting users, analysing the data and further feeding the insights to design sprints. Hence, discerning the right number of users in perspective with time and budget of study is critical to ensuring complete project handling.

Considering the worst case scenario where the project permits very less budget and very less time, I would recommend to scale down the number of participants to get the data on time. This is to make sure that we are able to generate at least the most significant insights.

In cases, where there is ample time but less budget, we can always select research methods which are frugal enough to generate meaningful insights without compromising on the number of users being considered for study eg. methods such as design surveys, diary studies etc.

For the reverse case of less time and a substantial budget, we need to consider differentiating between exploratory and validictory research and further ascertain the number of users. This is because recruiting more users will not be a problem here, however being able to recruit more users in less time will definitely be.

Quantitative vs Qualitative studies

Out of all the factors which impact the number of users in a study, the choice of doing a quantitative study or qualitative study is the one 90% of the times in the hands of the researcher. This is because the purpose of research and the quality and type of insights which are expected from the study are most clear to the researcher. Rest all the factors are conditional and largely statutory to the project requirements. Thus, the researcher has the liberty of determining the number of users to fit its requirements. However, the only constraint to be careful here is findings from quantitative studies need to be statistically sound. Statistically sound quantitative studies set a requirement of a minimum number of users which is usually large (often 30 users or more). Whereas, findings from qualitative studies are behavioral estimates. Thus, the researcher has the freedom to decide the number of users which is further elaborated by this article.

To conclude

Small, medium or large — what sample size of users fits your study is a composite question. The magic number of 5 users may work magic in some studies while in some it may not. It depends on the constraints put on by project requirements, assumptions about problem discoverability and implications to the design process. Assess these factors to determine the number of users for your study:

1. What’s the nature and scope of research — is it exploratory or validatory?
2. Who and what kind of users are you planning to study?
3. What’s the budget and time to finish the study?
4. Does your research involve presenting statistically significant numbers or inferring behavioural estimates for the problem statement?

Happy User Recruiting!

Written by: Shrut Kirti (via Medium)
Posted by: Situated Research

The post User Research: is more the merrier? appeared first on Situated Research.

What matters more: killer UX that makes people want to use your product, or shipping the things people want quickly and staking down a huge share of the market? If the UX is bad, people won’t want to use it. On the other hand, if someone else gets it there first, people are happy to use what is available and help to improve it with feedback as it grows. People have been struggling with these opposing interests long enough that we thought it important to outline a better way to think about the problem, depending on what stage your company is in.

It’s important to remember that this is only a framework and that your actual course of action will be as personal as your business and products. But if you’re simply trying to “wedge in” design excellence while rushing your product to market, then you’re already on the wrong path.

Competing Priorities: Experience vs. Execution

Experience

UX is absolutely critical, there’s no question about that. Q Manning at Code Mag sums up his thoughts on the matter rather well:

“Finding a well-developed app isn’t that difficult. Many low-rated apps are responsive and bug free. So what do these top apps all have in common?… The top-selling apps have a fantastic user experience. The best apps do more than accomplish their goals; they transport users into a preternatural state of clairvoyance, where each tap is intuitive and never requires second guessing.”

That sounds pretty sweet in theory, but UX rarely reaches that state of perfection. We debate this regularly at UXPin while reviewing UI designs, prioritizing features, planning the product roadmap, and so forth for our wireframing and prototyping app. UX involves how people use your product, what they experience when they do, and how they feel about those experiences. It’s such a broad definition that few companies think about it the same way—below, you’ll see one of the many convoluted UX frameworks that are freely available.

Source: Kicker Studio, “The Disciplines of User Experience”

Execution

The opposing interest is called, in the language of the Lean Startup model, the Minimal Viable Product (MVP). Lean product development instructs you to get a working prototype, ship quickly, get feedback, fix it, and do it again.

John Saddington, Partner at startup accelerator The Iron Yard, is a strong advocate of the MVP as a means of getting customer feedback as soon as possible. “Do whatever it takes to get something into someone’s hands. You’ll learn more from in-the-flesh customers than any degree of theorycrafting,” Saddington says. “That’s what an MVP is all about.”

It isn’t possible to comprehend what good UX means in your case until you have dedicated users

The simple fact is that it just isn’t possible to fully comprehend what good UX means in your particular case until you actually have some dedicated users. Get the basics, communicate your core concept and then get some fingers on the buttons. This is where setting user expectations matters most. If you just need some beta testers, don’t promote your MVP as a launch. You actually have more control over user expectations than you think. Many people are willing to try something new and clunky for the coolness factor alone.

Get Conceptual

However you look at it, you need something out there. And there are many ways to conceptualize your initial product. If you need to brush up, take a look into our free ebook, The Guide to Wireframing, and keep tabs on our Product Design Library for new e-books on prototyping and more.

I. Viable Business

Although there are MVP success stories like Dropbox, which used a bare bones approach to go from 0 to $1 billion in valuation over four years, an MVP more oftens lead directly to a Minimum Viable Business (MVB), which builds revenues and traffic more reliably yet slowly. Of course, this makes sense—most things of value in life come to fruition from steady effort over time. In fact, products that grow explosively like rocket ships are so rare that they’re commonly dubbed “unicorns” once they reach a certain level of traction. Regardless of whether your MVB is a rocketeering unicorn or a steady winner, the primary question you should ask yourself over and over again is: can it make money?

Source: Jon Yongfook, “21 Actionable Growth Hacking Tactics”

II. Feasible Product

As discussed in our Guide to MVPs, building an MVB is only part of the story. The next step up is making sure your product can be built with the time, money, resources, and technical capabilities today. It’s critical to be honest with yourself here because a lot of people grossly underestimate or flat out ignore this part. You can’t really move onto the next step without the product being feasible.

III. Desirable Product

Finally, your product has to be desirable, a Minimum Desirable Product (MDP). This concept wasintroduced by Andrew Chen, who defined it as, “the simplest experience necessary to prove out a high-value, satisfying product experience for users, independent of viability.”

Source: Intercom, “Asking Questions Beats Giving Advice”

Aarron Walter, Director of UX at MailChimp and author of Designing for Emotion, echoes a similar sentiment that UX is the key to desirability, even at the MVP stage. “At first, the primary focus is on usability and learnability. But these days, it’s easy to build an app and get it on the market,” says Walter. “What’ll make your app stand out from the crowd? Personality, a point of view, an ethos—features can come later, but personality needs to be there from your very first release.”

The guide below will help you safely navigate the waters of New Product Development, and provide advice on when to focus on UX or lean processes and to what degree at each stage of the process.

The Stages of Product Development

The most salient factor that determines how much to focus on UX or lean design is which stage you are currently in along the development cycle.

One unique aspect of the design process that can be frustrating is that it is path-dependent. Everything is open at the sketching stage, but after that, early decisions put constraints on what is possible later in development. Unless the team is going to scrap everything and start from scratch, which is not always desirable—or even possible—additions have to blend in to the existing design. Reduce your uncertainty early for a more successful project all around.

This implies a strategy of reducing the project scope so that all of your resources can be devoted to solving a problem that is fairly well understood. Design simply, get it right, and move on. You are not shooting for perfection, but a high-functioning product that you can refine and enhance the core of in the next stages of design and development. Laura Klein, VP of Product at Hint Health, warns against losing focus with your MVP. “An MVP is not an excuse for a crappy product,” she says. “MVPs are all about learning, and you don’t learn anything from a crappy product except that people don’t like crappy products.”

With that said, here is a brief breakdown of the three market stages and where your focus needs to be.

I. The technology stage: little UX, all lean

1. Objective: Assembling the plan together as a team and figuring out what the market needs.
2. Key considerations: Focus on MVP, with an emphasis on the Viable. You can’t focus on UX yet because you don’t have any users. You know who could use it, but you don’t know who will. Get a working prototype together and get it out there to find out who needs it and how they are using it in the real world.
3. Success criteria: Consumers outside the beta test group want to use it.

II. Feature stage: limited UX, less lean

1. Objective: Settle on the most important features to develop based on existing and/or prospective user demand.
2. Key considerations: Start molding the UX as part of the decision process to engender specific emotional responses from users. Do you want them to feel confident, curious, and hungry for more? Keep a close eye on what features competitors offer, but don’t be in a hurry to get anything out the door until the product works properly with the right UX.
3. Success criteria: Users comment about how they are using it and how they feel about it.

III. Experience stage: all UX, no lean

1. Objective: Research on what users are doing with your product means everything at this point.
2. Key considerations: Forget about adding features unless they are absolutely necessary. What are the biggest pain points customers have when using your product? How much trouble would it be for them to switch to a competitor now? This is a good time to study winning UX designs from around the world and figure out how to apply these insights to your product. The Hierarchy of Efforts is a great way to structure your UX improvements at this point.
3. Success criteria: Unsolicited customer referrals and viral adoption.

At UXPin, our wireframing and prototyping app is admittedly still at Stage II in this process. That said, we have done a lot of customer development and dramatically improved our core product recently to create a more complete and enjoyable experience. Soon we’ll be ready for Stage III, optimizing UX, and that will be a really exciting time for us—and our users.

UX Design vs. Lean Design

These two opposing forces really aren’t all that different from one standpoint: the user is driving the process, so the sooner you get on board with their needs, the more successful your product will be. Nobody cares that your product can do a million things and more. They only care if it works for them when they open the box.

Here is a rough rundown of what each process looks like for designing a new app.

Example of a UX Design Process

1. Identify people, a problem, and a project: People need an app that turns a week of recipes into a shopping list instantly.
2. Analyze your users and competition: Do some competitive analysis and create personas and experience maps to figure out exactly where the shopping app fits into the mind and market.
3. Design: This is where UX and creativity are formalized. The shopping app will start to take shape as it moves from a rough sketch to a wireframe or low fidelity prototype. Polish up the look and feel and the final state will be a high fidelity prototype.
4. Get Buy-in: Gather stakeholders and measure the excitement. This is the most undervalued stage and the point where products go bad due to lack of backing or not listening to users. Ideally, this should be happening between each stage.

Example of a Lean Design Process

1. Observe and Brainstorm: People shop by category (dairy, meats, vegetables) and make meals out of what is available. An ingredient focus can change the shopping experience.
2. Minimal Viable Product: Get feedback from a user test group on a bare bones recipe-to-shopping-list converter app.
3. Gather feedback and iterate: Maybe the shopping list isn’t the problem, it’s finding recipes easily based on lifestyle choices. Find out where the real problem lies and start over from there.

According to Jan Jursa, author of UX Storytellers and cofounder of MOBX Conference, the more mature the market in which your product is launching, the more you’ll want to lean on a UX design process. He believes that going MVP is not an invitation to skimp on fundamental product qualities. “Universal principles of design have been around for a long time and they are here to stay. If you think your next killer app can do without, think again,” Jursa says. “Elements such as harmony and hierarchy are an investment in the perceived experience of every product, as is usability.”

Stay Lean … With Your Eye On UX

Lean UX is gaining currency in the design world as companies try to fold the two approaches together seamlessly.

Source: Dean Meyers

The first key to achieving that balance in the real world is to keep UX as a goal at every stage of design and development, even when the focus is on getting the product into users hands. That way, when UX becomes more important, the design can easily incorporate the necessary changes.

The second key is more feedback from all stakeholders. That doesn’t mean try to please everyone, but it does mean that the funding sources and management team are just as valuable a resource as the users when it comes time for implementation.

Frank Lloyd Wright probably said it better than anyone: “You can use an eraser on the drafting table or a sledge hammer on the construction site.” It is far more effective to use an eraser early because customers don’t really appreciate it when you take a sledgehammer to what they see as “their” website. Launch with the most optimized site that you can and iterate from there to improve rather than overhaul. Your site is not carved in stone. It should evolve and change based on how users want to use it and the potentials unleashed by new technology.

Additional thoughts are included in the Guide to MVPs, which includes expert advice from UX folks like Brandon Schauer, Stephen P. Anderson, and others as well as analysis of MVPs from over 20 companies including AirBnB, Dropbox, Twitter, and Zappos.

Image of Frank Lloyd Wright’s Solomon R. Guggenheim Museum courtesy Jorg Hackemann/Shutterstock.

Written by: Chris Bank, UX Magazine
Posted by: Situated Research

The post Balancing Product UX and Lean Execution appeared first on Situated Research.

Option 1 is that they will tirelessly apply all their time and brainpower to trying to figure out your thing. The problem with this option is that the thing they are trying to figure out is probably trying to sell them something, and no one will work extra-hard just to be sold something. (I make the assumption that it’s trying to sell something because we are a marketing firm, and the things we make are generally supposed to sell stuff.) If the thing is entertaining or fun, you might have a chance for Option 1, but otherwise you can cross it off the list.

Option 2 is they will quickly give up and walk away. Of all the options, this is the one you should hope for, because Option 3 is not what you want.

Option 3 is that your thing will make them feel frustrated or stupid, and they may even get mad. Then their anger may be taken out on your brand, because people need to vent and blame someone for their bad user experience. This is just human nature. They might even be so frustrated that they post something negative on one or more of their social media networks. Then all of their friends, and even their friends’ friends, will know that your thing doesn’t work right. One Tweet turns into 3 million views (hey, it has happened). Ouch. We all know that social media is word-of-mouth on steroids, and bad comments or reviews have the power to make or break brands. This is why you don’t want Option 3 to happen.

The simple remedy

The good news is that Option 3 can easily be prevented. There is a simple fix for all of this, and I mentioned it at the beginning of this post. You simply test the thing before it’s produced, before it goes “out there” all broken for people to use as ammunition in online rants against your brand. This course of action sounds incredibly simple and obvious, which in fact it is, but it’s hardly ever actually undertaken by smaller brands, agencies or development firms that don’t have the deep pockets of Fortune 500s. Mega-brands like Amazon that make usability testing a continuous part of their routine (and their success stories) are the exception, rather than the rule. It seems that for Any Specialty Brand, Inc., usability testing either is not on the radar, is thought of as an unaffordable luxury, or, worst of all, is considered a waste of time and money. This couldn’t be further from the truth, because an ounce of usability testing is worth a pound of cure.

At Callahan Creek, I’m happy to say that usability testing that’s conducted with in-house UXD expertise is now SOP for all digital deliverables. As a UXD expert once told me after conducting hundreds and hundreds of usability tests, the process never once failed to uncover things that needed to be fixed or could be improved upon. That’s certainly been my experience as well. And more often than not the problems that we uncovered with usability testing were completely unanticipated – often with potentially serious consequences if left unaddressed. That’s because the people making the thing can’t get out of their own heads and think like the people who will be using the thing. Fortunately, there’s a simple fix: usability testing.

In usability testing, a UX specialist asks a testing participant to go through a series of tasks while the development team observes from another room. These rooms must be far enough apart so the inevitable shouts of “It’s right there, just click the button!” from the development team are not heard by the participant.

Written by John Kuefler, Callahan Creek
Posted by: Situated Research

The post Usability Testing Might Just Save Your Bacon – and Your Brand appeared first on Situated Research.

In earlier research, Tom Landauer and I showed that the number of usability problems found in a usability test with n users is:

N(1-(1-L)ⁿ)

where N is the total number of usability problems in the design and L is the proportion of usability problems discovered while testing a single user. The typical value of L is 31%, averaged across a large number of projects we studied. Plotting the curve for L=31% gives the following result:

The most striking truth of the curve is that zero users give zero insights.

As soon as you collect data from a single test user, your insights shoot up and you have already learned almost a third of all there is to know about the usability of the design. The difference between zero and even a little bit of data is astounding.

When you test the second user, you will discover that this person does some of the same things as the first user, so there is some overlap in what you learn. People are definitely different, so there will also be something new that the second user does that you did not observe with the first user. So the second user adds some amount of new insight, but not nearly as much as the first user did.

The third user will do many things that you already observed with the first user or with the second user and even some things that you have already seen twice. Plus, of course, the third user will generate a small amount of new data, even if not as much as the first and the second user did.

As you add more and more users, you learn less and less because you will keep seeing the same things again and again. There is no real need to keep observing the same thing multiple times, and you will be very motivated to go back to the drawing board and redesign the site to eliminate the usability problems.

After the fifth user, you are wasting your time by observing the same findings repeatedly but not learning much new.

Iterative Design

The curve clearly shows that you need to test with at least 15 users to discover all the usability problems in the design. So why do I recommend testing with a much smaller number of users?

The main reason is that it is better to distribute your budget for user testing across many small tests instead of blowing everything on a single, elaborate study. Let us say that you do have the funding to recruit 15 representative customers and have them test your design. Great. Spend this budget on three tests with 5 users each!

You want to run multiple tests because the real goal of usability engineering is to improve the design and not just to document its weaknesses. After the first study with 5 users has found 85% of the usability problems, you will want to fix these problems in a redesign.

After creating the new design, you need to test again. Even though I said that the redesign should “fix” the problems found in the first study, the truth is that you think that the new design overcomes the problems. But since nobody can design the perfect user interface, there is no guarantee that the new design does in fact fix the problems. A second test will discover whether the fixes worked or whether they didn’t. Also, in introducing a new design, there is always the risk of introducing a new usability problem, even if the old one did get fixed.

Also, the second test with 5 users will discover most of the remaining 15% of the original usability problems that were not found in the first test. (There will still be 2% of the original problems left – they will have to wait until the third test to be identified.)

Finally, the second test will be able to probe deeper into the usability of the fundamental structure of the site, assessing issues like information architecture, task flow, and match with user needs. These important issues are often obscured in initial studies where the users are stumped by stupid surface-level usability problems that prevent them from really digging into the site.

So the second test will both serve as quality assurance of the outcome of the first study and help provide deeper insights as well. The second test will always lead to a new (but smaller) list of usability problems to fix in a redesign. And the same insight applies to this redesign: not all the fixes will work; some deeper issues will be uncovered after cleaning up the interface. Thus, a third test is needed as well.

The ultimate user experience is improved much more by three tests with 5 users than by a single test with 15 users.

Why Not Test With a Single User?

You might think that fifteen tests with a single user would be even better than three tests with 5 users. The curve does show that we learn much more from the first user than from any subsequent users, so why keep going? Two reasons:

• There is always a risk of being misled by the spurious behavior of a single person who may perform certain actions by accident or in an unrepresentative manner. Even three users are enough to get an idea of the diversity in user behavior and insight into what’s unique and what can be generalized.
• The cost-benefit analysis of user testing provides the optimal ratio around three or five users, depending on the style of testing. There is always a fixed initial cost associated with planning and running a test: it is better to depreciate this start-up cost across the findings from multiple users.

When To Test More Users

You need to test additional users when a website has several highly distinct groups of users. The formula only holds for comparable users who will be using the site in fairly similar ways.

If, for example, you have a site that will be used by both children and parents, then the two groups of users will have sufficiently different behavior that it becomes necessary to test with people from both groups. The same would be true for a system aimed at connecting purchasing agents with sales staff.

Even when the groups of users are very different, there will still be great similarities between the observations from the two groups. All the users are human, after all. Also, many of the usability problems are related to the fundamental way people interact with the Web and the influence from other sites on user behavior.

In testing multiple groups of disparate users, you don’t need to include as many members of each group as you would in a single test of a single group of users. The overlap between observations will ensure a better outcome from testing a smaller number of people in each group. I recommend:

• 3-4 users from each category if testing two groups of users
• 3 users from each category if testing three or more groups of users (you always want at least 3 users to ensure that you have covered the diversity of behavior within the group)

Reference

Nielsen, Jakob, and Landauer, Thomas K.: “A mathematical model of the finding of usability problems,” Proceedings of ACM INTERCHI’93 Conference (Amsterdam, The Netherlands, 24-29 April 1993), pp. 206-213.

Written by: Jakob Nielsen (Jakob Nielsen’s Alertbox)
Posted by: Situated Research

The post Why You Only Need to Test with 5 Users appeared first on Situated Research.

Graphics are exceptional, as shown in the picture above (from the first level in the game). Usability is great as well: the first level slowly introduces the player to basic movement and combat in an embedded (situated) context, rather than in a separate tutorial. Game moves are introduced as they are needed to deal with enemies in the game, with all of the basic moves covered.

An easily-accessible book containing all of your character’s moves is a button-press away at all times: utilizing what academics might call ‘cognitive offloading’ – a means of having external representations available in the game (to look up moves, when needed) so that player attention can focus on the core gameplay. In other words, Quality Assurance (QA) did their job particularly well (besides the inability to rotate the camera angle in the 3D world). In particular, the first level of the game was excellent at teaching players how to play the game.

While QA did a great job with basic usability, effectively teaching the game players how to play, they failed at the overall user-experience in the game. Situated Research often explains to clients that QA is similar to testing code for bugs, while user-experience (UX) research is similar to testing a game’s design. In the case of Konami‘s new game, Castlevania: Lords of Shadow, the gameplay experience often resulted in button-mashing, where advancement in the game required a sore thumb from tapping the controller rather than formulating strategies to use in-game tools to overcome enemies. The latter (ability to create and test strategies) requires a game design quite different than what was found in Castlevania, where overcoming enemies was typically achieved through rounds of dodging an enemy’s very predictable AI followed by some strikes (before the next dodge was required).

Prior research (conducted by Situated Research and reported in our publications) describes how game players learn within games, and specifically how they progress through different phases of learning. (Learning was not examined as something that was necessarily educational; rather, learning could be any ‘change in behavior’ as a result of the experience of playing the game.) This research indicated that game players went through early phases of learning the game interface and basic game controls early in the game, transitioning to a later phase of more advanced strategy development. These phases correlate to the comparison between QA (basic usability) and UX (more advanced user-experience) research. Again, while Konami excelled at teaching players basic game usability and showing them how to play, the latter felt as if it was left to the wayside.

UX research will help to test a game’s design: showing the core ‘pillars’ of the game, or where the game really excels. In other words, there should be features within the game that are spectacular, allowing players to invest themselves (and their identity in the game, for social interaction), which gives players a reason to keep coming back to play the game. While Castlevania consistently provided players with rewards (such as new moves through a combination of button-presses), many of these rewards were not meaningful. Experience from killing enemies accumulates an in-game currency with which to buy new moves, but these new moves typically feed into the button-mashing gameplay. Using the new moves requires a memorized sequence of button-presses, which pulls player attention away from strategy development (player cognition is focused on rote memorization).

While many of the game’s graphics were exceptional, and core gameplay was taught well through embedded use (very good for usability), Situated Research felt that the game suffered from a design that inhibited player strategy development and unique, invested gameplay. Game levels did not allow much exploration: players typically were fed through a narrow path within the game world, where exploration was inhibited by the inability to move the camera angle. This also affected combat several times, as the player view could not rotate to view a charging enemy that was off the bottom portion of the screen. User-experience research could have helped Castlevania‘s design by helping to design game rewards that encouraged strategy, and by making the overall reasons for playing the game more explicit. While the artwork and storyline of the game did a great job at setting the scene, the overall game objectives were much less clear: the purpose of overcoming each enemy was not evident and did not seem to lead the player closer to their overall objective.

For those interested in reading more, our previous research incorporating features of Activity theory to analyze gameplay may be of interest, as it shows the relationship between basic game controls (operations) and motivated activity; and is achieved by analyzing a game player’s reasons for playing a game (how strategy development relates to goal achievement during gameplay). Special thanks to Christian Walker and Steve White for their help with testing the game. We are interested in your comments, so please leave them below.

Written by: Matthew Sharritt, Ph.D.
Posted by: Situated Research

The post Castlevania: Good Usability, Poor User Experience appeared first on Situated Research.