Raising UX maturity in an engineer dominated tech startup as an intern
A Journey of a young solo UI/UX design pioneer
This is the story of how I survived and strived in a tech-savvy startup as the pioneer UX designer under the title of an intern.
If you are also struggling in a difficult situation, working as an intern but with the ambition to raise the UX maturity of the company and create good user experiences for the users. You are definitely not alone.
I believe this is the journey that many people have been through as the first UX professional in the company. I did complain about how messy and chaotic it is at the very beginning of my internship; there is so much to do and consider that you don’t even know where to start.
As an intern (a naive student), I assumed that my fellow colleagues would know better about how things should work and provide the assistance I need whenever I need them. Unfortunately, that is not the reality.
The reality is that it’s a start-up with low UX maturity, therefore we have to figure this out together with the company, or at least they are expecting you to figure this out for them.
I felt the heavy weight just fell on my shoulders because I felt that I need to prove to them that our belief, the theory of HCD, works. And in order to make that happen, I have to be the expert myself to show them the magic and science behind the magic.
The good thing is that the experience is guaranteed to be rich, whether it is a good one or a bad one.
The company is a high-tech engineering software development start-up based in Germany. The company has offices across the globe, which makes it culturally diverse and international. However, a huge amount of the employees in the company are engineers with different specialties. The company is ruled by engineers; the salesmen, the product manager, and all C-level managers are with an engineering background. Not really diverse professional-wise, I would say.
According to the NN/g website, the company was only at stage 2: The Developer Centered User Experience stage when I first started there. I was the first and only UX specialist they’ve ever hired.
Before that, the company relied on the developer’s opinions to build the user interface and it turns out to be a disaster; even the employees of the company think that the product was hideous to use.
User feedback was collected by sales or field application engineers, who have “direct contact” with the user (=not the real user input); no proper usability test or any sort of testing was conducted to observe the user interaction from an objective perspective.
Without any deeper analysis of the purposes and needs behind those marketing requirements, the company only fixed the problem on a surface level and move on. It results in new problems that continually added up to other unsolved problems of the product, which makes the whole user flow even more confusing.
The company has aware of the issue that the product is lacking usability and good user experience because the customers keep complaining about it, and that’s where I came into the picture.
Nonetheless, one UX intern might be helpful yet not necessarily solve all the problems they have in terms of UX.
The product is a specialized tool that allows engineers to design FPGA chips with an easier software language. The context of the product is completely out of my field knowledge and that was also the reason why I choose to work in this company. I would love a good challenge and wanted to prove that I can tackle it with solely UX methodology.
They claimed that the product is so complicated that even an FPGA expert needs to spend some time understanding it.
But actually, I think it is still a tool providing relevant information at the right time regardless how complicated the backend would be. Human-centered design is always about “human”.
Step 0: Re-Organize
I was allocated under the GUI team when I joined the company. The first task they assigned to me was to re-design the unusable graph filter without giving me the context or too much information related to the topic because they didn’t want to limit my “creativity”. They would just implement whatever I design without any user input or even discussion about the approach at all, and that was just strange…
Shouldn’t the engineering guys come after? Shouldn’t the prototype and usability test comes before the engineers take over? Then why am I here on the engineering team? What is the context of use anyway? What is our persona?…
My first mentor was a GUI developer and he doesn’t really have the bigger picture of what I was always asking to know, instead, he often provides some technical details that I believe weren’t really relevant to my scope of work. We had some conflicts about how we should work and the task deployment, but the real issue was: I was assigned to the wrong team and we were doing things in the wrong way!
Then I realized that even though they have some ideas about hiring a UX specialist, they didn’t seem to have the knowledge about Human-Centered Design and what a UX designer actually does. So I called a meeting and had a brief introduction about HCD and how a UX team should occupy the head of engineering and the product owner. I quickly diagnosed the company’s UX maturity level (with the rule of thumb) and the importance and benefit of using the HCD approach. I wanted to let them know that UX is not just a buzzword, instead, it’s a concept of including user input in the process and it requires the organization to stick to the concept in order to maximize the effect. There are also a lot of methods to choose from depending on the context and other requirements and it is normally teamwork so that people can brainstorm on the topic… I was hoping that this instant injection of the HCD knowledge would make things easier for me to work properly, and it did.
In the end, they re-arranged my department with the product team and I started to work closely with the product manager and finally got all the resources I need in terms of the context.
We all know that user research is crucial to UX design, however, the struggle they have is that we actually don’t have many customers in hand due to the fact that we are a start-up that sells an expensive innovative product. The company doesn’t want to give the customers a bad impression that our product is not ready or unfinished by conducting usability tests with them; we can’t risk losing any one of them. In my past experience in the university project, having 5 participants has always been the golden rule or at least 3 participants. Who would have thought that in reality, even having one real user willing to spend 1 to 2 hours participating in the test is considered kindness to us. What I didn’t think about was that in the real world, people won’t be satisfied by free pizza or beer. Time is money; as we ask our users to spend 1 hour to do the test, they are losing 1 hour of effort of that engineer. It is not their duty to make our product better.
Nonetheless, I still strived to get two real users to participate in the usability test in the end. One is from a Belgium company that is friendly to us and the other one is the “hard to please” Japanese customer, plus one FAE as the pilot test. I was pretty excited about the fact that we are finally doing a usability test and this is what I am familiar with.
As I started planning the test, there were a lot of things to be considered. First of all, I still do not fully understand our product since it is indeed a complicated one. I couldn’t plan nor conduct the interview all alone; I need some technical support from the Product Owner, who knows the product like the back of his hand. I quickly formatted the interview guideline, however, the problem was that even though I was the moderator of the test, I didn’t design the tasks since it was too technical for me and I also didn’t understand what the participant was talking about. It is very important to be the expert on the product before conducting the test. If I get to do it again, I will instruct PO to be the main moderator and just participate as a note-taker and observer.
Anyways, the feedback that we collected from the pilot test and the first user test was very valuable to the company. Even though I couldn’t see the depth of the impact at that time, other stakeholders all said that it was a piece of eye-opening information and they appreciated my effort. Based on the experience I have from the first two testing sessions, the next one was even more challenging; the Japanese user.
In order to get the most authentic feedback, the participant should be able to speak the language that they feel comfortable with. This time, I decided to ask our Japanese FAEs to do the usability test for me. I documented the interview guideline in finer detail, and I called several meetings with the Japanese FAEs to make sure that they can conduct the testing session on their own. The most important thing was to collect the data, regardless of the language, we’ll figure out how to decode them in the future, that’s what I thought. The Japanese usability test was a success, however, I’ve never bothered to actually go through all the detail from it. The language barrier is not just something that one can easily overcome.
Documentation and analysis
Once we have the result of the usability test, I started to write a very detailed test report. However, with the knowledge I had at the time, the conclusion may be overly shallow; the conclusion of bad usability was too obvious that anyone can point it out without real user input. Anyway, as we move on to the next step, the unfinished documentation was buried with other unfinished plans I had, for example, a user research panel that allows us to always have participants from potential user groups to do the testing. Then I realized that this is just the norm of a start-up. There is always too much to do and too many good ideas to try out but too little time to fulfill them all. There is not yet a systematic way to make everything organized since we are still learning and exploring possibilities all the time.
Prototyping & Verifying
After collecting information from different stakeholders with different aspects, I started to have some ideas about what our tool is actually about and sorted out a rough user flow. Then I decided to just sketch out something quickly and verify it with the stakeholders or user testing. It was first the user flow and then the paper prototype. I verified my idea multiple times with different stakeholders but unfortunately, they didn’t understand the idea of the paper prototype, because the fidelity was too low. Then I digitalize everything by taking pictures of the paper prototype and making them into clickable slides (low-fidelity interactive prototype).
The prototype got many positive feedbacks which allowed me to continue refining the flow, the fidelity of the prototype, and other details. I then created a high fidelity prototype using Adobe XD for the general flow of the tool. However, due to some internal issues, the project of migrating to Visual Studio Code has been paused for the moment, therefore I was assigned to design and refine the UX of the current Eclipse tool. It was a bit discouraging to me at that moment, but after all, it is still the same product just in a different form. As I create the prototype for the current product, I learned more about the complexity and technical details behind the surface and gain so much more insight while doing interviews with different employees of the company. Sometimes I would even ask people from the marketing team or interns to be my testing participants so that I can get insights from a completely new user. But I think the pity part is that we’ve never tried to recruit random participants to do the testing for our product.
In the end, I didn’t get the chance to actually finish the prototype for VSCode migration because it is never an easy task that you can just easily accomplish within 6 months or even one year. However, I believe I did have a huge impact on the company. They decided to hire a senior full-time UX specialist because they see the value in UX and are willing to put more resources into the field.
As a side note, a few months after I showed our CEO the prototype with a slightly cocky attitude, I told him that he should show my masterpiece to our investors and get funded, we got acquired by an industry giant company. I believe that I definitely contributed my part to this great success of the company, as the CEO was very excited when he showed the prototype in our all-hands meeting, telling people how much potential we have with our product and how exciting the future would be.