The Note Taker

A Designer who is relegated to doing nothing more than documenting the ideas of others.

  • Can mutate into: “The Distrusted” Designer
  • Dangerous when coupled with: “The Patent Author” Product Manager
  • Likelihood of fixing: High
  • Danger to project: Medium

Problem

Everyone uses software every day, leading many project team members to feel qualified to comment on what is or isn’t a good User Interface (UI). This typically comes in the form of “I like” or “I don’t like”, and the expectation is that the designer’s job is to capture the likes and dislikes of the group. A Designer operating exclusively in this mode is The Note Taker, whereby they are only capturing the ideas of the group, rather than providing any design direction of their own.

All designers must present their design to a project team for acceptance, but what differentiates The Note Taker from a healthy design review process is the order in which documentation is written:

  • If documentation precedes feedback, it is a healthy design review process.
  • If dictation precedes documentation, the designer is only taking notes.

The Note Taker is not performing the role of a designer, regardless of their background or true capability. When they are in a pure documentation role, their job can be done by anyone who knows how to use graphics software. Indeed, this is often why The Note Taker is employed: other team members do not know how to produce design documentation with graphics software.

The core issue with The Note Taker is that there is no designer on staff. The more complex the requirements, the more a lack of design direction will result in a clumsy UI. All too often, this is how most enterprise software is “designed”: with no designer at all.

Solution

How big a problem The Note Taker is depends entirely on what role the project needs a designer to play. If the stakeholders have specific UI requirements, as they would if the requirements were based on a feature done by their competitors, then the Note Taker is most likely performing the role the project needs them to.

If you truly do need design direction and contribution for the project to be successful, which path to take when fixing The Note Taker depends on their skill level:

  • If taking notes is the extent of their capability, you will need to find someone else to fill the role of a designer.
  • If they have simply relegated themselves to their fate of taking notes (see “The Disenfranchised” Designer), the design authority needs to be given to them by the project leadership and stakeholders.

Granting authority is simple, and costs the organization nothing, provided the Product Managers are confident enough in the designer’s ability. Having been granted this authority, it is then important that the designer works to establish and maintain credibility, or risk their authority being taken away (see “The Distrusted” designer).

2 thoughts on “The Note Taker

    • Here is how I think about it:

      Scenario #1 – A Note Taker with only a Graphic Design/Art background
      Scenario #2 – A Note Taker with only a HCI/UX/Usabilty background

      In Scenario #1, a Note Taker can be quite happy in their role, as what they are told their role should be, and what they most likely would prefer their role to be is are in sync. They want to spend their time creating beautiful, interesting, compelling designs, and so long as they can do that they’re happy translating what people are telling them into mockups. The problem here is, just because the design is beautiful, interesting, and compelling; doesn’t mean it works for the user of the software product.

      In Scenario #2, A Note Taker would be deeply frustrated, as they *know* that their job should be far more than simply documenting what other people think the UI should be. Furthermore, as they don’t have a graphic design/art background, most likely their mockups are simpler and more utilitarian, and therefore won’t get the positive reception an intentionally-beautiful UI would. This then creates tension around the stakeholders not being impressed with their HCI/UX/Usability-based designs, as well designed user interfaces are so obvious and intuitive that they’re downright boring. This then practically guarantees that they mutate into “The Disenfranchised”, as no one can stay motivated when they’re stuck in that position.

      In summary: Scenario #1 everyone’s happy, in Scenario #2, no one is happy. In both cases, the product isn’t getting the benefit of a properly designed user interface.

Leave a Reply