Episode #42: Moving Fast Without Losing Design Detail with Yonas Berisa

Speed can help a product team learn, but fast design loses value when the problem is unclear, implementation details go missing, or work ships without testing. In Episode #42, product designer Yonas Berisa explains how his path through logo design, sales, and self-directed learning shaped a collaborative process for moving from a brief to development.

What you'll learn

• How sales and presentation experience can strengthen product design work

• Why a project brief should define the problem and desired business outcome

• How design jams, wireframes, iteration, and developer reviews fit together

• What makes handoffs smoother when designers and developers build a working rhythm

• How to balance fast output with attention to detail and testing

Turn an unconventional background into practical skills

Berisa's interest in product design began in 2016 after he watched a Y Combinator startup pitch on YouTube and became interested in the interface shown on screen. He was studying business marketing and designing logos on the side. Searching for product design led him to Behance case studies, then to experimenting with Photoshop and Sketch before he understood design systems or established rules.

His early client work included simple logos for small businesses through Upwork and logos for university engineering projects. He also sold channel lettering to businesses and worked in door-to-door sales. Although those jobs were not product design roles, they developed skills he later used with designers, developers, and journey teams. Sales taught him to present in front of people, explain an idea, and negotiate when a proposed design could not be implemented exactly as planned.

The lesson for aspiring designers is not that one background guarantees entry into the field. It is that adjacent experience can become useful when connected to the work. Client conversations can support research and collaboration. Sales can improve presentations. Negotiation can help a team preserve the purpose of a design while changing its implementation.

Start with the problem and the outcome

At Asurion, Berisa worked within a cross-functional journey team that included product management, development, and design. The company handled protection and repair experiences for powered devices and worked with clients whose products had different requirements while still using Asurion's design system.

When turning specifications into designs, his team first checked whether the flow made sense from screen to screen. A project brief then clarified the problem, the proposed direction, and the business outcome for the work. The product manager prepared the brief, and the team reviewed it before moving deeper into design.

That sequence matters because a polished interface cannot repair an undefined problem. A clear brief gives a design jam something specific to explore and gives later reviews a standard for judging alternatives. The team can ask whether a design addresses the agreed problem and outcome rather than choosing only by visual preference.

Use collaboration before and after detailed design

Berisa described brainstorming and design jamming with another designer to produce several ideas and gather inspiration. For a completely new screen or project, the process could include wireframes before detailed product design. He often created multiple options, brought them to his design team, and continued with the direction the group selected.

Iteration did not end when the interface looked complete. Before handoff, designers reviewed the work with developers to confirm that the proposed implementation was feasible. If developers could support it, the design moved to a ready-for-development state. If not, Berisa's negotiation experience helped the group discuss adjustments instead of treating the design as fixed.

This process distributes important questions across stages. Early collaboration expands the available ideas. Wireframes help examine structure before investing in detail. Design reviews refine the direction. Developer reviews expose implementation constraints before work enters the build queue.

Build a handoff rhythm without ignoring detail

A handoff can be difficult the first time a designer works with a new development team because neither side knows the other's communication style. Berisa found that the process became easier once the group established a rhythm. The team used comments in Figma and direct messages for follow-up. When he changed a design, he left a dated note describing the specific updates. That record helped developers understand what moved and when.

Berisa also identified a tension in his own working style. Early in his career, he moved quickly through entire projects but sometimes missed details. Speed remained a strength because it helped designs get out and ship quickly, yet he recognized that shipping without testing creates another problem. Fast output therefore needs a review loop: document changes, check feasibility, examine details, and test what ships.

Listen to Episode #42 for Yonas Berisa's full account of entering product design, applying sales skills, collaborating across a journey team, and learning to pair speed with stronger design discipline.