User Research Without Defending the Design with Janisa Simmons | Episode #67

Janisa Simmons began in graphic design, moved quickly into web design, and entered the field before UX design was a common label. As a webmaster at Georgetown University, she worked with HTML, CSS, and broadcast emails. A graduate certificate from the University of Baltimore and experience in her next role helped her recognize the larger discipline behind the work. Her responsibilities progressed from task flows and focus groups to deeper interaction design, edge cases, and introducing UX practices within organizations.

As Principal UX Designer at Seeq, Janisa works on an advanced analytics platform used by process engineers. She values direct contact with users because the software is part of their daily work. Her sessions give them a chance to interact with a design, explain pain points, and influence features before and after release. The conversation offers a practical view of UX as an ongoing cycle of understanding, prototyping, testing, delivery, and iteration.

What you'll learn

• How to keep a usability session focused on learning rather than selling a design

• Why realistic interactions can reveal issues that static screens may miss

• How Janisa moved a requested notification feature through research, prototypes, development, and iteration

• Why interface copy deserves attention as part of the complete user experience

• How practice, creative outlets, and UX communities can sustain professional growth

Design the complete workflow, not the obvious screen

Janisa illustrates end-to-end design through a notification feature for Seeq. Process engineers use the platform to monitor manufacturing equipment and conditions, such as a temperature rising above a specified threshold. The product could already visualize periods when a condition was met, but it did not yet send that information to the people who needed to act on it.

The word notification sounded simple, but the workflow was not. Janisa had to investigate what users wanted to monitor, how they expected to receive an alert, and how often it should arrive. She also considered the person creating the notification, an administrator with broader visibility, and a recipient who might be tagged without having access to the system. Each role created a different touchpoint and a different expectation.

Her process started with conversations, surveys, and interviews. She then presented lower-fidelity mockups and prototypes, gathered feedback, and worked closely with the product manager before handing the experience to developers. Feedback continued after development. The feature had been one of the most requested capabilities, but shipping it did not make the work complete. Janisa treats products as things that evolve as people use them in new ways and ask for further improvements.

For product and design teams, the lesson is to map every participant, permission state, delivery method, and follow-up action before assuming a familiar pattern is straightforward. A small interface element can carry a much larger service workflow.

Run research without defending the product

Janisa's central research advice is to separate yourself from the product. A usability session is not a sales presentation, and its purpose is not to persuade someone that the design works. The researcher needs to create enough comfort for participants to give candid feedback without worrying that they will offend the person who made the prototype.

That discipline becomes especially important when something breaks. If a participant reaches a bug or an unexpected path, Janisa advises against rushing in with directions or explaining how the design was supposed to work. Instead, ask what the person expected to happen and how they thought the interaction would behave. The failure can still produce valuable evidence about the user's mental model. Defending the prototype shifts attention back to the team and can erase the learning opportunity.

Her approach also provides a useful standard for critique. Feedback is not a personal judgment on the hours invested in a design. The work still has to solve a problem. Early-career designers can improve by practicing, studying, listening without taking feedback personally, and repeatedly iterating rather than waiting to produce something perfect.

Build the craft through tools, copy, and curiosity

For advanced interactive prototypes, Janisa prefers Justinmind because it supports robust behaviors without requiring a large collection of screens and layers. She uses Figma for quick concepts and collaborative work, then may move a complex project into Justinmind. Mural, Slack, and Confluence support workshops, communication, and shared context. The broader principle is to choose the tool based on the fidelity and collaboration the work requires.

She applies the same care to interface copy. Earlier in her career, an editorial team handled language consistency, and she once viewed copy as something another person could simply provide. A manager challenged that assumption. Janisa now pays close attention to instructions, labels, and distinctions as small as whether a button says okay or done. Those words affect comprehension and how the experience feels.

Janisa is interested in AI and GPT-based assistants, but she warns against adopting a fashionable solution before identifying the user problem. To keep learning, she follows UX leaders including Jared Spool and Michael Locke. She also maintains creative outlets through clarinet, painting, dance, theater, church volunteering, and community involvement. Her example makes professional growth concrete: practice the craft, stay connected to people who challenge your thinking, and make room for creativity beyond the current project.

Listen to Episode #67