I have recently been feeling anxiety over beginning a design. I have been giving myself pressure to deliver something because my expectations are high. What if I end up designing against the guidelines? What if I spend too much time designing and then I have to redo everything? What if this is something that people will be disappointed by?
For context, in the project I’m working on, the engineering team has the backend mostly ready. They have been waiting on me to design the frontend which is pretty overwhelming and has caused a bit of paralysis on my part to design faster than I could. In a previous article, I talked about owning my design process and voicing out my perspective of where I see the design going and making a decision that isn’t just solely on the engineering team’s plans. In this article, I will be going over how I have been slowly overcoming my design paralysis when first starting a design. This means not letting any preconceived notions of what I expect a design to be and to create something, anything, to get my thinking in a tangible format, no matter how scrappy it is.
Design in small chunks
In general, designing in small chunks gathers more feedback, creating iterations to make the design better, ensures buy-in and involves more people which increases the impact your design makes because there is more visibility.
Despite the engineering team being ready to deploy on their end, they have been very patient with me to make sure that I learn everything I need to about the project and that we deliver a successful user experience.
With that expectation, I had been under the pressure to design everything, but after talking to my PM, I almost forgot my roots as a designer: to define the core user journey (workflows) and to design in small chunks (multiple iterations). Overall, this means designing parts of the experience and sharing them with the engineering team to make sure we are equally aligned in the goal of the experience and the feasibility of the design. This ensures that we are both collaborating at the same time instead of having them wait on me to deliver everything. If I didn’t communicate with my teammates, it can leave a lot of room for my part to design something “wrong” and leaves out the voices of others to give me feedback throughout the design process, which would allow me to correct on-the-go rather than at the end. I want to consider engineers feedback to make sure that I’m designing something feasible and that I provide the right details engineers can take without making them do guessing work.
Collaboration on all ends is crucial to developing a successful product and that means communicating early and often.
At work, everyone is very eager to help in any way they can and by showing them your work early in the process, it gets buy-in and with teammates, allows us to collaborate more effectively and efficiently because we can be on the same page.
Rough fidelity is your best friend
A lot of the initial anxiety is from assuming the worst. When you start making things tangible, it is easier for people to understand your design rationale and the small details can be worked on together. If you don’t deliver anything and let thoughts permeate in your head, it makes it harder to start and keeps people waiting in the dark to possibly make assumptions. Getting your thoughts onto a surface (I.e paper, Sketch) makes it easier to literally sort out and visualize your thoughts to start building out something.
My initial fear is that I don’t know what to design, but when I lay out my thoughts, I realize that I do know what to design and it was all about creating models to conceptualize my thoughts (i.e work flows, user journeys) without worrying about how they look, but how they work. This makes it easier to focus on the details when you have the big picture mapped out rather than thinking about everything in your head.
It feels like there pressure to design something “good” but the most important step is to get something tangible to move forward. In fact, when I was worried about designing work that was too high fidelity, but my manager ensured me that that was simply part of iteration. At Google, there is never such thing as “too high fidelity” and what that typically means is that you went in the wrong direction and need to pull back.
What is your focus on in relation to the design timeline versus engineering or PM’s timeline? Create something based on your process using your teammates timelines as a reference for goals and deadlines.
Fidelity can always be built on, but the different questions/thoughts that happen throughout different steps of the design process need to be realized in order to know which parts need to be focused on more than others. That’s when you decide where the fidelity goes rather than on everything. For example, in my project, the goal is to design a MVP, so I have to make sure I am designing the things that are possible based on the timeline, not the entire experience. With this in mind, my time is focusing on the core experience and core tools that achieve the goal, not tools that are simply “nice to haves” at the moment.