Episode #71: Generating and Testing Useful Design Ideas with Aram Stepanian

Aram Stepanian entered UX through a path that began in Armenia, included medical school and work in a COVID emergency room, and later moved through marketing, home improvement, and human-computer interaction. Across those changes, he kept returning to one aim: make people's everyday lives better.

A friend already working in design introduced him to UX and shared courses, including one from Georgia Tech. After finishing his medical degree, Aram moved to New York City for a master's degree in human-computer interaction at Pace University. An internship at Touch began in UX research because the young team needed a researcher. After graduation, he joined the company as its founding designer. He also teaches Pace students to use sound design practices rather than treating files and process as an afterthought.

What you'll learn

• How clinical listening transfers to user research and product discovery

• How a short timed workshop can generate, vote on, and narrow ideas

• Why real shipped products offer stronger references than presentation-focused galleries

• How customer outcomes and Jobs to Be Done help sort competing concepts

• Why fast experiments require a willingness to archive work that does not succeed

Listen before turning observations into solutions

Aram sees a direct connection between medicine and UX. A doctor listens to a patient's story, gathers information, and forms hypotheses about what may be causing the problem. A designer listens to customers, interprets their stories, and turns the resulting insights into product hypotheses. In both settings, listening deeply comes before deciding what to build or do.

His startup routine reflects the range of product design. He checks Asana for sprint work and upcoming plans, then reviews Slack and email before stand-up. Depending on the day, he may move among research, interface design, business questions, and marketing. He enjoys working in Figma on components, design systems, screens, and visual details, but values product design because it sits between customer and business concerns.

That position creates a responsibility to define what comes next. A manager may not provide the next product idea. Designers must generate possible directions, explain why they matter, and gather evidence before asking a team to commit.

Generate broadly, then narrow with evidence

For ideation, Aram uses collaborative whiteboards such as FigJam. He describes a short session in which a team spends roughly three minutes generating as many ideas as possible, then gives each participant votes to identify the strongest options. In about 13 minutes, a large pool can narrow to one or two directions worth further attention.

Voting is not final validation. The selected concepts become hypotheses. The next step is research with customers to determine whether the assumptions may be true. This distinction keeps an energetic workshop from becoming a substitute for evidence. The exercise gives the team a manageable set of questions to test.

When facing a design challenge, Aram studies patterns in Mobbin because it shows solutions from real products. He is cautious about references from Pinterest or Dribbble when their emphasis is visual presentation rather than a working experience. A designer does not need to reinvent a familiar interaction. The more useful question is how an established pattern can be adapted to the current user's needs and improved for the current context.

He also looks for ways to reduce the number of inputs a user must provide. Fewer required steps can improve the experience when the removed input does not carry necessary information. The rule is not minimalism for its own sake. It is a prompt to examine every demand the interface places on a person.

Judge ideas by the customer's outcome

Aram uses Jobs to Be Done to keep design centered on outcomes. A customer effectively hires a product to perform a task, so the designer should ask what the person will achieve by using it. Designing only to produce a design misses the point. Customer obsession means connecting screens and features to a result that matters outside the interface.

Fast iteration makes that reasoning testable. Aram suggests combining tools when a Figma prototype cannot convey enough of the actual experience. Moving a concept into a framework that behaves more like a working product can expose insights that static or limited interactions hide. The goal is not fidelity as status. It is enough realism to answer the current question.

Teams must also be willing to discontinue features. Aram points to Google's history of ending products as an example of not becoming attached simply because something was built. He struggled with that attachment early in his career, then learned to delete or archive work that did not appear likely to succeed. Fast iteration only reduces risk when stopping remains a real option.

Use curiosity without abandoning craft

Aram expects disciplined file practices, particularly from junior designers. Layers and elements should have meaningful names rather than default labels that make another person's work difficult to navigate. Speed does not excuse avoidable disorder, especially when design is collaborative or handed to development.

At the same time, he treats broad curiosity as a strength. Following questions into AI, engineering, and business has helped him understand developers, discuss what can be built, and estimate the implications of ideas. He advises new designers to ask people directly for feedback and advice. Some may not respond, but others will, and those conversations can create learning and professional relationships.

Listen to Episode #71 for Aram Stepanian's full discussion of listening, ideation, product patterns, experiments, and curiosity.