Three Suggestions for
"Newbie" Product Designers
-- Design your design process
-- Use constraints to boost creativity
-- Honor your " Newbie" status
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.
The User Environment Diagram was printed and put on the whiteboard in the project meeting room.
The mural canvas that we designed for user research
No.3. -- Honor your "Newbie" status
As “newbies”, many of us are eager to upgrade ourselves to the experienced stage. However, as we all know, the experience only doesn't guarantee great design. Newbie designer can create great work as long as we realize how precious this newbie stage is for our growth. When we are new to the certain area, we don't feel ashamed to admit we don’t know many things. We feel it is ok to ask “dumb” why-questions when we see experienced designers habitually think and act. We are so serious about what the user needs are. We never start with the conclusions. If we honor our “newbie” stage, we will gain the momentum that ultimately cultivates the mindset: always maintaining doubt over authorities, certainties, and patterns, which is the big differentiator between the experienced designer and the great designer.
When we were defining what we wanted to improve in the redesign of the data analytics platform, the dominant opinion in my product team was we should focus on the usability because many clients said out loud: "this tool is not intuitive to use." I agreed that usability was truly a problem. I also understood this internal anxiety about the usability as our company is well known for its quick response to clients’ request. However, I didn’t think the problem that looked most obvious was necessarily the root problem. Without identifying the root problem, the seeming problems would just come back again and again. According to the design research result, 80% of our client participants said: "this tool is not intuitive to use." Instead of immediately categorizing and triaging this as a usability issue, I asked a few "side" questions to those clients: “what is your typical workflow regarding reporting?"; " What do you expect from our reporting service?"; "How do you usually use the reports from us in your daily work?". What I wanted to understand is not just why they feel it was not intuitive to use, but also how their work was affected by this issue. Learned from my previous business development professional experience, I believe people's experience of using technology is organic. I wanted to understand those cause-and-effect relationships.
Interestingly, it turned out that 60 % of the client participants who complained about the tool actually barely tried out the tool. They didn’t use the tool not because it was “not intuitive to use”, but because they didn’t need to use it. Thanks to our customized client service, the clients always picked up the phone and got exactly what they needed in a timely manner from their client support managers. Their “not intuitive tool” comments actually primarily came from the demo tutorial sessions.
Based on these findings, I proposed to the team that we should not only improve the usability but also figure out what is exactly the role of this online tool in our data analytics service ecosystem. When are our clients supposed to go to the online tool to help themselves and when are they supposed to pick up the phone? These questions really shaped our redesign focus for this project (I will write another article to summarize what we learned in this redesign project.) I’m glad I was “so stubborn” to find out the “truth” at that time, and didn’t take the prevailing opinions as authority. Of course, as a newbie, to get opportunities to express your doubts and challenge something other people deeply believe, you don't just need the courage but also a real open-minded and encouraging team. I couldn't shape anything without my team’s trust and support.