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.

Budgeted Resources

• It is necessary to identify bottlenecks and areas of optimization; ie. budgeted resources.
  • Memory
  • Network Bandwidth
  • Time
  • Heat
  • Power
  • Money
• There is a tradeoff between ease of use and efficiency.
• Sometimes budgeted resources change mid development cycle.

Constraints

• 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)

Exemplars

• 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

• 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.

Innovation

• 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.
  • iPhone
  • Unix
  • Python
  • Atomic Bomb
  • Fortran
  • Penicillin

Universal Design

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.

Accessability

• 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).