There are a few ways these meetings might be organized depending on where we are in the design-development process.

• early concept: help me think about the problem
• late concept: help me choose among these ideas and develop one
• early detail: this is where we are going, what caveats remain?
• late detail: here's a the detail, what questions do I need to address?

These depend on the thought that there are a few phases/horizons to product design work, namely

1. Problem Framing (aka Research or Horizon 3), in which we learn about the challenges and needs of users to understand and select a problem to go after with concepts,
2. Concept (or Horizon 2), in which we develop concepts and select among them with the help of users and engineering, and
3. Detail (or Horizon 1), in which we develop the selected concept and test the fitness of our more detailed work with users as we go.

It's a common anti-pattern that engineering gets involved only when we are in detail, but we'd like to pull them into the other phases to be informed about the available problems and to help us develop and select among concepts.

Some Agile purists will decry this phasing as anti-agile, but that requires a blinkered view of what Agile means, which often comes about when one confuses Scrum for Agile. (The dirty little secret of Scrum is that there's a lot of hand-waving about the large quantity of work that needs to happen outside of sprints to make Scrum possible.)

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.

1. Customer – is the work produced by the designer informed by the customer, appropriate to the customer, accepted by the customer?
   1. 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.
   2. 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.).
   3. Accepted is essentially adoption. The same caveats apply.
2. Collaboration – is the designer an effective collaborator on their project teams? Do they work well with their peers and their project teams?
3. 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?
4. 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.

At work there's been a move afoot to tag items in our roadmapping tool as "globalization," "internationalization," "localization," or "translation."

The executive level thinking here is that we are not offering our products globally, and need to be. So what do you do about that? You globalize!

To my thinking, though, there are universal requirements, things that the underlying product should do everywhere, and requirements borne of local data formats, terms of art, regulatory environments, etc. Universal versus local. Then there's the work of offering interfaces and commendation in a newly-supported language, and the things you must do technologically to make your application able to deliver these universal and local requirements and serve interfaces and documentation in the correct languages.

To my thinking, a universal requirement is just a requirement. The special ones, therefore interesting to tag, are

• localization: things that need to be done differently due to a locale's needs – preferred data formats, regulatory environment, terms of art, etc.
• translation: the actual translation of interfaces and documentation into a newly-supported language or English variant
• internationalization: things that must be done technologically to enable us to address either of the above

A tag that would be applied to all or almost all of the items seems like it might not be that useful. Globalization is the goal, not a specific type of work. It probably doesn't make sense to separately call out universal requirements, as these should be numerous. Most work should be universal.

Meanwhile, globalization also includes marketing and sales and support and other things. Trying these terms on wrt marketing: we want to globalize our marketing, so we consider the universal messages we want prospective customers to understand (which should not be a special effort), then we look at how these might need to be localized (made locally specific/applicable) and translated (in the right language), and what processes we need to internationalize (tech/process/people to enable the above) to make conveying these messages possible.

I might be thinking about this wrongly, but this is my current understanding.

Heather asked me yesterday "who owns accessibility?" That's a fun question. I replied:

Accessibility is not owned. Who owns quality? It's a team responsibility. To the extent that accessibility compliance, or release date, or the P&L is a "feature" of a piece of software it is owned by the PM, but each function has its responsibilities in accomplishing accessibility. Making these responsibilities explicit is necessary.

The folks with responsibilities mainly include UX (designing for accessibility), FED (engineering for accessibility), QA (inspection), and PM/PO (prioritization). These aren't collected in one person's purview around here until the CEO, so that's not the answer to your question.

If we are to be product-led and not sales-led, PM has to insist on it (and manage competing priorities), maybe that's part of the answer.

The "ownership" urge seems to sometimes dilute or deprioritize the responsibilities of others, which is a shame because we must work in concert.

In her post on LinkedIn, Laura Cotterill (one of my new coworkers) refers to Eric Chan's post about teamwork and wonders why such a seemingly obvious mode of work is out of reach so much of the time. To which I responded

My impression is:

1. When we pressure people to overproduce we encourage them to defend themselves in ways that seem locally sensible but turn out to be anti-collaborative.
2. Financial planning, especially when the business is not self-funded, tends to require a forecast; that forecast hangs from a roadmap, effort estimates, and sales targets.
3. When a business sees the sales team as its economic engine rather than the product itself (sales teams tend to be good at preserving this impression), opportunities detected by sales get pushed onto that roadmap with less discussion than necessary.

Of these I find the first the most pernicious.