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.
Your company is building out a toolkit to support third-party developers. You’ll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc. You’ve got a long list of desired controls from your customers. You’re agile. What do you build first?
Perpetually intermediate (competent) users. Users who briefly exist as novice users and never become experts. Most of your users are competent, and you should design for them. Competent users have different needs and different expectations than novice or expert users. How do you know your user’s competency levels, so you can design for them?
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.
Blue Ocean Strategy provides an interesting reactive analysis of companies and markets. Personas are used to understand your customer’s needs. Combining the two provides powerful proactive insights when positioning your product for market success.
Netlife Research brings us the 2009 Bad Usability calendar. Get it while it’s hot.
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.
Continue reading Use Case Management is a Tough Balancing Act
Netlife Research (company website in Norwegian) has done it again. Their 2008 Bad Usability Calendar is here and it is great. So great that it is hard to pick a favorite. Download it here. 2007 has more great examples.
[Note: This is a short post- just got back from the Velvet Revolver concert at Stubb’s. Living in Austin rocks!]
You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either. Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely. You have to make them want to use it, and you have to design the software for the users who must use it. Otherwise, you won’t achieve the ROI.
No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.