Rational vs. Empiricism
- All thinking vs. all doing.
- Rationalists believe that everything should be well planned ahead of time.
- Empiricists believe that you need to build the system to really understand how it works.
- Includes prototyping and user testing in development.
- Emphasizes iteration and multiple test cycles.
User And Use Models
- User model: who is going to use it.
- Use model: how they are going to use it.
- These models explicitly force you to think about the problem differently from different perspectives.
- Categorizing user from use allows designers to identify and assess their assumptions about the user.
- It is often necessary to make assumptions about the user, however it is best to identify them explicitly.
- It is necessary to identify bottlenecks and areas of optimization; ie. budgeted resources.
- Network Bandwidth
- There is a tradeoff between ease of use and efficiency.
- Sometimes budgeted resources change mid development cycle.
- Too many restraints can make a project difficult.
- Constraints are not always a bad thing, they can focus your design.
- There are different kinds of restraints, and not all restraints are necessary:
- Real constraints
- Obsolete contraints (Habits)
- Misperceived constraints
- Intentional constraints (Self Imposed)
- Typical examples.
- Provide a good/ safe way how to approach a problem.
- By examining other people’s design, you can borrow from their experience.
- Originality isn’t as important as usability.
- Without exemplars you only have your own experiences.
Process Vs. Innovation
- There is a market from both approaches and a need for both.
- Process is the design cycle and is structured, conservative.
- Process is something that businesses like, it is predictable, its safe.
- Process addresses the past problems; it focuses on what changes can be made to past models.
- Past processes might not be applicable to current or future situations.
- Process is veto oriented.
- A large part of process is risk avoidance.
- Process is driven by consensus and compromise.
- Can be based on past problems.
- Incremental updates are important to the design process, innovation isn’t always required.
- A focus on innovative can be hit and miss but most great milestones in development require big ideas.
- Innovation does not guarantee a good idea.
- Innovation often doesn’t fit into the process model of development.
- There are limits to innovation, only so many new things that you can do.
- A lot of great products have been made outside of the normal design process.
- Atomic Bomb
There are design principles that are universal and can apply to software development.
80/20 Rule (Pareto Principle)
- 80% of the work can be done in 20% of the time.
- Conversely, 20% of the work can end up taking 80% of the time.
- This principle also applies to code itself; often 20% of the actual code of a program does 80% of the work.
- For software developers, this means that a large portion of your time and efforts needs to be devoted to bugs, polishing, etc.
- It is important to focus your efforts strategically.
- Accessibility is not only applicable to people with disabilities.
- “7/11” rule - people wont use software unless its easy to use (simplicity).
- The purpose of developing software is to sell it, so ensuring that people want to use it is important.
- You need to ask yourself if people can understand your design intuitively; it should be obvious (perceptibility).
- Sometimes its okay to relay information redundantly in different ways.
- Users shouldn’t need to be an expert or need above average skill to use your product; you need to design for your target audience (operability).
- If the user makes a mistake, don’t punish them (forgiveness).