We mentioned the creation of personas in our overview of the interaction design process. In this post we will talk in more detail about how to create them. We will cover identification and prioritization of the personas, defining the corporate and personal goals for the personas, and creating the anecdotal stories that give each persona an identity against which we can make design decisions. Scenarios are also defined for the primary personas, which drive the creation of the functional requirements specification.
Design / Interaction design / Requirements / Requirements gathering / Software development / Software requirements specification / UX
Posted on:
Interaction Design Process Overview
Interaction design, as described by Alan Cooper in The Inmates are Running the Asylum, is a process for designing software by focusing on the most important users. Unlike traditional requirements gathering and solution design processes, interaction design focuses on the goals of a specific class of users, represented as a persona. Those goals are considered when defining scenarios that represent how the primary persona will use the software. The combination of goals and scenarios leads to design artifacts and a functional specification. We will explore these steps in more detail in this post.
Agile / Design / Interaction design / Outsourcing / Requirements / Software development / UX
Posted on:
Software design and specification and making movies
Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. Cooper is presenting the analogy in the context of validating the business case for investing in interaction design, but it holds true for requirements as well.
Definitions / ROI
Posted on:
Definition of payback period
We’ve talked previously about using ROI to determine which projects to fund. This isn’t the only way to make those decisions, as Ski points out with the concept of flush. Payback period is the measure of how quickly an investment returns the invested amount, or the break-even point in the investment.
Foundation series / Software development / Test Automation / Testing
Posted on:
Software testing series: Pairwise testing
Very large and complex systems can be very difficult and expensive to test. Often, we inherit legacy systems with multiple man-years of development effort already in place, in the field and of unknown quality. With these systems, there are frequently huge gaps in the requirements documentation. Pairwise testing provides a way to test these large, existing systems. And on many projects, we’re called in because there is a quality problem.
Administrivia
Posted on:
Bear with us
Laptop died last night. Migrating to home pc. Will be back next week.
Project Management / Requirements / Use Cases
Posted on:
Organizing a software migration project
In an earlier post on requirements for migration projects, we defined a continuum of migration projects, ranging from completely new business processes to identical processes. In this post we will look at why companies approve identical-process migration, or duplication projects, and provide some tips on how to organize these projects.
Marketing / Requirements / Software development
Posted on:
We must sell the software first
We write a lot about value-driven prioritization of software requirements. It’s easy (when defining requirements) to forget that we have to sell the product before anyone gets any value from it. With internal use software for large companies (like enterprise software, intranets, erp systems), “sell it” means “get high user adoption rates.” High user rates are key to getting ROI when process-improvement is one of the targets of the software.
Project Management / Requirements / Software development
Posted on:
Managing scope creep is not a zero-sum game
We’ve never had a project where we didn’t have to address scope creep. As a supplier, we prioritize loyalty and relationships above incremental profitability. Project management techniques for addressing scope creep do us a disservice by starting with the presumption that resources have to be managed in a zero-sum game (every new feature must displace an existing feature). In this post we will talk about the opportunity to strengthen the relationship with our customer as part of addressing scope creep. It is not a zero-sum game.