Another common diagram to create is a user interface (UI) navigation or UI-flow diagram (…) to explore how you will architect the UI of your system by exploring the flow between major UI elements, including both screens/pages and reports. This is critical to your system’s success because the user interface is the system to your stakeholders. Not the technology. Not the data. Not really cool frameworks that you’re working with. If you do not architect the user interface effectively you run the risk that you will build a system that your stakeholders aren’t interested in working with. See example from the book ‘Maturing usability‘
- Don’t agree on a fixed price for agile pojects.
- The client needs to understand and agree to employ agile methods. Introducing Agile through the back door will cause lots of trouble (“We said right from the start: we wanted this (…) feature”) and extra cost.
- The whole production team will need to think and work agile.
My personal take on Agile Prototyping/Development: The ability and the necessity to constantly check horizontally (what I do makes sense across all segments of the project) and vertically (what I do makes sense from a high level point of view).
“In software, design permeates construction.”
The four design problems in software development:
- Design of the problem
- Design of the solution
- How do we build it?
- Builing it
Alan Cooper (video): Similarities Between Interaction Designers and Agile Programmers