5 things I learned in my first Product Design internship
During my 10-week internship at ZapLabs, I grew so much not only as a designer but also as a working professional. I am extremely grateful for my experience, and therefore I wish to share my learnings with whoever is interested.
Design for special cases
If you have ever done any programming, you probably realize that a problem can be so much trickier with the edge cases. Unfortunately, real life is full of these “special” cases, which means the problems that we designers tackle with can be as difficult as (if not more difficult than) those hard algorithm problems. At first, I did not realize the similarity between these two, so I did not fully engage my logical reasoning on the complicated project that I was working on. That led to some inefficiencies and changing things back-and-forth.
Reading the chapter “Design can Sadden” from Tragic Design (by Jonathan Shariat and Cynthia Savard Saucier) with my design team has definitely helped me get into that mindset of designing for edge cases. Right before I started reading that chapter, my UX researcher Matt and I had a discussion on how we can prevent user frustration when they accidentally mismatch their contact information with our system (Zap) fields. I was hesitant to add the Preview step to the already long and complicated bulk import feature, but we also don’t have another solution that can be implemented easily and promptly.
Reading the saddening consequences when edge cases were not handled really enlightened me on how to prioritize UX decisions. In this case, since there are many special cases at each step(e.g. What if their CSV file doesn’t have this? What if they didn’t realize they can upload without that? What if they prefer the other flow because that’s less painful? etc.), what I did was listing out all the possibilities in a flow chart. The visualization helps me see what the potential user flows are, so we can guide them accordingly.

Later, I implemented a few changes to make the process more fail-safe, which include the Preview page to allow users to see how the contacts will look like in Zap before they import.

Not polished does not mean not detailed
This is my first time designing for a non-tech-savvy demographic (our users are real estate agents and brokers, and the majority have a low tech literacy), and it gave me some challenges and new perspectives. Often times when we design for school or personal projects, we do user testings on our friends and other millennials who grew up with all kinds of technologies. Therefore, it’s easier for them to understand what I mean even when I just have a really rough prototype.
However, after the first round of user testings with four middle-aged real estate agents in the middle-east U.S., I realize that my prototype should be as realistic as possible to give the best results. For example, when making the InVision hotspots, I did not check the “maintain scroll position” option for screens that I want to maintain scroll position (e.g. when you select an option from a drop-down menu, your scroll positions shouldn’t change), because I never scrolled to click that option on my screen. However, some users had different screen/browser size, and others preferred to scroll down and page when the drop-down menu expands. When they selected an option, *BANG* the page jumped to the top scroll position. The initial user reaction was mostly confusion — they weren’t sure if they broke something. Apparently, many of them did not realize that happened because what they are using is just an InVision prototype, which basically works like a slide show.
This seemingly trivial detail did not affect functionality or anything core, but it disrupted user experience to a certain extent. When it happened too often, it could even negatively impact our testing result, even though it has nothing to do with this feature. Therefore, being as detailed and realistic as necessary in your prototype can be crucial to the user testing result, and is thus a good practice for designers.
Justify your design decisions with research (of all kinds!)
Working with an existing pattern/component library is another thing that you don’t deal with in your school/personal project but you do in the workspace. Sometimes you have to introduce a new pattern or make a design decision that makes total sense to one person yet not the other. This is when you need research to back up your decision — whether it is some real data from user testing, A/B testing, or an existing pattern in other Apps and products. These researches enable you to not only explain why this works but also show that it actually works.
For example, I used a blue border instead of the default gray for drop-down boxes that we need users to take actions on, but at first, the designer who was working on our component library did not fully support this decision. I explained why I want blue instead of gray, and how this use case was different from any existing use case, but he was not fully convinced. At last, I showed him a similar use of color in Zolo’s design, and he was finally convinced.
Take full ownership of your project
In the beginning of my internship, I was a bit timid and wasn’t sure if something should be my concern. However, this mindset stopped me from thinking holistically on the project. A big lesson on this is that I ignored the back-end processing time for importing a large amount of contact information. As a result, I had to make significant changes to the flow after presenting it to my PM and the whole project team.
Indeed, that sounds like a PM/engineer concern, and I could also argue that this wasn’t taken into consideration in the previous round of design from a year ago, but some reflection leads me to realize that since I am a designer here, I should be considering everything that makes a difference in the design of this feature. This realization encouraged me to take more initiatives within and beyond my project during my internship there.
Iterate — not only on the prototype but also on yourself
In the 9 weeks spent with the bulk import/upload feature, I lost count of how many iterations I went through and how many changes I made on every big or small thing in the prototype. Iteration is such a familiar concept for designers, and I personally like it so much that I iterate on myself too.
Going into the work life, I was a bit uncomfortable with not being able to receive feedbacks on a regular basis. Therefore, inspired by our school’s Teaching Assistants’ home-made Google form questionnaires, I also created my own “mid-term evaluation” and “final evaluation” forms in my 5th and 10th weeks of internship. The criteria were not perfect— I just made up my own form based on what I think is important. I asked people to rate the following skills/qualities on a scale of 1 - 5: design skills, collaboration, professionalism, leadership, efficiency, personality, and overall ability. I also asked them to include an optional comment to tell me anything.
In the mid-term form, the only two criteria that gave me 2 and 3’s are design skill and leadership/initiative, so I focused more on improving these two areas in the second half of the internship. I adopted the approaches that I mentioned above and more. At the end of my internship, I was very happy to receive no 2 or 3’s in the final evaluation form. Of course, the most valuable part of these forms is the comment area. I was able to see what I did well on so I can keep doing them, and also know what I can do differently or pay attention to in the future.
I am extremely grateful to everyone at ZapLabs for making my first legit internship so fun and rewarding. Thanks to my mentor Jules Cheung for being patient with me and teaching me so much, to my design team for all the help, support, lunch hangouts, and escape room trip, to my fellow interns for making it a fun experience, and to everyone there for providing an active community to engage with. I really can’t ask for a better first experience with a design career and the tech industry ❤

