Snapshots of Designing for a SAAS Product

Why this problem space is intriguing to me

Learning a new vocabulary

I learned it the hard way that knowing what to look for, devising representative usability testing tasks, and asking spot on user interview questions, are only possible through the extra work of understanding the domain thoroughly, which is ultimately important in interpreting the users’ needs. The nuanced domain knowledge is needed to make leaps in insight. Back when I was teamed up with a PM to improve an existing product. She told me that she had scheduled some time to talk to a few potential customers she met at an industry conference. I went to work on planning the interviews and thought that 4–5 days would be enough to come up with a plan. Even though I have some understanding of the industry and the customers, it was insufficient for understanding the nuances of a complex problem space. The interviews didn’t go as well as I thought. I was struggling during the interviews to come up with good probing questions.

Besides acquiring new knowledge, I also like to jump in and start visualizing the things I just learned. As I’m now partnering and learning from our domain experts, I often sketch out a journey map or storyboard to better digest the information and understand what’s going on in the customer’s world. Learning by “doing.”

Figuring out specific patterns for specific scenarios

One of the challenges of designing enterprise-level platforms to me is the lack of patterns that work or don’t work in specific scenarios. You may find me often scratching my head over certain design details. A common design pattern that is usable anywhere else may not be applicable here because of a specific rule, the paradigm the legacy system runs, or a unique way of the users operating their businesses. But in my opinion, user interactions need to be clear, familiar, and straightforward, no matter what. Therefore, breaking down a workflow or digging deep into what’s going on behind the scenes are the things I often do. When I was working on the trip pricing table, I had to do a lot of math to test my design concepts to make sure they would fit the business logic.

Interactions should be simple and clear, but in many cases, the underlying logic is not. I find I am always reminding myself to be more thoughtful and not oversimplify things.

Finding ways to get user feedback organically

Usually, we get access to enterprise users via our customer success team. I’ll typically observe them as they play around with my prototypes, or while they use our products during their training sessions. Sometimes I won’t get access to the user research that I think is critical to the project — This means I have to figure out how to make justified design decisions through any means necessary (i.e. getting feedback from our customer success team, stakeholders, etc.)

However, when we were designing for the end-users who are the flyers, it was nearly impossible to get a hold of them and ask them to do a usability testing session with their busy schedules. Instead, I managed to get lots of insights from the people who are working for the end-users such as the brokers, salespeople from operator companies, or the assistant for the end-user.

Internal testing can be effective too, especially for the first few iterations of the design or for strictly testing usability, as long as the participants have no involvement in the development of the product.

Rolling with changes

Lastly, just like any other startups, teams shuffle and priorities shift fast. I’ve had times where new ideas quickly replaced old ones in the current roadmap, where the strategy can change abruptly. What was once a priority became completely irrelevant, and I’ve had to roll with the punches. Despite working hard on a project, I’ve learned to be prepared in times where I’ll need to start again from scratch. When this happens, try to find joy in starting something new and make it better than before.