Some of the best advice I ever received was from Margret Schmidt, VP of Design and Research at Roku. I had just started managing a team of designers, and I was anxious to succeed. On a Zoom call, she told me to have designers design “mild to wild” (low effort to high effort), but to never forget the problems that you aim to solve—and solve them in each version. I still think of this every time I sit down to design. Being a product designer means working within constraints—tech, business, time, resources—while trying to make an impact. For all the product designers out there, especially those earlier on in their career paths, I wanted to share what a difference it made when I realized how making small iterative improvements over time really added up. 

More design isn’t better

I’ve worked in-house, at agencies, and freelanced, and up until a few years ago, the projects that were important to me were the projects that I could put in my portfolio: the big stuff, like a complete site refresh.

Then I took a product design role at a real estate tech company that was operationally heavy. I loved their brand and consumer-facing product, but they needed the most help on their internal tools. So that’s where I spent most of my design time.

The internal tools were a hub for everything: maintenance tickets, addresses, access information, scheduling, cleaning, and so on. My first instinct was to redesign the platform—make it sleek, sexy, and fun to use. I would spend my weekends designing a mobile experience and thinking of all the cool features we could add, like GPS tracking to manage the fleet of maintenance workers or an app. While some of these features were “nice-to-haves,” most of the designs didn’t solve the problems fast enough. I was learning that more design wasn’t necessarily better. To be impactful, I needed to thoroughly understand the pain points and the constraints, and then form my solutions based on that foundation.

‍
Listen to the pain points

One day I had a shadowing session with the operations team. We were looking at a poorly designed chart of tasks where the columns showed the dates and the rows showed who did the tasks. What was missing from the chart was the address of the property where the tasks needed to be done. Without the address, there was no easy way for them to know where to go. I wanted to redesign the whole thing: Create calendars, improve the hierarchy, and more. But I also knew that we could easily pull the address into this chart before I even opened Figma. With one engineer and in less than a day, we solved the problem. True, I wasn’t going to put that chart into my portfolio. But it didn’t matter—I improved someone’s experience. I did my job. That kept happening. Another example: When the maintenance team went to a property, they pulled up the maintenance ticket on their phone. The experience was not mobile friendly, and the first thing they needed was access instructions. But that information wasn’t on the ticket—it was buried in the platform. I wanted to redesign the whole experience to be mobile friendly, putting the access information at the top along with the address that linked out to Google maps. While I was designing that experience, an engineer sloppily linked the access code in a random place on the page. It didn’t look pretty, but the maintenance crew loved it. I learned a valuable lesson, again. Sometimes big impact comes in small wins.


Beware of  shiny objects

Fast forward to Altruist. I was a few months into my tenure, and this new project came my way: a global notifications center to surface Altruist’s most important events. I wanted to work on that. 

A notification center seemed like a pretty large task, however, and looking around, we didn’t have an equally large team. Remembering what I learned on the internal tools team from my previous company, I started with the pain points. I wanted to learn why advisors were asking for a notifications center, what their biggest frustrations were, and if we could solve them with fewer engineering and design resources. After doing some research and talking with our CPO, we learned that the biggest pain points were when accounts were being onboarded.

I put together our findings, organized it into a deck, and outlined the opportunities from low effort to large effort. Low effort was sending out emails when a few key events happened. Large effort was an in-app notification center. And then I added some medium effort ideas in between. We started with the low effort, and with the help of our PM and engineers, we were able to validate our approach through user interviews and launch three simple yet effective emails. 


Track success, even if it’s a small project

When possible, track success—even if it’s a small project. We ended up linking a Typeform survey at the bottom of each email to collect user feedback. We wanted to make sure we were making a positive impact. We received a few handfuls of PSAT (product satisfaction) scores for each email. They were mostly positive and validating, but more importantly, we also got constructive feedback. There’s always room to iterate.
‍
But what about the big stuff? 

The small wins are bites out of the proverbial elephant. They aren’t high-fives all around, “pencils down, we solved everything.” Most of the time they’ll need tweaks and iterations. I believe in designing products that people enjoy using, and sometimes that is a complete redesign. There’s a time and place for hacking together a solution, a quick design, and for visionary thinking.

Product design means working within constraints to make an impact. I encourage any designer to test the big stuff and think big, but also feel good about making an impact with small iterative improvements. Remember that you may be doing the best design that can be done for the task at hand—and that’s what matters.'



More on ethos