Our experts first discuss how to elicit clear product requirements from stakeholders. Does the right approach differ for small versus large companies? Do product requirements capture the goals of stakeholders? Do requirements reflect the true needs of users? Do they establish a good understanding of technical constraints? How can you validate the assumptions behind product requirements? What kinds of research should influence the definition of product requirements? How should you balance the needs of users versus the business?
Then, our expert panel considers some different viewpoints from which we can review design solutions: stakeholders’ business goals, the needs of users in various roles, and the feasibility or ease of implementation. On the other hand, focusing on one particular user’s needs during a design review can yield a greater number of insights. Considering different user-interface layers lets you structure your evaluation of a design solution. Plus, it’s important to consider the effectiveness of design artifacts as well. Read More
A theme I deal with a lot, both at work and in this column, is organizations’ asking user assistance (UA) developers to support more products with fewer resources. For UA developers who are experiencing a resource crunch, the obvious solution is writing less user assistance for a product than we would have produced in the past. (See my UXmatters column “Hockey Sticks and User Assistance: Writing in Times of Resource Constraints.”) But that still leaves the problem of how to write less and cover users’ information needs adequately.
Everett Rogers’s seminal model of the technology adoption process , charted in Figure 1, suggests an approach that might let us put the proverbial 10 pounds of content into a 5-pound bag of writer capacity. Rogers noted that the phases of technology adoption correspond to its adoption by distinctly different classes of people, who accept new technologies at different paces. Read More
So, you’ve wrapped up your customer research, completed your personas, and have even written a few scenarios that show how users would want to interact with your brand new product. What’s next? What happens to the personas and scenarios once you’re ready to start requirements definition and design. Are you sure you’ve adequately communicated the type of system your users need to the Business Analyst and Interaction Designer on your team?
If you’re like me, you’ve always felt something was missing once you finished creating your personas and scenarios. They communicate the heart and goals of the user, but miss out on a lot of details. And while it’s the intent of both documents to do just that, neither personas nor scenarios succinctly communicates to your business what features a product or service should have and why it should have them. Read More