Process: Requirements Definition

UXmatters has published 20 articles on the topic Requirements Definition.

Top 3 Trending Articles on Requirements Definition

  1. The Best Ways to Prioritize Products and Features

    Ask UXmatters

    Get expert answers

    A column by Janet M. Six
    December 23, 2013

    In this edition of Ask UXmatters, our experts discuss the best ways of prioritizing a list of products and features.

    In my monthly column Ask UXmatters, our panel of UX experts provides answers to our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: [email protected]. Read More

  2. Agile Development Is No Excuse for Shoddy UX Research

    November 21, 2016

    Agile development and UX design are like a couple in an arranged marriage—a relationship between two strangers who are expected to coexist, develop trust and respect, and eventually, love each other. Throw UX research into the mix and you have the makings of an even more awkward alliance, as you can see in this typical conversation between a UX designer and a product owner, somewhere in the middle of Sprint 0:

    Product owner: “Hey Jen, when can we see some wireframes?”

    UX designer: “Well, we’re wrapping up our user interviews and putting together some personas—basically trying to get more clarity around our target users. We’ve already started on some sketches, but I expect we’ll need to make some tweaks based on what we learn.”

    Product owner: “That’s all very good. But we can’t afford the luxury of spending too much time on research. Sprint 0 ends next week. We can’t keep the developers waiting! Let’s speed things up. I’d really appreciate if you could get those wireframes going quickly?” 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

Sponsor Advertisement
Continue Reading…
Supporter Advertisement
Continue Reading…

New on UXmatters

Champion Advertisement
Continue Reading…