This summer I landed the first full-time internship in my life at a big corporation. As the only UI/UX design intern in my team and the only designer in my project, I am really grateful for this experience, as my soft skill as a designer was definitely practiced and improved throughout the 4 months, which might be even more valuable in the long run.
The major project I was working on is directed by senior executives and our goal as a team was to obtain the buy-in in order to go through the proper product development process later on. My job was to deliver the proof-of-concept “mockups” that visualize the potential features and facilitate the conversation between the executives and our team leads during this “pre-development” process. Therefore, the constant changing of directions is the nature of this project, as well as receiving different voices from 6 stakeholders.
Work with stakeholders
Working on a project that involves 6 stakeholders without enough user testings or research data can make it a challenging situation for the designer. I received a ton of feedback and change requirements from each person in every meeting. In the beginning, I found it hard to formulate the tangible execution: I left confused and wondering which requirement I should execute on. The fact that these requirements come from different stakeholders who might not be present in the same meeting makes the situation even more challenging: Are they on the same page? Which request is my priority? When there is a conflict between stakeholders, who should I listen to? I summarized 5 success tips below:
Note-taking and recap
In every meeting, you can catch me taking notes like crazy because this is my first time working in fintech and cyber, and there is a huge learning opportunity for me. I tried to capture everything I have heard, seen and read to bridge that knowledge gap, and take time to digest and reflect on what I learned at the end of the week. Although my notes seem like nothing but just tons of random information in the beginning, the Aha moment came to me eventually where I am able to understand its inner connection. Meanwhile, when working with stakeholders, I wrote down what they said with their name alongside the note, so I can identify and understand each person’s perspective and follow up on those requirements later on. This also applies to the sign-off process, get a writing proof, write down the time, the person’s name, which might cover your ass someday.
Communication is the key
Meanwhile, know your audience, in this case: understand your stakeholders. It’s crucially important to be able to understand and think from their perspectives. The ideal audience for a designer to present the rough design wireframes and low-fidelity works is people who are familiar with design thinking and design processes: they understand your design intention, and sometimes they can even see your next step in their mind. While in some cases, low-fidelity works can’t speak that much in stakeholder meetings: you might find stakeholders frowning while staring at your design, and there is that uncomfortable silence after you explain your design rationale, it seems they just can’t understand what you are playing over there… Therefore, as a designer, you need to find the best way to communicate your design work. At the end of the day, our goal of design presentation is to make sure everyone is on the same page and have the conversation around the work, why not see this as an opportunity to find the most accessible way of design review?
What do you think as the DESIGNER?
Being able to articulate the rationale behind your design decision and stay strong is so important but also challenging for junior designers as we might not have enough confidence to voice our design decision: you are the youngest person in the meeting room, you are negotiating with people who have decades of work experience in the industry. However, if you are just busy satisfying with all the change requirements and never voice your own opinion, you as a designer will not be trusted and valued. You design for a reason. Do your own research, find the ground for your design decision and don’t be afraid of voicing your opinion. At the end of the day, our goal is to deliver better design, better product.
Look for support
You are not alone. This is what my project manager told me in the second week of my internship. If you ever find yourself struggling with anything, reach out to people you are comfortable talking with. Tap their shoulder and have a quick check-in/regroup to discuss what you feel confused, or look for quick feedback on your latest wireframe. People are here to support you, and we work together to make the project move forward.
Version Control and Clear Documentation
Due to the nature of my project, we went through many design iterations. I can’t emphasize enough on the importance of version control. I stored all the versions just in case we jump back and forth (which happens a lot in my project). Figma offers great version control tools for designers and you can clearly see the changes in each version and easily revert to old files. Meanwhile, I also write clear documentation of those files, including things like date, signed off person, key changes made in this version and next step, for potential future revisits.
Adapt your own design process to the workplace
I go to art and design school for a 4-year design degree and I spend most of my time learning and reading books about design and research methodologies. Like most designers, I believe in design iterations. I do rough sketches, I create wireframes, low-fidelity design, high-fidelity prototype, and then maybe add some kickass micro animations to the interactive prototype. User testings also play a big part in this process to make sure my design decision is valid. This is the design process I learned from school and how my design process looks like when I work on my own side projects, also, it is what the project manager told me the design process will look like at the beginning of the project.
I started some rough sketch on my iPad, and I created some simple wireframes. In the second project meeting, I showed my rough low-fidelity design to the team, and then I was told that this version will be hands-off to devs due to the change of project timeline, and there won’t be time for a second iteration to create high-fidelity polished work as I will start to work on another project immediately. I was so surprised at that time as I don’t think this should be the end of this mockup, even it’s just a proof-of-concept. During our weekly retro/demo time, everyone applauds for the demo developed exactly based on my rough design (people are very nice there), but I feel quite embarrassed to see my imperfect design displayed on the big screen: I know it can be much better, and it’s not my best work.
I reflected on what happened in this project, and I decided to use mid-level fidelity design or jump right into high-fidelity designs I have for all the design conversations that happened with those stakeholders. Although this means more work for me as the designer, it acts as a concrete starting point of all the stakeholder meetings and helps to spark more ideas on the table. In the end, it turned out that my design became the glue that kept all the conversations moving forward, and my speed and work received great feedback among the team.
Thank you for reading! I hope you find this article helpful :)