I tend not to be in favor of output metrics like these; they’ve been shown to be counterproductive for developers (lines of code, commits, bugs crushed, etc.), for example. But I am thinking about how best to apply the process maturity scorecard to the work of the individual designers to try to coach them on their projects. If a designer is helping to improve the process maturity of their product team(s), that’s a good sign.
On the other hand, some anti-metrics (trouble indicators) are pretty obvious – if there’s a lot of rework coming back to a designer, if deliverables are sloppy, if product managers and engineers are dissatisfied or under-involved, then we can tell there is a problem. But the opposite of these are not great metrics for individual performance, as a certain amount of rework will be technically driven, we don’t want to create an inspection-heavy situation where each deliverable is scrutinized for lack of sloppiness, etc.
I do have expectations that designers will bring work to and contribute to critique, seek my counsel on design challenges, press for collaboration, etc. But do I want to count these behaviors? Probably not.
The ideal thing would be to peg team performance to the product metrics we hope to install. The metrics we really care about are user success metrics in a product, and these are team metrics, not individual performance metrics.
So when it comes time to evaluate a designer, I like to use four Cs – customer, collaboration, culture, and content.
-
Customer – is the work produced by the designer informed by the customer, appropriate to the customer, accepted by the customer?
- Informed a leading indicator, evidenced by their participation in research and testing. They are or are not doing this. Exactly how much is situational, nonnumeric.
- Appropriate is somewhat evident in testing, and ultimately evident in adoption, a lagging indicator (and highly dependent on product and engineering decisions, the appropriateness of the feature idea in the first place, etc.).
- Accepted is essentially adoption. The same caveats apply.
- Collaboration – is the designer an effective collaborator on their project teams? Do they work well with their peers and their project teams?
- Culture – what is the designer’s contribution to the culture? Are they intellectually and emotionally engaged in a way that improves their teams and the org, is neutral, or detracts from their teams and the org? Are they improving and helping the culture improve?
- Content – is the designer’s work organized, communicative, complete, insightful, timely? Are their skills and attention to detail usefully on display in their work?
The best articles out there about measuring designer performance are a) not very good and b) old, such as Measuring Designer Performance, or How do I create KPIs for my design team. So I’ve been content to use those four Cs, which are similar in concept to how IDEO evaluates their creative and engineering staff.