22. +Customization +Complexity

A GOOD INDICATOR that more research on our users is needed is when we decide to allow a user to customize the product.

Example: We internally discuss whether the sidebar should be on the right or left side of the screen. Some argue it should be on the right, others on the left. Both positions seem well-supported by their advocates. We can’t agree, so we make the “decision”:

“Let the user decide: give them the option to customize it.”

This decision seems to resolve the discussion, but only defers the problem.

Now, the choice is transferred to the user, and the complexity to the development team that must build and maintain both options and the means to configure them.

The practice that helps make informed decisions always involves including the user in the design table.

Conducting field research, prototyping, and quantifying results are key. In summary, the decision to allow customization of a feature should exist as a consequence that it benefits the operation of the tool, not as a way to avoid making an informed decision.

BONUS TRACK: There are other “classic” problems brought by feature customization:

• Excessive complexity in the product
• Difficulty for support teams (each user has a “different version”)
• Risk of reducing the usability of the tool