Process: Requirements Definition

UXmatters has published 22 articles on the topic Requirements Definition.

Top 3 Trending Articles on Requirements Definition

  1. Writing Usability Requirements and Metrics

    Ask UXmatters

    Get expert answers

    A column by Janet M. Six
    February 9, 2009

    In this installment of Ask UXmatters, our experts discuss how to write effective usability requirements and determine the right metrics for the redesign of a legacy, public-sector system.

    Ask UXmatters exists to answer your questions about user experience matters. If you want to read our experts’ responses to your questions in an upcoming installment of Ask UXmatters, please send your questions to: [email protected]. Read More

  2. Communicating Customer and Business Value with a Value Matrix

    December 15, 2008

    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

  3. Differentiating Your Design: A Visual Approach to Competitive Reviews

    Research That Works

    Innovative approaches to research that informs design

    A column by Michael Hawley
    April 13, 2009

    A common activity at the outset of many design projects is a competitive review. As a designer, when you encounter a design problem, it’s a natural instinct to try to understand what others are doing to solve the same or similar problems. However, like other design-related activities, if you start a competitive review without a clear purpose and strategy for the activity, doing the review may not be productive. One risk is that you may find you’ve wasted your time reviewing and auditing other sites, because you end up with findings that don’t help you design your own solution. Another risk is that the design and interactions of competitor offerings might influence your solution too heavily, whether you intend them to or not. Once you’ve seen how others have solved a particular problem, their solutions may subconsciously affect your own thinking.

    But while competitive reviews pose some risks, I contend that doing them is still valuable. Designing without first understanding what others are doing in the same competitive space means you’ll miss out on an opportunity to leverage others’ experience, and you might not be cognizant of possible threats to your strategy. To differentiate your Web sites and applications in the marketplace, you must be aware of what others are doing. Key to a successful competitive review is to have a clear objective for your review and minimize the risk of bias when doing your own designs. In this column, I’ll discuss a structured approach to competitive reviews I’ve used successfully to help my team understand the competition. This approach focuses on identifying opportunities for differentiation. Read More

Champion Advertisement
Continue Reading…

New on UXmatters