Recently, I have got messages and emails from prospective students and new grads from my program in CMU (Carnegie Mellon University). People are interested in my experience with working as a product designer (software product design). Reflecting on my practice, I came up with three suggestions, which I learned from the workplace in the past year, for the newbie product designers or those who think about becoming product designers. 

 

No.1 Design your design process

 

We product designers are trained to be so good at identifying the problems that our clients or users are facing, which is indeed half of the success (I shared my thoughts about reframing the design problems in this article I wrote last year). As for another half of the success - solving those problems, it greatly depends on if we adopt the right design process. How do we define the "right design process”? If you believe there was something wrong with the design process, how would you fix it? Or do you think you, as a newbie product designer, should fix it? These questions are particularly worth to ask yourself when it comes to the giant system design which involving intense team collaborations.

 

I started to think about these questions in one of my design projects: redesigning an enterprise level client-faced data analytics application. It was a system design with huge complexity in content, UX, and UI. My role in that project was the lead product designer who closely worked with my product team, stakeholders, and other related departments to come up with the design solution and created the prototype. In the discovery and ideation stages, the communication and collaboration across teams were very efficient and effective. However, surprisingly, when we arrived the design (build) stage, we stuck on lots of back-and-forth discussions on content and features and wound up endless versions of "final version" wireframing (you can imagine my pain). What confused me was: we conducted thorough user research, our product team and stakeholders agreed on the design concepts, and we validated the design concepts with our clients by involving them in a co-design approach, but why we still have so many back-and-forth discussions when translating design concepts into screens? My hunch was there might be something wrong with our process, but what exactly was that? By observing the team discussions and talking with some of our team members, I found that people either got into the weeds or were incoherent about their thoughts. I realized that, in face of this level of complexity of the content and features, it was just hard for people to be aware the impacts and interactions among all of these content and features all the time, and it was very demanding to always keep the system structure in mind. We need to find a way to decrease the cognitive load, and facilitate people’s structural and systematic thinking.

 

To address this problem, I proposed to add one more step before we went to UI stage: User Environment Design (UED). It is a system design method first introduced by Hugh Beyer and Karen Holtzblatt in their book: Contextual Design: Defining Customer-Centered Systems (Interactive Technologies). We spent one week together to create and refine the User Environment Diagram. The diagram was composed of focus areas that are translated from storyboards. Each focus area clearly defined the interactions between the users and the system, and the interactions between focus areas were also visualized. The relationships of the content and features within this system became easy to understand. The User Environment Diagram was printed and put on the whiteboard in our meeting room so that it can work as a reminder in our meetings to help us keep this blueprint of the system in mind. Since then, our discussions became more effective. Ambiguity and confusion were eliminated in the meetings because we all use the same language defined by UED and communications are grounded on UED. In the following mid-fi and hi-fi design stages, UED worked as my UI design guidance, which unsurprisingly expedited the design and prototype.

 

 

 

 

 

 

 

 

 

 

 

From this project, I learned that it is my responsibility, as a product designer, to apply the design thinking in the whole design process, not just in the user research or ideation activities. Our design work is the fruit of the design process. How can we expect a great design solution if the design process is problematic? Even if your organization may already establish the design process, it doesn’t mean you should follow blindly. There is no perfect "one-size-fits-all" design process. The design process should never be something static and standardized. Rather, it should be agile enough to respond to the unique needs of different projects. So, please be mindful about your design process. If you think there is something worth to discuss about the design process, talk to your team regardless of if you have the authority to shape the process or not. If you are as lucky as me to be empowered by my amazing supportive team to explore new approaches, then own this opportunity and make some changes. If you are still building this trust, please still articulate your thoughts. At the very least, these thinking can help you and your team reflect on why the design success or fail at the end.

 

No.2 Use constraints to boost your creativity

 

Constraints are usually simplified or trimmed in school projects so that you can apply and practice the frameworks/models/skills you learned from your program in an ideal context. In reality, constraints are all over the places in the working environment: you might often be told you wouldn't have that "luxury" to conduct user research; You may not have adequate data and background information to understand the business needs; You may also have to keep tweaking your design due to the technical challenges your development team are facing. What may be even more frustrating is you may find out some of the user needs that got validated by your design research would never be addressed unless the internal process is adjusted, which beyond your product scope; And so on and on. Trust me. It doesn't matter where you work: big company, small company, "cool" company or " old-school" company, you will always come across various constraints like those mentioned above. Instead of resisting or just reacting to the constraints, you should apply your design thinking to look at the limitations. You can use them to boost your creativity. Let me use the same example to illustrate what I mean by this.

 

In the analytics project (mentioned earlier), we had a couple of constraints when it comes to the design research: the design and development timeline were very tight (always tight); the product team had different opinions about the scope of the design research; both the internal and external users were located across different time zones; the research might need to involve multiple departments in the company which could cause lots of administration communication… all of these constraints posed two challenges to me: 

First, how can I convince my team that we need to do the design research for this project in spite of those constraints? 

Second, how to design the design research that works well with the constraints while achieving all the research goals?

 

 

To answer why we must do the design research for this project, I worked with our design manager to aggregate all the critical questions the product team should be able to answer with confidence before we do any “real” design (e.g. “what do the users exactly mean when they say “the design is not user-friendly?”, “why many users said they don’t have the need to use this product regardless of the design is good or not?”). Then we had several rounds team discussions about how much we know about these questions? What we think we know are based on evidence/data/facts? Or just assumptions? If we dive into the design without knowing much about the answers to those questions, how much it would affect the success of the product? These objective discussions helped the product team realize what we really don’t know, and we eventually achieved the agreement that we should conduct the extensive design research to inform our design.

 

As we had concerns about the time, the resources and the cost of the research, we decided to utilize a few smart tools to create an innovative design research experience for everyone involved in the research. We primarily used Mural, the online collaboration tool, to conduct 90% user interviews and workshops. Integrating Mural into our design research was such an inspiring experience. More than screen sharing or audio/video conversation, Mural creates a more intuitive online environment that facilitates the real-time interactions for remote participants. We designed the scenario-based interactive activities for the participants to visualize their thinking process. We gained much more profound insights from observing how the users actually “did“ the activities not just from what they said. All of our user participants loved using Mural to participate in the research. “It’s creative and efficient.” By integrating the advanced technologies, we conducted twenty-eight one-on-one, 45-minute user interviews, one 10-people, 2-hour long design workshop and one online survey within ten days.