UX is Grounded in Rationale, not Design

During the past few weeks of my internship, I felt stuck and unmotivated. I didn’t know what I should be doing or if the work I was doing was worth the time I put in. How could I make the most of my time? I only have 12 weeks was the thought I prioritized over everything else. I felt so pressured by time to make something as fast as possible that I didn’t take time to let the learnings surrounding my project and the company sink in, and how I could use them to give me direction on my project. Thankfully, my manager, J.B. Chaykowsky, saw that I was struggling and suggested I synthesize everything I had learned so far. We were able to break down my learnings and start distilling them into constraints or “truths” surrounding the problem I am currently trying to solve. This experience has changed my mindset of how I approach design and my process.

When you frame the problem, it allows you to see the big picture of different directions you can take with your approach and evaluate your design with principles

An article Dan Brown wrote about practical design discoveryreally resonated with what my manager was trying to help me do. This was to frame the problem and take a design direction which would help me see a big picture of the what, who and how of the problem vs only seeing the granular details of how a design (aka a solution) would look like.

You don’t want to start drawing concepts too early

During the few weeks of my internship, I focused my time on sketching and making. How could I sketch solutions without understanding the current issues my user was facing, let alone the main problem I was trying to solve? Though I did do research surrounding the problem, looking at previous insights from users and such, I did not have concrete knowledge to back up my explorations and whether my solution would work or not.

Research is super important, but synthesizing that information to come up with new opportunities is even more valuable than making products look good or building something which already exists. It also opens up the opportunity to give perspective to other designers working a team and allow them to leverage what they are working on to solve bigger issues aside from a specific solution.

Use sketching as a way to think, but don’t sketch out solutions too early if you don’t understand the problem

Sketching out things is great as it allows you to visualize and conceptualize something, but don’t sketch solutions without understanding of problem. You will end up boxing in your thought process too early if you do that. Though some places may say that sketching in the beginning is good, you could be using your time to distill information and create a solid framework of the work you are trying to do.

Rationalize instead of inputting (don’t be brain dumped on)

connectivedx

I have been talking to a lot of people and writing down everything I learned so far, but writing isn’t the same as understanding. I was not using that information to generate understanding about the problem, but instead wrote it down in hopes of understanding it later.

Without building a rationale behind the problem, my reasoning behind my design decisions would end up being part of a non-existing framework I didn’t have to support them. The things I built wouldn’t be as effective if I had just focused on making sense of my research in the beginning.

I needed to shift my emphasis from making to synthesizing and using data I learned to build understanding and a solid framework where my decisions would make sense.

Before building, you need to build a good foundation. This would potentially lead you to building the right thing instead of something that isn’t relevant or has already been done before. I started synthesizing information based on previous work (work I did or what the company had done), current work (the project I am working on), questions and user research. This allowed me to lay down everything visually and provide more clarity on framing the problem.

Rationalizing everything made me realize I couldn’t just start designing without knowing the scope of what I was trying to do. I needed to go broad and focus before going narrow. There is potential to solve a part of problem other people hadn’t been focusing on and to prevent repeating the same steps other designers have done if they did something similar to what I am doing.

Engage in the problem

Akhil Chugh

If you spend time synthesizing information, you can reframe the problem in ways you couldn’t have done if you start doing concepts already. Engaging in the problem will help build a better rationale which will allow you to understand the problem better. To get people to understand your design, you need to have solid rationale about the things you say. This means backing up your design decisions with customer insights and/or data.

If you can’t connect your work to reality, you are essentially wasting time

Dan Brown broke down three ways to create a direction for your designs that will help you break down a problem. These are constraints which allow you to rationalize your thinking and describe your design decisions:

Principles define what the design should or shouldn’t do. These statements are grounded in research, and may be referred to as implications when you can tie them to research.

Concepts establish an overall approach for the product, expressed as a central theme or idea.

Models describe the product in an abstract way, showing the underlying architecture, structure, flow, or approach. They offer a sense of how the product will work (without actual functionality)

Taking the time understand the problem by synthesizing data will allow you create constraints and frameworks while meeting your objectives. Constraints make your design scalable and frameworks make your design feasible (what should the design do vs won’t do) This will lead you to focus more, allowing you to think differently and to give you direction on how to practically approach a problem .

Do you really understand the problem?

When I talk to my co-worker, Vera, about my designs, she will always ask me to provide an example or use case surrounding it. There are times when I can’t do this and this is bad. I have been listening about the problem mainly through her and looking at existing data that I haven’t been able to provide specific use cases to back up my ideas.

If you can’t give a concrete example, then you probably don’t have a clear understanding of the problem. Because we are on the same team, my co-worker might have an understanding about what I am trying to explain to her, but if I try to explain my idea to someone else without any example or rationale behind it, they won’t get it. In fact, this is how amazing ideas can die on the spot because you couldn’t explain it clearly or thoughtfully.

You can’t relying on an abstract or metaphor when describing your design. You need to tell a story with a solid framework your design is based off of.

In a company setting, you need to be able to explain to people, especially higher ups, about the project you are working on and how it is going to help their customers. This means providing concrete examples backed with data or customer insights. They are going to be seeing your work for the first time and you want to make sure they understand everything you did, especially because you spent a lot of time on developing your logic and design. Essentially you need to explain 3 months worth of work in 5-10 minutes.

In UX design, it is crucial to have an understanding of who you are designing for in order to really understand their pain and then come up with solutions that will help alleviate it. Otherwise, you are wasting your time coming up with solutions that won’t be beneficial for you, the company and your customers.

Closing Thoughts

The reason why I felt “unproductive” was because I wasn’t taking the time to understand my users or the problem I was given to solve. I haven’t empathized deeply with what my users go through. This made me realize how hard it was to develop empathy for others when you don’t have a first-hand experience of the problem.

In order to develop empathy, you have to go through what your users to go through to really understand their pains.

I had been learning a lot about my project, as well as talking to many people, but I wasn’t distilling any of that information into something actionable. Instead, I started to get stuck in a plethora of different information, letting myself get stuck in analysis paralysis because I wasn’t connecting that information to how it was going to help me move forward.

Embrace what you don’t know, especially in the beginning because what you don’t know can become your greatest asset. It ensures that you will absolutely be doing things different from everybody else (Sara Blakely)

It’s okay to be stuck in ambiguity or if you aren’t too sure what to do. When in doubt, take the time to process everything you have learned so far and create constraints that will allow you to focus on what is really important and build frameworks to understand the problem. Don’t make design decisions early in your process without knowing what you are trying to design, who you are designing for and how are you going to get there.