Tracking Competencies for Product Design
Expectations as a designer when looking for new positions and from companies and hiring departments looking to fill roles don’t always align. I’ve worked in different roles, with different titles, and under different team structures. Each has been similar, but had also been very different. What you read in a job posting, what you hear described during an interview, and what you actually experience on the job might not be the same.
Where I am now is coming towards an inflection point in terms of understand what design can mean to the company and the services it provides; both on internal- and external-facing teams. Our services teams lack a way to to track and identify skills. They also lack a way to enable measure professional growth. There is a lot of talk of hiring T-shaped designers and developers, but we don’t really live up to that idea. T-shaped skillsets are usually discussed with the idea of hiring a diverse team, each member having their own “T,” a wide breath of knowledge with a deeper core focus. Have enough T and their breaths and depths compliment each other, allowing for a stronger, more capable team that can address a wider range of problems. However, the reality has been looking for the same T without an understanding of different skill sets.
For our services team, we’ve been working on building out matrices to help illustrate different areas on knowledge for the roles on our team: development and engineering, design, customer success, etc. I took the lead, getting feedback from our other designers, to draft a competency matrix for UX design on our team.
There was already an existing one for architect engineers on the team, and that established a blueprint for how we framed the others, UX included. I also looked at the example posted by F. Merry in his attempts at this. You can read more about his process and try his matrix in his post, “What is a good product designer?” I also drew on my experience on the board of AIGA Boston and as Boston organizer for Action Design, taking cues from the discussions with local designers and the programming we established to help meet designers’ needs.
The matrices overall haven’t been implemented yet, but they have opened up more conversations. Overall design maturity, especially in terms of UX, is low. Both in terms of the company’s target niche and in its internal culture, the only things understood are IT and business interests. UX is largely seen as—for services—as front-end development and visual design, or—for the product team—illustration and visual design. It’s been a tool so far to help educate others on the breath of what UX can mean.
This project isn’t done, and the goal hasn’t been to have a definitive one, just one that as a team we’re confidant enough to start using and that we can review an update as we start using it. So far our services UX designers have evaluated themselves on it and the current push is to get the different services teams to adopt the overall service team competencies, including this UX one.
You can view the current here and try it out yourself. Let me know what you think.