A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.
Category Archives: Interaction design
Posted in Agile, Business Analysis, Business Rules, Interaction design, Interface Design, Product Management, Requirements, Requirements gathering, Software development, UX, Uncategorized
Tagged agile interaction, Communication, process prototyping, prototypes, prototyping, uml as prototype
28 Comments
Cadence Versus Risk
I’ve been thinking about the software development process. Big, upfront, design and requirements. User research and analysis. Market insights, gained on exploration or over time. Release cadence – how quickly you get, and incorporate, feedback from your customers about your product. How quickly you react to your competitors’ reactions to your actions.
Read the rest of the article …
Use Cases for Iterative Development
Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage requirements for incremental improvement?
Read the rest of the article …
Posted in Agile, Business Analysis, Interaction design, Prioritization, Product Management, ROI, Requirements, Requirements Models, Software development, UX, Usability, Use Cases
Tagged agile development, agile use cases, incremental development, iterative development, satisficing, use cases
17 Comments
Measuring Great Design – Mad Libs Input Form
I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.
Bonus: the idea is cool.
Design-Free Requirements
Design-Free requirements are important for two reasons, and hard for two other reasons.
Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.
Read the rest of the article …
User Goals and Corporate Goals
When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal. You need to be aware of both. Having a positive user experience is important, and requires a user-centered understanding. Achieving your corporate goals might be in conflict with some user goals.
Read the rest of the article …
Use Case Management is a Tough Balancing Act
Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.
Posted in Business Analysis, Interaction design, Prioritization, Product Management, ROI, Requirements, Requirements Models, Software development, UX, Use Cases
Tagged business goals, corporate goals, end users, goal directed use cases, goal-driven use cases, Interaction design, managing data, personas, principal stakeholders, principle stakeholders, structured requirements, two tier, two tier requirements, two tier sales requirements, two-tier business model, ux
3 Comments
Managing Stakeholder Goals
A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.
Nexus – Drag and Drop
Implementation continues on nexus, and we’ve re-factored the way that items in a bundle are ordered, as mentioned in our earlier post. We talk a little about affordance, and show a couple screen shots.
APR: Persona Development
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 management, and business analysis.
A couple other good articles on how to create personas:
- Leisa at disambiguity on the merits of creating personas.
- Practical persona creation at evolt.org.
In this article we define our primary, secondary, and supplemental user personas.
Latest Articles
Comments on all Articles
