A Designer who is more concerned with how the product looks and feels than if it does anything useful for the end user.

• Can mutate into: “The Distrusted” Designer
• Dangerous when coupled with: “The Napkin Sketcher” Product Manager
• Likelihood of fixing: None
• Danger to project: Extremely High

Problem

Software development projects build or enhanced products that are hopefully of use to someone. As such, they tend to have utilitarian user interfaces that emphasize function over form. The Artist places more emphasis on form than function, leading to more design direction related to: color; negative-space; font; iconography; animation; transparency; gradients; and shadows; rather than the user’s tasks and goals. The UI requirements are therefore thin on specific interactions, while being very detailed on look and feel. This then leads to churn on UI requirements, as questions will be raised as the product is being built and tested that The Artist has not considered, and typically has no good answers to.

In the final analysis, The Artist designer produces poor requirements. Generally, their “requirements” will be nothing more than a series of screen shots defining only how they want the product to look. There will be some placement of controls on the screen, but without detail as to their function. When pressed for details, they will typically refer the developer to the Product Manager’s requirements, expecting the development team to fill in the gaps between a static screen composition and a functioning product.

If The Artist is paired with developers that have user interface implementation background, they can most likely fill in the gaps for themselves, but this then leaves QA in a position whereby the do not know how to test the product. A typical sequence of events is as follows:

• The Artist presents their typically beautiful screen compositions to the stakeholders, which receives rave reviews based purely on its aesthetics.
• The Artist provides the developers with the same approved screen compositions.
• The developer fills in gaps in the requirements to the best of their ability.
• QA then attempts to test the UI, realizing that they are not sure how the product is supposed to function, leading them to ask the stakeholders for clarity.
• As this is the first time the stakeholders have been exposed to how the UI actually works, they will typically have changes, the extent of which could range from minor tweaks to throwing out the UI completely and starting over.

The Artist designer can have a devastating impact on the project’s time lines. They create a situation where there is a high probability that major changes can come very late in the project, potentially causing entire features to be completely rewritten.

Solution

When faced with The Artist, most project team members will say exactly the same thing: “Add more details.” As simple and straightforward this may seem, it is normally beyond the capability of The Artist.

Typically, people who go to school for the arts, and/or choose a career in the arts, do not also have the analytical and technical skill required to write detailed system interaction requirements. Indeed, with enough time and effort anyone can learn anything, but this poses yet another problem: The Artists does not want to learn these skills as it takes them away from their true passion.

To “fix” The Artist is to change a key aspect of their professional identity, and to a certain degree who they are as a person. This is not reasonable, and in many situations is not desirable. The Artist is not necessarily bad at what they do; it is that they are being asked to do the wrong thing.

While they cannot (and perhaps, should not) be fixed, a mitigation strategy is to pair them with an Interaction Designer who has more emphasis on defining the usability of the application, than its look and feel (see “The Professor” designer). This partnership of Visual Designer/Interaction Designer is common in the industry for companies with the budget to hire more than one designer.