An example design prompt:
“Design an intuitive chat component for our web application.”
Many of the prompts that I see my colleagues take sound similar in verbiage to the one above, and this is particularly frustrating. Why? Well, design is about the architectural whys of a system, not just the intuitiveness and aesthetic qualities of its components. With many teams, an introduction to this concept is not so easy to make clear.
To communicate ideas like this, we must sometimes fully devote ourselves to understanding and speaking the language of our teams and our customers. Let me tell you a story about how learning the language of my team at NASA JPL has helped us better produce experiences across the laboratory.
A Title Change
I work on a team that is designing a system to make more engineering more collaborative and less error-prone. I wear an interaction design hat on a day-to-day basis. On this team, it has taken some time to communicate design and the problems it answers best.
Previously, I had been considered to be part of the development team. A requirement for an “intuitive chat component” would funnel down from systems engineering, I would design it, and a developer would pick up my specifications and write some code.
I hope you’ve caught it by now — there lies a fundamental problem with this process from a design standpoint. The above should beg the question,
Why didn’t he get to ask why?
What evidence provides that this “intuitive chat component” should be a product requirement? Does it satisfy a true need? Have we thought about how it will fit into the existing information architecture?
My team dictates that the systems engineering team is responsible for addressing questions like these — not the development team. Systems Engineering determines product requirements, the problems those requirements address, and the means by which those requirements should be tested.
Eureka! Kinda seems like Interaction Design belongs on this team, doesn’t it? Upon this realization, it became clear to me that I should encourage my team to recognize me as systems engineer, instead of some special type of developer.
Design as ___________________
As designers today, we should be willing to drop our egos and readily embrace other job titles. This is especially the case at organizations that have not yet fully embraced design thinking at an institutional level.
One of the biggest frustrations in our field is that most organizations define design as the making of aesthetic things. To an extent, that’s fine! Let’s leave that be for now. Said organizations likely have teams within them that are actually doing a bit of thinking before development begins. The big question we as designers we must ask is, “who?”
For one organization, that might be Management. For another, that might be Marketing. For mine, that just so happened to be Systems Engineering.
The next big question we should ask involves how we might interject our methods to the benefit of the team. For me, that started with getting my team lead to start calling me a systems engineer. I needed to define myself by way of my team’s language in order to seek out the why’s behind our information architecture, to determine the corresponding user needs behind our system, to influence the process behind the design and development of our product, and so on.
Only once this was done did my tasks progress from “design an intuitive chat widget that we can integrate into our web application” to “find out how adding a social aspect to our web application may help our users in getting things done.” This simple team-internal title change from Interaction Designer to Systems Engineer involved me in more architectural meetings, more conversations about our product development process, and more control over the comprehensive user experience. It was this change in understanding that helped my team realize that design is more so an architectural concern than anything else.
I encourage the rest of the design community to learn the language of its clients and organizational peers. We must embrace the language of our stakeholders to communicate the utility of design thinking. Let’s put aside our egos for a moment and create understanding among our teams just as we do our users.
How do you communicate to your team the meaning of design? Who determines product/service requirements on your team and why?
