Human Factors - the TL;DR

Human factors involves making a product or system user friendly. It entails integrating humans into the design of a system such that the end product has a user centered design.

Human Factors - the non TL;DR

Human factors is about applying what we know about people to the design of systems. Human factors in regards to application, the focus is on integrating the end user of a product into the system. When designing products it, we have to consider the demographics of the end users and how that impacts how the product will be used. For example, if we were designing chairs for use in college classrooms, we would not want the dimensions of the chair to be that for a small child. Another thing human factors looks at is context of how the user will be using the product and determining the different ways the user might utilize the product. This occurs so that the system can be designed so when the user goes to use it, it works in the manner that the user expects it to work. Human factors practitioners also do this so that if the user uses the product in a way that it is not supposed to be used, the system can gracefully degradate.

Application of Human Factors

People who study human factors can go into different sub-disciplines of human factors. Examples of sub-disciplines are user experience and ergonomics. User experience (UX) has a lot to do with evaluating the usability of a product and making sure the feedback from the end users is incorporated into the design of the product. Ergonomics is making physical items that we use, such as chairs and computer mice, fit the human in a comfortable way that reduces the amount of wear and tear that would take place on the body. Good ergonomic design can help prevent repetitive use injuries.

Human Factors and Engineers: Effective Communication

Human factors practitioners what to make sure the product has a user centered design. Engineers want to make sure the functionality of the product is working. Without human factors, it can be difficult to make sure a product meets all the requirements and have a product the end users can easily use. However, without the engineers, we would not have a functioning product. It is important that these disciplines work together, and work well. This means that communication is critical. Here are some things that I've learned are necessary in order to have human factors and engineers communicate effectively.

1. Understand the context of the topic of conversation.

Often, human factors will say one thing and it will mean something completely different to the engineers. Likewise, things that engineers say can have a different meaning for human factors. It is important to recognize that what you are saying might not mean the same thing to somebody in a different discipline.

2. Think like the other discipline (sometimes)

There is a reason why different disciplines exist. However, with these different views come different ways of thinking (and so does miscommunication). It is important to recognize, that even though you think you are talking about the same thing, sometimes that isn't the case. To help realize this, try thinking about why the other discipline might be saying what they are saying. Note, this is easier said than done.

3. Ask for clarification questions.

It is important to recognize when you don't understand something or when you might not realize what the other person is saying. When this happens ask for clarification. It never hurts to ask how something works or how something got designed.

Key Points for Human Factors Practitioners to Remember

Sometimes when we are busy doing our job, it is easy to forget some important things...

1. Sometimes your design changes are unrealistic to implement

So you've analyzed a system with human factors methods and have some suggestions. Something that might seem like a simple design change might be hours of work for the engineers developing the product, which would cause a huge setback in development. Due to deadlines and constraints, sometimes it just is not feasible for your design changes to be incorporated.

2. That product you're evaluating is the engineer's kid

Engineers go through a process to produce a product to hand over to the customer. In the same manner that you put in long hours to do your human factors analysis, the engineers have put in many hours to build this product. Sometimes they started with nothing; sometimes they are building onto an existing product. Either way, remember to be respectful of the dedicated hours of technical skill that has contributed to getting the product to its current state.

3. Communicate to the engineers what design changes are the most important

Sometimes there will not be enough time to implement all of the recommendations. It is important that you tell the engineers which of your changes are critical to the success of the product and why. In most cases, product development does not allow for implementation of each human factors recommendation.

4. Be constructive in your feedback

One does not simply say "Fix it!" or "The users didn't like this." This type of feedback does not help the engineers. When you give feedback for design changes you need to be prepared to 1- explain what was wrong/not helpful, 2- explain why that feature was not helpful, 3- give specific recommendations for changes, and 4- explain why you are making those recommendations. Remember to also be prepared to back up your recommendations with an analysis using human factors methods that was conducted on the product.

Including Human Factors in the Engineering Design Process

There are many ways to include human factors in the development process for a product. In the ideal world, the human factors person (or team) would be included from the very begining. Many times this is not the case, however, I have outlined suggestions for what the human factors person can do during parts of the engineering process.

Needs Statement
Starting from the begining, sometimes you can convince your product owner that human factors is important. Do this when the product owner is developing a needs statement, or at the very begining of requirements elicitation. The important thing is that product owners have written down that the system have a user centered design and include human factors. This encourages the engineers to be more accepting of human factors. Warning: this does not garauntee that usability will be a priority and don't be surprised if somebody comes to you asking to sign off for human factors being included when it really wasn't (though sometimes this is due to time and budget constraints). Once the product owner has iterated that they want human factors to be included, follow up with the appropriate people so that product owner need is met - sometimes standing by and doing nothing is not good, however, there might be times due to political presures where you will have limitations in completing your job.

Requirements
When requirements are being developed, make sure you are involved. If your organization is implenting traditional "System shall" requirments, you have the potential to be particularly useful for the development of non-functional requirements. *Make sure you know the difference between requirements and design!* (Requirements explain what, design explains how) (Project management: Make sure the test plan is being written in parallel to the requirements document. Good requirements are testable!)

Test Plan
(Project management: Make sure the test plan is being written in parallel to the requirements document.) (Project management: make sure to test and document as you go!) While the engineers are writing the test plan for how they are going to be testing requirements, you should be writing your test plan on how you are going to be doing usability testing (don't forget to get IRB approval if needed).

Design (for User Interface)
(Project management: make sure to capture design documentation and document as you go!) When designing the user interface, it is important to map the requirements to the design of the system. It is great if there is a user centered design, but it doesn't matter if your product does not meet requirements. (Project management: don't hold up the engineers by putting off design implementation if human factors is taking too long to come up with a mock up. Make sure that some implementation of proof of concept is being done in parallel of producing a design.) Sometimes while you are coming up with a user interface design, the engineers will be working on a proof of concept for the functionality of the product. Basically, while you are working on the user interface, they should be working on the back end to make the product work or designing how they will be making the back end. As you are prototyping, consider getting user feedback on the prototype. Remember that while you are prototyping your design, you should also be doing an analysis and conducting human factors methods.

Implementation of Design
Evaluate the product as it is being built. Make sure to get user feedback as progress is being made on the product. Note: there is a difference between alpha and beta testing and doing a usability study, though there are some similarities.

Testing
You should get all usability testing done before the project moves into the final stages of testing. If you don't get usability testing done before then, there will most likely not be time to implement your recommendations.