A Designer who feels they are powerless to influence the design of the project, and therefore are not providing design direction.

• Can mutate into: “The Note Taker” Designer
• Dangerous when coupled with: “The Dictator” Product Manager or “The Diva” Software Developer
• Likelihood of fixing: None
• Danger to project: None

Problem

Everyone has a breaking point, and designers are no different. Many designers working on large software development projects participate in an unfortunate yet predictable sequence of events:

1. They are given vague requirements that they need to interpret.
2. The stakeholders tell them they have free reign to interpret them as they feel best.
3. The designer interprets the requirements into a user interface design that they feel is best for the user.
4. The designer presents their design to the stakeholders.
5. The stakeholders pick apart the design, demanding a long list of changes, many of which ignore basic design principles or will make the product harder to use.
6. The design is resubmitted to the stakeholders.
7. The stakeholders offer commentary on what they think are the remaining problems with the design, resulting in a shorter list of changes which further corrupt the usability and aesthetics of the product.
8. The designer complies, presenting the final design to the stakeholders, which the stakeholders begrudgingly accept with sentiments such as “We can always improve it later”.
9. The designer presents the UI requirements to the development team.
10. The development team complains that the UI designs have poor usability and aesthetics, demanding a long list of changes, many of which ignore basic design principles and will make the product harder to use.
11. The designer complies, presenting a revised design to the development team.
12. The development team begrudgingly agrees that the design is good enough to start implementing.
13. During implementation of the design, the designer is asked to compromise on their design as certain UI requirements will “Take too long to develop” or that they can use off-the-shelf UI components if the design requirements are changed.
14. During QA, the designer attempts to open bugs where the implemented UI does not match the design specification, which the project team argues are low priority bugs.
15. The product ships, and customers complain about the UI, and the designer is blamed.

This sequence is more the rule than the exception, and is the main reason many designers of enterprise software are deeply unhappy in their role. In this state of unhappiness, The Disenfranchised designer gives up on trying to influence the design process, and instead just goes through the motions from paycheck-to-paycheck as they look for a new job. As a result, the project no longer has a designer on staff, and the product’s UI slowly spirals into an unusable ugly mess.

Solution

It is easy to mistake The Disenfranchised designer as a case of burnout, to which rest and relaxation are the cure. However, it is not exhaustion or stress that has left the designer in this state of listless unhappiness, it is the process they are forced to follow. It is tempting to believe that the solution is to simply fix the process, but the process is endemic to the software development industry as a whole, and is therefore not easily changed. It is also tempting to believe that replacing the designer is a solution, but the new designer will also quickly become The Disenfranchised. Indeed, with a process that cannot be fixed, there is no fixing the problem.

The Disenfranchised designer does not pose a danger to the project, as they are following the process the project asks of them. The only impact is they are not acting as a guard to the deterioration of the product’s UI, which frankly most companies cannot measure and therefore do not care about. Therefore, the long term effect is a successfully delivered project, but with a resulting product that will never live up to its full potential.