I personally agree with your comments, but there will always be some people who may not feel the same….

I think you have two primary sets of people to address. The first is
the people you work with (presumably developers and people generating
business requirements/product owners). They will have their own ideas
as to what they see as success from you, which will include whether
you deliver designs on time, and whether they trust your professional
judgement. You could derive some metrics from discussions with them.

The second audience is the users of the applications that you are
developing for. You can survey and talk to users, and get measures of
overall satisfaction, or of satisfaction with key modules. You can
also measure in a number of ways whether people can successfully
complete tasks, and how long it takes, and where they get stuck. You
can measure how many problems you identify with the usability of live
applications, and how many you have design solutions for.

Those are the sorts of things I’d be more interested in, as they
relate more directly to business success.

When I managed a usability group, I invited clients to give quarterly
feedback on how well the team was doing (ratings and qualitative comments
that were then coded by similarity). One issue that emerged from this
“client satisfaction” survey was that the type of report desired differed by
stakeholders. From that I learned to give clients examples of our reports
and ask them for feedback about how well the format would support their
needs (requirements input, detailed UI design, high-level consistency
issues, etc.).

Test current products, using both task based measures and SUS. This is your current benchmark level. New functions implemented are measured by meeting or exceeding the current benchmark. Indeed, you can add “target SUS” into the product development process, and measure by meeting that. The goal is to create quality new designs, and also test them. The target is to allow you to acknowledge that you might be building something very new or very complex, which will get a lower score naturally. It also helps you allocate your resources and negotiate with your peers.

You can simplify it out as % of new products meeting or exceeding target SUS, whether internally or externally designed.

Then you want to improve your current product/service. Over the quarter or year, your measure can be twofold: increase in system SUS, increase in specific task scores.

Your support example is easy to envision but very difficult to implement. Again, easier said than done. That doesn’t mean you shouldn’t go down this path, but it will be a lot of effort and coordination. Who educates the support people on which problems are related to product usability? Why should support take time out of their busy schedules to help *me* (being devil’s advocate) get the data I want? Getting support to change their processes is a political hurdle. Again, none of these are impossible, but they aren’t easy either. And aside from support, what are some of the other ways? I’m not trying to monopolize your attention on this post, but I find that many of these things are eloquently preached from the podium but after the speech, everyone has a dazed look in their eyes and no idea of how to actually follow through.

I agree with educate-and-administrate, but only to a point. People have different areas of expertise and natural talent. You could educate some on all the important concepts in usability and graphic design and they still would make bad choices and not have the capability to style. So do I educate? Absolutely! Do I still see the need for some approval process despite the obvious bottleneck? Unfortunately yes. Development does code reviews don’t they? With that said, I do firmly believe in giving others the tools to help them make the right decisions (we have implemented an in-house design library of template, patterns, etc. for that purpose specifically, although we still find the need to rework and tweak).

As for the comments on “insight”… I have several issues with that but will have to comment later due to travel.

Again, despite disagreeing on some points I really value your comments (and I’m sure others do too). Thanks so much.

Here’s where I’d start: Talk to your support folks. If your product design is not optimal, then they are spending time answering the phones (or handling emails, dealing with a support forum, or other activities to support customers).

You can quantify how much it costs for someone to answer the average question from the customer. You can project that if you could eliminate the need for customers to call with the top 10 questions, you’d save the company that much money.

Then do it.

That’s just one of a ton of ways to quantify customer experience improvements in terms of dollars.

You have as a responsibility to “3) Approve any UI design work done outside of Product Design”. We have a ton of research that shows this will likely stagnate your group, as it makes you a bottleneck and produces a substantial reduction in likely quality. You’re creating a review-and-approve organization and we have lots of data that says that doesn’t have long term success.

Instead, I’d take all 4 responsibilities and replace them with “Ensure that every design decision in the organization is made with up-to-date knowledge of customers, users, their goals, their needs, and the designs that will eliminate frustration and produce the most delight.” This would move from a review-and-approve approach to an educate-and-administrate approach (for former being reactive and the latter being proactive). This completely changes how you approach your work and will change you from a service that produces and approves designs to a resource that improves the customer’s experience.

Metrics that are in relation to each other don’t work because what happens when one goes up without the others. Do you discount it’s value?

As for getting data from sales: I’m betting they want the best product to sell. The easier the product is to sell, the easier they make their commissions. If you can promise them easier sales, you can get their cooperation on any number of fronts. Where are your metrics that ensure that sales will have an easier time selling your product than they do this year?

You want metrics that give you insight. Given that, I’d ditch the following: #1, #2, #3, #5, and #6. None of those are insight generating (even #5). You want metrics that give you insight, then measure the number of hours *all* employees spend watching real users/customers interact with your (and your competitor’s) designs. That’s your critical number. (You separate out the number of hours senior management spends. That’s actually more critical.)