[SIZE=15px]Thank you, Donna for your excellent rebuttal. I’m very much enjoying this exchange.[/SIZE]
[SIZE=15px]First off, let me say that any argument in favor of user research applies equally, if not moreso, to “up-front” user research. Once I dispatch with Donna’s arguments, I think you’ll see that it’s impossible to argue on the one hand that user research is “crucial,” but on the other that up-front user research is not. If user research is necessary at all, then it most definitely is best applied early in the development cycle, i.e. “the earlier the better.”[/SIZE]
[SIZE=15px]So let’s break down Donna’s argument. It comes in two parts: 1) for a new design, users are often unable to articulate their needs, and 2) for redesigns, designers often already have an intimate understanding of the users’ needs either through informal methods (like analytics) or through day-to-day communication. What is it about a redesign in her argument that suddenly endows users with the ability to articulate their needs escapes me, but I’ll move on.[/SIZE]
[SIZE=15px]Rather, I’ll argue that users’ inability to articulate their needs doesn’t obviate user research, it just makes the job of sussing out the user’s needs harder. But when user research is completed after the fact – instead of at the beginning of the project - UX designers are often already married to their vision of how users should complete a task. Any changes that come as a result of user testing are done in the context of the initial design work rather than based out of findings from structured conversations with users about their tasks, workflow, needs and constraints. When designers design before they listen, their subsequent efforts focus on making a square peg fit through the round hole they’ve created.[/SIZE]
[SIZE=15px]As for redesigns, they come in many different forms: those completed for various business purposes, those necessary for technical upgrades, and those completed simply because the existing product has usability concerns. Often it’s a mix of these three. In the case of a redesign that includes concerns about the existing application’s usability, it’s absolutely critical to conduct up-front research to prevent repeating mistakes of the past. [/SIZE]
[SIZE=15px]But regardless of the reason for the redesign, up front research is still necessary. Here are a few reasons why:[/SIZE]
[INDENT][B][SIZE=15px]Lack of continuity in redesign team. [/SIZE][/B][SIZE=15px]Between the original design and the new design, it’s very unlikely that the design team is composed entirely of the team that did the original design and user research.[/SIZE]
[B][SIZE=15px]Increased user experience with the product. [/SIZE][/B][SIZE=15px]The user has been using the product for many years, and they have more mature workflows and ideas about their needs, so their requirements may have changed.[/SIZE]
[B][SIZE=15px]Setting a new baseline to measure ROI.[/SIZE][/B][SIZE=15px] Presumably you followed best practices and did user testing on the old system before shipping it. Now the system as been in use for awhile; you may have even pushed some minor revisions into production. It’s a good practice to re-establish baselines for the UX against which you can measure ROI of future efforts. (Training baselines, how long it takes to perform processes, etc)[/SIZE]
[B][SIZE=15px]The most vocal users aren’t necessarily the most productive. [/SIZE][/B][SIZE=15px] The quiet wallflowers who sit in their cube and get their work done, are often not the ones reporting their needs. They weren’t the squeaky wheel, but they’ve got a wealth of insight to be shared. So basing your redesign on the communication you have with the most vocal users isn’t representative of your user base and may, in fact, miss feedback from the most productive users. [/SIZE]
[B][SIZE=15px]Analytics only sniff out questions to be asked of users[/SIZE][/B][SIZE=15px]. Analytics are great at telling us what we do right, but not at telling us what we’re doing wrong. They don’t provide the answers or insight into underlying challenges, motivations, and behaviors.[/SIZE]
[B][SIZE=15px]Skipping steps like user research adds risk and cost to the project budget. [/SIZE][/B][SIZE=15px]And it’s not a matter of if there will be additional costs, only how much those costs will be. No one wants to be in the position of reporting that, at the conclusion of user testing, the team found the application needs major revisions to launch successfully. Measure twice, cut once.[/SIZE][/INDENT]
[SIZE=15px]As I’ve laid out in this post and my previous post, user research is a best practice for numerous reasons. Designers who consider it optional, do so at their own peril. And again, I go back to the Dunning-Kruger effect — those who think they know enough about user behavior and assume they don’t need to conduct research are MORE likely to be wrong.[/SIZE]
[SIZE=15px]Before I conclude, I would like to thank Donna for a spirited debate and the folks at UX Mastery for providing this forum.[/SIZE]