Building software involves a lot of communication. Behind this communication, lies perspectives. These perspectives often get lost somewhere between initial goals and final product, which can lead to failed software. I found that by using a simple Perspectives Frame, I improve my chances for success.
- Industry Perspective - industry constraints and standards
- Business Perspective - business goals and constraints
- Technical Perspective - technological requirements, technical standards and practices
- User Perspective - User experiences and goals
I could easily over-engineer it, but in meetings and hallways, this quick, memorable frame of four categories helps. OK, so it looks simple enough, but how do I use it? Here's how I use it in practice:
- Understanding goals - First things first, I want to know goals and drivers from the different perspectives. Knowing which bucket they fall in, helps more than a random collection of requirements.
- Understanding priorities - Which perspectives take precedence? For example, corporate line of business applications tend to optimize around industry and business at the expense of the user experience, since users don't have much choice. On the other hand, an emerging breed of social software applications, puts the user front and center. In another case, e-commerce applications have to get the user experience right, since users do have choices.
- Checkpointing representation - Is my customer representing the user, business, technical or industry perspective? Do I have the different perspectives represented?
- Rationalizing decisions - If I know that for a scenario, user experience take precedence, I can make more effective decisions, moving towards the goal.
- Rationalizing feedback - If I know which perspective feedback is coming from, I can have a more meaningful prioritization discussion. If the team knows that for this case, the success of the user experience is key to the business success, that's a different story than if we
- Choosing the right techniques and tools - Some techniques tend to be optimized for a particular perspective. That's a good thing. The trick is to know that and explicitly decide if it's the right tool. For example, performing Kano Analysis can help you identify user satisfiers and dissatisfiers. On the other hand Taguchi methods will optimize around technical perspectives.