We know to treat business rules and business requirements differently. One example – treat external government regulations as rules (because they are less subject to change than requirements). When you have multiple systems in an architecture, while “rules” makes sense for one system, “requirements” make sense for another. What do […]
Measuring the ROI of Design
Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is […]
APR: Design Element Sketches
Here are the scans of the design elements I drew out the other night as part of the design and requirements exploration for our agile project case study. There are seven images (with larger versions) showing design exploration.
APR: Mixing It Up With Design And Requirements
With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly? Prototyping.
How To Not Suck At Design
Michael Shrivathsan just wrote an article presenting five tips for creating products with great design. Michael’s List Start with the user interface. [Roger Cauvin adds, start with a working first iteration] Work closely with UI designers. Pay attention to details. Simpler is better. Be brave. Our Thoughts User centric design […]
Valuable and Functional Requirements
Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.
From Market Requirement To Product Requirements
We looked previously at an example of market analysis, defining first a market opportunity, and then a market requirement. We wrote an article a while ago about how to go from an MRD to a PRD. In this article, we will look at the journey from our market requirement to associated product requirements. And thanks, Roger, for throwing down the gauntlet.
Top five usability blunders (and fixes)
Five easy steps to alienating your users with bad usability Fail to simplify a comprehensive interface so that new users can quickly climb past the suck threshold. Build an inconsistent UI layout or interaction design that varies throughout the application, creating a sense of dissonance for the users. Interrupt the […]