Software product success.
The last step in our agile software development project was documenting our understanding of our users. In this article, we will define the personas that we will use to guide our design and requirement development. This definition of personas is built by combining our experiences in consulting, product and program […]
A look back at the best from a year ago.
Its easy for us to overdo almost anything. Kim Goodwin offers some good advice about how not to overdo it when using personas as part of our software development process.
Mike Mace provides us with some great insight about market research – helping us to avoid ‘the blender’ and ‘the gap’. The gap is a reflection of the inability of most customers to innovate. The blender is the loss of useful market information into a homogenized input that pushes only the lowest common denominator – again stifling innovation. We have to avoid the blender and the gap to get useful data from our research.
Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.
We were all student drivers at one point. But no one stays a beginner indefinitely. Almost no one becomes an expert driver either. Most of us are competent drivers. Driving skill probably even follows a bell curve distribution, with most drivers being OK, some “bad”, some “good”, and very few experts or beginners. We’ll show in this post how to apply this pattern to software requirements and design.
The same is true of our users
subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.