I joined a silicon valley tech company’s first program as one of their first designers

Photo by Josh Calabrese on Unsplash

I was Evergent Inc.’s introduction to , thinking, and research along with another intern. Evergent, a cloud-based B2B user lifecycle management platform, only recently began integrating into their company, so while their product is comprehensive and extensive, most of the energy at the company had been invested in improving the back-end and expanding visibility, not on their product’s interface or experience.

As the first design interns at Evergent, we had six weeks to develop a research plan, redesign significant parts of their product, and test the designs. The structure of the internship allowed us freedom and flexibility in conducting our research, preventing the usual red tape from interfering.

Because of this, I had a lot of control over developing the research plan.

The argument for personas:

Depending on the design project, the benefits of personas may vary, but my experience demonstrated that the value in personas can be found beyond the persona itself — in the process of creating them. Personas can also be useful in designing wholistic interfaces and making it easier to communicate and advocate design choices.

My company wanted us to develop persona’s, a task that requires a substantial amount of time and energy. In my design courses, I’d studied how to develop persona’s, why we make them, and how they’ve been used in previous design projects. But as someone conducting design research professionally for the first time, I wanted to make sure our very limited time was well invested. So before developing our personas for the redesign, I questioned how important personas are in design.

Are they primarily for us as designers? Or are they more a tool to explain designs to the stakeholders?

After a series of research and design presentations, I saw that our persona’s proved to be a useful tool in explaining our designs. It allowed the executive team to align with the user emotionally while understanding the logical points that our redesign is tackling.

Developing the personas also forced us to consider various aspects of the user’s life into the design. Our user spends a lot of time on a certain social media platform? Maybe an interface that is difficult to learn can be designed to mimic that platform for improved learnability. Our user spends a lot of time working with people in different countries? Maybe we can rethink the time display.

But more than that, I found that even if we never referred back to the personas, the process of developing them was instrumental in identifying our user characteristics and what we needed to change, keep, and rethink on the new interface. We conducted user interviews to gather a wide variety and extensive amount of information about our users, and the process of creating the personas was an effective and efficient exercise in processing and consolidating the information from our interviews.

Why interview when you could just send out a survey?

I found that the purpose of an interview isn’t to survey people, it’s to develop better questions and gain insight into the product.

We always want consistency in user interviews, but sticking to an ordered list of questions usually isn’t going to elicit the most valuable information. If that was the case, you might as well send out a survey to cut the time and energy it takes to conduct an interview.

The purpose of having survey questions in an interview is that you get to use the questions as a prompt to jumpstart a conversation with your users. The conversation should raise and answer new questions you hadn’t thought about before, and provide unique insights. With every interview should come new, preferably actionable insights.

Interviewing people is also more memorable. We had sent out surveys to the people we couldn’t reach and interviewed the people we could, and even though we had many more people respond to the survey than we interviewed, the results from the interviews held most of the weight in our research. People elaborated more in their answers, raised new questions, and had more varied answers, and that’s because we’re establishing a relationship when we have a conversation. Talking face-to-face, people are more inclined to help provide the most impactful answers because they feel that they are also making a contribution to this project.

Your results should primarily be based on the test subjects actions, not opinions

When we presented the research behind our designs to the executive team, my design partner discussed how he asked “her opinion on the x function and his opinion on the y design.” Opinion oriented research is okay when it’s only a minor component of the research because it can show us public perception. But it’s not effective for developing the best UX.

When Instagram first implemented Instagram Stories, public perception was underwhelming. When Facebook first implemented timeline ages ago, people weren’t having it. Eventually, people’s affinity to these design decisions changed — now tons of people use Instagram stories and nobody has complained about timeline in years.

Henry Ford is attributed to the quote: “If I had asked people what they wanted, they would have said faster horses.” There is a difference between user attitudes and user experience. If you weigh a test subjects opinions too heavily when redesigning an interface, it could just lead to a faster horse when you could have gotten a car.

This brings me to my second point:

Be vocal and assertive when you don’t agree with the research

I should have been more assertive when I saw how my design partner was conducting his research. Too much of his research and design changes were based on people’s opinions, and not actions that he’d observed. Fortunately, none of my user testing was opinion based so when we presented our research, we had sufficient concrete data.

I didn’t push hard enough because I wasn’t his boss, I was his colleague. When I told him to create a task-based user test, he said he would, but he didn’t. When I asked him to get a variety of perspectives from people in the office, he said ‘okay,’ but he didn’t. Our final design presentation was strong, but only because I finally pushed for the required action. So although our presentation was strong, it wasn’t as strong as it could have been because I acted too content and resigned with the way it played out rather than being assertive.

Instead of telling him “you should,” I should have said, “do it now.” Being his colleague doesn’t make it okay to settle for subpar work.

Your research could identify UX issues that you won’t be able to solve, but it’s worth addressing them

While the design internship was only six weeks, the company’s product had been developed without a concrete design team for ten years. Because of this, our research uncovered a lot more issues to tackle than we had time for. I spent the last week of the internship clearly defining these issues and how we found them and provided design suggestions for the company to tackle in the future.

I don’t know how the company plans on using these findings, but they are in the process of developing a design team. By presenting these findings and our design suggestions, we were able to make an impact that lasts longer than our time at the company. We were able to illustrate the gravity of design at a tech company and illustrate how design research can touch a wide variety of issues within the company. Don’t limit your research by asking questions that are too focused. Sprinkle in broad, general questions to undertake through your research because the results from these will add unexpected value to the current project while providing insight into other areas that the company could be working on.



Source link https://blog.prototypr.io/what-i--from-my-first-uiux-design-internship-3141ce01632c?source=rss—-eb297ea1161a—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here