Spotlight Archives - Page 7 of 9

A Q&A with Functional Prototypes Expert Jacob Turetsky

Spotlight articles shine a light on designers we admire, asking leaders in the field about their work and their design journey. This month’s Spotlight focuses on Functional Prototypes, the working, testing, problem-revealing models that turn ideas into something you can actually use. Functional prototypes rarely look polished. In fact, they often look wrong. But for Jacob Turetsky, that’s exactly the point. In this Spotlight interview, Jacob reflects on why functional prototypes matter, how they shape better products, and why failure when designed intentionally can be the most valuable outcome of all. In this conversation, he shares his process, his philosophy, and why functional prototypes are the backbone of meaningful product development.

Q:

Can you describe a moment when functional prototypes failed so clearly that it completely changed the direction of a project?

A:

While working at a large ergonomics-focused product company, we were developing a stacking chair that included a subtle amount of active recline. The idea was to rely on the frame of the chair itself to create that movement, without adding a complex mechanism.

I quickly built a prototype using CNC plywood panels to mimic a kind of spring action happening in the lower corner of the chair leg. Structurally, it made sense. But no matter what we did, every time someone leaned back, it would pull their shirt out of their pants if it was tucked in.

It turns out that recline needs to happen as close as possible to the human hip, which is difficult because that’s exactly where your body is already sitting. Our pivot point was dramatically far from where it needed to be. Even though it worked from a construction standpoint, it completely failed ergonomically.

That prototype forced us to abandon the idea of relying solely on the frame. We moved to more complicated mechanisms that brought the action closer to the body. We built another prototype that had a cluster of potential pivot points in the right region, full of holes and adjustable pins. We could move things a quarter inch at a time and test them with people.

It didn’t look like a finished product at all. It was messy and riddled with holes. But only after that process could we move forward and actually design the chair.

Q:

For readers who may not be familiar with the term, how do you define a functional prototype? What separates it from a model or visual mockup?

A:

To me, a functional prototype is about answering the riskiest questions as early as possible—when those questions are still cheap and easy to fix.

Every design has assumptions. A functional prototype lets you isolate those assumptions and test them before you layer on additional detail. It’s not about surface or appearance yet.

You’re looking at how components relate to each other, how the user interacts with the system, and whether the overall architecture works. Drawings and visual models can only take you so far. When you need to know how something actually feels, moves, or behaves, you have to build it.

Q:

Why are functional prototypes so critical, especially in hardware, wearables, and integrated systems?

A:

Design is hard. And the design process really demands that we get answers to the riskiest questions early.

Functional prototypes allow you to test assumptions when it’s still okay to pivot—when changes don’t feel like mistakes or failures. You’re able to ask, “What are we testing right now?” and “How many versions should we build?” before committing to anything expensive or overly refined.

That’s what functional prototyping is about for me. It’s figuring out how things relate—between components, between the product and the user—before worrying about how it looks.

Q:

What makes functional prototypes successful?

A:

The most important question is whether it gave you the answer you needed.

A successful functional prototype is very well scoped. If something isn’t being tested, it should be over-engineered so it doesn’t interfere with the result. You don’t want flex or instability in one area creating a “mushy” feeling somewhere else and confusing the outcome.

I actually think one of the most boring outcomes is when a prototype works exactly as expected and doesn’t reveal anything new. A good prototype should teach you something—ideally something unexpected.

Q:

You’ve worked across design engineering, product development, and hands-on prototyping. What first drew you toward making things work in the real world?

A:

It’s hard for me to point to one specific moment. It really feels like a chain of experiences mixed with some luck.

I grew up building things and tinkering. Early on, I wanted to be a car designer, which led me to industrial design and then to furniture. I had a furniture internship that went badly—I had a severe allergic reaction to exotic wood and realized I didn’t want to be milling cabinets every day.

At the same time, I was working on a medical design project at Pratt, and that completely shifted my perspective. I loved the process of taking an idea, pinning it up, building on someone else’s thinking, and then making something that actually assembled and functioned.

Suddenly, we were creating things that had never existed before. That was far more interesting to me than just building objects. I still build things with my hands, but now it’s more of a hobby. What really captured me was thinking through how mechanisms work and why one approach works better than another.

Q:

Looking back, what experience most shaped your approach to prototyping?

A:

Early on, I learned that designing a prototype is often separate from designing the final product.

Sometimes you need a prototype that’s adjustable. You need to test different lengths, pivot points, or ranges of motion. In environments where the work is mission-critical and function-first, prototyping becomes central to the design process because you can only learn so much from drawings or static models.

I remember working on a mobility device where everyone had different ideas about wheel placement and handlebar positions. We built a single, highly adjustable prototype using basic extrusions so we could test all of those ideas in one model.

That experience reinforced something I still believe strongly: functional prototypes don’t need to be beautiful, but they do need to be neat, intentional, and well thought through. In many ways, a functional prototype is its own design.

Q:

When starting a project, how do you go from an idea to a working prototype?

A:

I really trust the design process. I usually start by defining what I call the architecture of the product. That means stepping back from materials and finishes and asking more fundamental questions.

Is it vertical or horizontal? How do the components relate to each other and to the user? I try to answer the biggest questions first and then work inward, narrowing the scope as I go.

I’ve learned that trusting this process is far more reliable than waiting for a single stroke of genius. It’s also much more valuable to clients because it creates clarity early on.

Q:

You often work in environments where time is short and the stakes are high. How do you decide what “level of fidelity” is right for each stage of prototyping?

A:

A lot of it comes down to education. Some clients see a prototype that doesn’t work as a failure, so part of the job is framing prototyping as learning.

I always imagine being in the room when the prototype doesn’t work. If I’d feel embarrassed, then it’s too expensive or too high-fidelity for that stage. At that point, I’d rather rewind a week and build two cheaper versions.

Q:

How do you avoid perfecting things too early—or too late?

A:

It’s about knowing where you are in the process and what questions you’re supposed to be answering at that moment.

If your first prototype is machined out of aluminum, you’re in trouble. If it lights up and moves and does everything at once, you’ve gone too far. Early prototypes should be cheap, fast, and iterative.

Letting time, materials, and scope set boundaries is important. Those constraints help you avoid over-investing before you’ve learned what you need to learn.

Q:

You’ve collaborated with designers, engineers, and researchers. What makes a cross-disciplinary team successful when you’re building prototypes under real-world constraints?

A:

On cross-disciplinary teams, I often act as the hub. It’s important to let subject-matter experts focus on what they do best, but designers also need to advocate for the user.

You don’t need to become an expert in everything, but you do need to learn enough of each discipline’s language to collaborate effectively. Ultimately, the designer’s role is to fight for the human experience and make sure the system works for the person using it.

Q:

Looking ahead, what skills or mindsets will the next generation of prototypers need most?

A:

With tools like 3D printing, it’s very easy to add detail too early. You have to learn when to stop.

Print it. Test it. Move on. Don’t keep refining something in CAD just because you can. Earlier in my career, tools naturally limited how far you could go. Now you have to create those limits yourself.

Functional prototyping is about answering questions quickly—about getting things to work or not work as fast as possible. That mindset is more important than any single tool.

—

Check out the rest of our Spotlight series to hear more from leaders in the design industry. Sign up for our newsletter and follow us on Instagram and LinkedIn for design news, multi-media recommendations, and to learn more about product design and development!

Please reach out!

A Q&A with Technical Designer Ryu Tomita

Spotlight articles shine a light on designers we admire, asking leaders in the field about their work and their design journey. This month’s Spotlight turns to Technical Design — the quiet, intricate work that transforms ideas into products that actually perform. We sat down with Ryu Tomita, a former member of the Interwoven team and one of the most precise technical designers we’ve had the pleasure of working with.

Ryu’s career bridges industrial design, soft goods, wearables, and fashion, his strength lies in the details: how materials behave, how components integrate, and how thoughtful engineering elevates user experience. In this conversation, he reflects on his path, his process, and the craft behind technical design.

Q:

You’ve had a really dynamic career, spanning fashion, industrial design, soft goods, and wearables. What originally drew you into design, and what keeps you excited about it now?

A:

I’ve always just loved making things—assembling pieces, figuring out how they fit together, and then seeing something take shape from nothing. That’s really the common denominator across all those fields. You start with an idea you can’t fully see yet, and through the process you discover what it becomes. That moment when everything comes together is incredibly satisfying. That’s what pulled me into design in the first place, and it’s still what keeps me excited about the work today.

Q:

When you think back on your time at Interwoven—it’s been about four years now, which is wild—what are the projects or moments that really shaped you? What have you carried into your current career?

A:

Definitely HeroWear and working on the Apex. I had no idea what to expect because we were designing a product none of us had ever seen before, and we had almost no information in the beginning about what it should ultimately be. We had to research everything: going into warehouses, understanding what the end users were doing, what they needed, and how a solution might actually support them.

From there it was really just creating something step by step, little by little, and trusting the process—that if we kept working, we’d eventually land on the right product. Embracing that unknown, and not being afraid of it, was a huge learning experience for me.

***Ryu’s time at Interwoven taught him to design through ambiguity — a skill that continues to shape how he approaches complex technical challenges today.***

Q:

Do you still approach your work the same way today—observing the user, embracing the unknown, and figuring things out step-by-step?

A:

I don’t have as many opportunities now to do direct user observation, but yes—the mindset is still the same. Embracing the unknown and taking things one step at a time was such a valuable lesson, and it’s something I still rely on in my work today.

Q:

What’s one thing people often misunderstand about the work of a technical designer?

A:

People sometimes get caught up in the tiny details and forget that technical designers always have to hold the big picture. You have to step back and think about how everything will come together and what the overall goal is—not just where a piece of Velcro lands. Remembering that bigger vision is really important.

Q:

How would you define technical design for someone outside our industry? People don’t always understand how valuable it is or how it differs from concept design or styling.

A:

Honestly, it’s hard to define because so much of it happens in your head. But for me,

Q:

Why do you think technical design matters, especially in categories like wearables, medical devices, and soft goods?

A:

Everyday items require a lot of thought because people use them constantly. Even something simple—like a belt or a holster—needs a slight curve so it hugs the hips instead of sitting straight. Those small decisions make a big difference when something is worn daily. Technical design is what makes those details functional and comfortable in real life.

Q:

You’re known for being incredibly detail-oriented—something I always appreciated in your work ethic. How does that mindset translate into the work you do now compared to more conceptual work?

A:

Believe it or not, I’m not as detail-oriented as I used to be. Things move so fast here that I’ve had to learn to let go of some of the minutiae. But I still think details are incredibly important. In tailoring, for example—where the hem goes, how the fusible is shaped inside a sleeve—those choices really affect how the final garment looks and performs. Even when the big picture matters more, the details still play a role in shaping the outcome.

Q:

Do you have an example—without breaking any NDAs—of a project where the details really drove the success of the design, or where you had to let go of details?

A:

I do, actually. I’m looking at the sample right now. We were working on a pleated dress, and the director wanted it to fit closely around the hips. With individually pleated pieces, it’s much easier to sew everything straight. But if you add a small dart to each pleat, the dress hugs the body much better. It was more work for the seamstresses and definitely more tedious, but it made a noticeable difference in the final result.

Q:

When you start a new project with big technical unknowns, where do you begin? And how is that process different from the product-focused work you did at Interwoven?

A:

Fundamentally, it’s the same. You lay out all the pieces, look at the sketch, and try to understand the big picture first—how the shape forms, where you need more volume, how things come together. Then you work through the smaller issues as you see the prototype.

The difference now is scale. In fashion, I’m working on collections with 120–140 styles, split between two people, instead of a single deep-dive product. But the mindset is the same: start broad, then solve the details.

Q:

What kinds of fabrics or garment types do you prefer working with?

A:

Wovens. I’ve learned to appreciate them more. Knits can be easier because there’s less room for error, but I work with both.

Q:

Tell me about your iterative process. How do you move from prototype to final sample?

A:

We usually make an initial prototype in a comparable fabric—we almost never use muslin. We fit it, review it, and make adjustments. If there’s a major design change, we start over. If not, we refine it and then move into a final salesman sample.

Q:

How much of the pattern work do you handle, and how long does a garment take?

A:

I draft from start to finish. A simple dress with four or five panels might take two and a half to three hours. A jacket could take three-quarters of a day to a full day. It really depends on the style.

Understanding the hidden architecture of a product — whether a wearable or a tailored jacket — is where technical design becomes almost invisible, yet absolutely essential.

Q:

Most people don’t realize how much inner structure goes into a tailored garment. Can you walk us through that?

A:

I didn’t realize it either until I opened up a men’s jacket. There’s a lot inside: canvas, padded chest pieces, Heimo, shoulder pads to hold the shape, sleeve structuring, and fusible layers that add support.

The heaviest structure is on the upper body—chest and shoulders. Fusible can run through the whole front and usually across the back shoulder blade. Anywhere there’s a turned hem, you’ll often find fusible to hold the shape.

Q:

Is that construction similar between men’s and women’s garments?

A:

The sewing is similar, but the fit is completely different because of physiological differences—especially the bust. You have to alter patterns significantly to account for that.

Q:

Can you give an example of a small technical detail that makes a big impact?

A:

A two-piece sleeve. People don’t notice it, but it feels so much more natural because the sleeve can actually follow the bend of your arm. A one-piece sleeve is basically a tube—it doesn’t guide the arm forward in the same way.

Q:

What’s next for you? What are you exploring personally right now?

A:

I’ve been experimenting with denim washes at home—doing potassium permanganate treatments on my patio, which is probably dangerous but fun. There’s so much science behind wash techniques that I never knew. I’m not inventing a new wash, but I’m trying to create my own personality in how the denim wears and ages.

Q:

What advice would you give to young designers starting out in technical design?

A:

I’d say it’s important to keep one eye on the bigger picture while you’re deep in the details. You have to be able to zoom out and look at the whole garment or product, then zoom back in to solve the small problems. It took me a while to learn that balance, but having both perspectives is essential.

Q:

Last question: if you had to start all over again, would you still choose to be a designer?

A:

Yes, absolutely.

—

Please reach out!

A Q&A with Digital Design Expert Priyankaa Krishnan

Spotlight articles shine a light on designers we admire, asking leaders in the field about their work and their design journey. For this installment of our Spotlight series, we sat down with digital product designer and change-management leader Priyankaa Krishnan. Trained in product design and instructional design, Priyankaa now works on complex, internally-facing tools within the supply-chain organization at a large west coast based tech company—one known for building its own systems from the ground up. Her path from international student to designer and change leader is defined by curiosity, systems thinking, and a relentless focus on user adoption.

*Photo courtesy of Prinyankaa Krishnan*.

In this conversation with Interwoven founder Rebeccah Pailes-Friedman, Priyankaa shares how she weaves user insights into strategy, balances business priorities with human needs, and runs rigorous testing cycles that turn ideas into durable, real-world solutions. She also offers candid, actionable advice for emerging designers.

Priyankaa Krishnan is a program manager, and in her job she pairs digital product design with change management to launch and scale internal supply-chain tools. She earned a master’s in Industrial Design from Iowa State University, and is pursuing a PhD in Human–Computer Interaction at her alma mater. An international student turned design leader, she blends UX strategy, analytics-driven decision-making, and Prosci-informed change practices—translating BRDs into measurable outcomes and guiding cross-functional teams through rigorous testing (E2E, QA, SIT, UAT) so new processes become everyday habits.

Q:

Could you start by sharing a bit about your career path—how you found your way into digital product design and change management?

A:

I came to the U.S. as an international student, which meant a lot of my early choices were constrained by visas and timing. I studied product design at Iowa State and discovered I loved teaching, so I completed a graduate certificate in instructional design. That opened the door to my first role—building learning experiences and micro-learnings inside a large enterprise.

So many of my early decisions weren’t really choices. Because of my visa status, I often had to pick from whatever options were available and run with them, and that shaped me. The instructional design credential led to an offer for the job she currently holds. At the same time, I had an entry-level product design offer from Ford and was waiting to hear back from Sac State (California State University, Sacramento). I even asked the my interviewers for a week so I could wait on Sac State. On my mentor Ana Luz’s advice—“take the tech job!”—I accepted. I call myself an “accidental” instructional designer: I didn’t know the corporate toolset at first, but I learned by doing, practiced hard, and that’s how I landed and grew in the role.

Q:

So, what exactly is an instructional designer?

A:

An instructional designer builds learning experiences—often micro-learnings—for a learning management system, guiding people from not knowing to knowing. In corporate settings that also means unlearning and relearning. The courses I built focused on changes to systems, processes, people, and tools. That’s where “change management” comes in: when something changes, you have to educate people so they can adopt it. Early on, my job was to create courses, publish them to Cornerstone (our LMS), and track participation. But I kept wondering about the bigger picture: I can design beautiful courses because I’m a designer—but are people actually adopting the change, and to what purpose? Leadership was asking the same question.

A mentor at work, Mikki Lee, introduced me to Prosci and change management. I took the workshop, earned my certification, and transitioned from instructional designer to change manager. I came to see instructional design as a subset of change management. Knowledge is just one part of it; you also build awareness, gauge desire, develop knowledge, assess ability, and ensure reinforcement—from the top down and the bottom up—so adoption actually sticks.

While I was driving end-user adoption, I also became a critical part of designing the solution itself. I work in the supply-chain space with internal users, making sure our products are ready for customers while our systems, processes, and tools continually improve for employees. That only works if our teams stay current with the changes we’re designing for them.

Q:

You specialize in Design Thinking and UX strategy—how do you weave user insights into your process from the very beginning?

A:

In an established corporate environment, we don’t go hunting for problems—the business brings them to us through Business Requirements Documents (BRDs) that outline use cases and current pain points. In parallel, we run periodic audits of existing tools, collect in-product quick-feedback surveys, and use a “bug nub” (a small bug icon in the UI) so anyone can file bugs or request features. Because the ecosystem is mature, we’re usually redesigning or improving something rather than building from scratch; about once a year we do ship a completely new tool for a team and then manage onboarding.

When a BRD comes in, we map the pain points and triage them: what’s a nice-to-have vs. what’s P0. P0 means the business cannot function without it—if a P0 breaks, the business breaks—so we tackle those first.

From there, the design process is standard: we identify the stakeholders who submitted the requirements and run quick interviews to confirm the five W’s and H (who, what, when, where, why, how) and close any gaps. Then we publish a plan: the three things we will accomplish this half, clearly separating what must happen immediately to keep the business running from what belongs in the long-term roadmap.

Q:

When you’re working on change management, how do you balance business goals with the human experience of design?

A:

Change is tricky. When we roll out new ways of working, the business often resists—people are used to doing things one way, and we’re asking them to do it another. The most effective lever is top-down alignment. We take a proposed solution to leadership and, when it maps to organizational goals, secure a clear mandate. That makes the change mandatory, not optional, and leaders can communicate, “This change is coming and we need to adopt it.”

Not every rollout is mandatory, though. I distinguish between mandatory tools and reference tools (nice to use, not required). For reference tools, we run a “rally” approach: we visit teams during their regular meetings and give a focused 15-minute demo—“Here’s the tool; here’s exactly how it benefits your team.” Crucially, we aim to have the team’s manager deliver and reinforce the message. If the instruction comes from a manager, people do it; if I pop into a room and say, “Stop using this button, use that one,” it doesn’t land the same way. When the message comes from the business, via the right manager, adoption accelerates.

A recent example (kept high-level due to sensitivity): shifting government-driven costs have impacted pricing. We built a reference tool to visualize pricing changes, but some teams still rely on spreadsheets out of habit. In these cases, I partner with the group that’s accountable for those expenses and have them champion the tool to the affected teams—so they can answer to leadership with confidence and the organization gets consistent, accurate data.

All of this is deeply cross-functional. I sit between engineers and software developers, design, the business, and end users—coordinating requirements, aligning incentives, and making sure the right people carry the right messages at the right time.

Q:

What role does collaboration play, and how do you bring cross-functional teams into the process?

A:

It’s highly cross-functional—solution leads, engineers, analytics, QA, and business stakeholders. Honestly, it’s “a lot more talking than doing” at the start—on purpose. We align on use cases, metrics, and constraints before we build. Weekly feedback loops let us present options (never a blank page) and tradeoffs. I don’t ask, “What do you want to see?”—I bring two or three viable concepts and facilitate a decision.

Q:

In digital product design, how do you gather and interpret insights to keep a concept on track?

A:

Gathering insights: I lean strongly on analytics. Because we’re often improving existing systems rather than starting from scratch, we begin by measuring current performance and identifying gaps. We partner closely with our (very large) Analytics team.

From each Business Requirements Document (BRD) we produce two artifacts: (1) product development requirements, and (2) an analytics requirements spec. Working with solution leads for the supply chain, we define which metrics matter and the exact definitions for each (numerators/denominators, business rules, segments). All relevant event and system data is stored in a central data repository.

Analytics uses the spec to build dashboards that map gaps to requirements. They’ll literally chart, “this metric is low here, that one is high there,” against our targets. If the organization says the goal is 95%, and we’re at 87%, we run root-cause analysis using taxonomy slices (flow, geography, vendor, tool, milestone, etc.). For example, we might see in-transit delays spike and discover a missing milestone between a supplier and our system.

Q:

Physical product design leans on iterative prototyping. How do digital testing methods compare or complement that process?

A:

In our ecosystem, the UI kits and brand patterns reduce surface-level design decisions, so we can focus on solution design. For new tools, we still iterate: weekly reviews, side-by-side concepts, test environments, and structured test scripts. We run multiple layers before production: end-to-end team testing, QA, systems-integration testing (SIT) across upstream/downstream tools, and user acceptance testing (UAT). It’s iterative—just like physical prototyping—only the fidelity is software builds instead of foam and muslin.

Q:

Can you share an example where testing or validation revealed something surprising and shifted direction?

A:

We built a data-collection feature and tested single-record flows successfully—then discovered we hadn’t prepared the environment for multi-record scenarios. Everything failed, and we had to push the project by three months. Another time, notification settings weren’t validated in the dev environment; when we went to prod, thousands of emails failed over a weekend. Painful—but those misses made us tighten our checklists and guardrails.

Q:

What advice would you give designers who want to strengthen their testing and validation skills—digital, physical, or hybrid?

A:

Communicate early. Build awareness that change is coming and invite feedback while it still matters.

Detach your ego. Don’t treat the work like your baby—critique is data.

Timebox and prioritize. Fix the P0 issues immediately; queue lower-priority requests for later.

Make it real. Whether it’s a clickable prototype or a rough build, tangible artifacts unlock better conversations than slides.

Q:

Anything else you’d like to share with young designers getting started?

A:

Apply steadily—even 15 minutes a night. You never know who’s looking. And practice showing unfinished work. Confidence grows when you iterate in public, learn fast, and move on.

—

Please reach out!

A Q&A with User Researcher Amy Dexter

Spotlight articles shine a light on designers we admire, asking leaders in the field about their work and their design journey. User researcher Amy Dexter is featured in this edition of our Spotlight series, where we sat down to discuss her career spanning healthcare and consumer technology. From her early curiosity about how people interact with complex systems to leading research strategy for tech teams, Amy’s journey has been defined by exploration, adaptability, and a passion for bringing the user’s voice into product development. In this conversation with Interwoven’s Yukiko Naoi, Amy shares insights from her path into human factors and user research, her approach to testing and validation, and how AI is shaping the future of research practice. She answers twelve questions about her career, methodology, and perspective on user research.

Amy earned a master’s degree in mechanical engineering from Tufts University after completing a Bachelor of Science in mathematics and statistics at Austin Peay State University. Her career spans roles as a human factors specialist, customer insights and experiences strategist, and user researcher at Sonos, where she optimized user experience and product performance. Amy also worked in the healthcare sector, applying her expertise to improve patient care and medical device usability. She blends rigorous research methods with a deep understanding of human behavior, translating insights into actionable design strategies. Amy’s analytical mindset and passion for understanding people drive her approach to collaboration and innovation, whether working with teams or engaging directly with end users.

Q:

Can you briefly introduce yourself and share how you started your career in user research?

A:

I’ve always been a curious person interested in a wide range of fields, which made choosing a career path challenging. Before college, I spent time job shadowing professionals like a lawyer, an ultrasound technician, and a photographer to get a sense of what their daily work looked like. I interviewed them about what they enjoyed and what was difficult, which helped me think more deeply about different possibilities. In college, I continued to explore by taking courses in photography, medicine, education, and even considered becoming a therapist. Eventually, I chose to major in mathematics and statistics with a minor in photography, reflecting both my analytical and creative sides.

After college, I went to graduate school for mechanical engineering, thinking I wanted to understand how things work and how to make them work better. The turning point came when I volunteered for a research study focused on teamwork under stress. Participating in that study opened my eyes to how fascinating human behavior and team dynamics could be, especially in challenging environments. I realized I was more interested in how people interact with systems and technology than in the mechanics themselves.

That realization led me to human factors engineering and usability testing in medical devices, and eventually into user research in consumer technology. Throughout my journey, curiosity about people, systems, and the places where they meet has always driven me. Looking back, I see that my early career exploration and interviews were actually a form of user research, just focused on understanding my own needs at the time rather than others’. I never knew user research existed as a field, but my curiosity ultimately led me exactly where I was meant to be.

Q:

What do you love about your job?

A:

I support an ecosystem of designers, product managers, and engineers by leading research studies, building research infrastructure, and coaching teams on methodology. My role is a blend of hands-on research and research operations, which includes creating self-service tools, reviewing study protocols, and integrating AI into our workflow. What I love most about my work is being a voice for the user, especially in spaces where their needs are often overlooked or misunderstood. I enjoy surfacing the experiences of underrepresented groups, challenging internal assumptions, and making sure the team hears directly from real people. It’s rewarding to see how research can influence product decisions and ensure that what we build truly reflects the realities and priorities of the people we’re designing for.

Q:

Tell us a little about testing and validation – when do you do it, how do you do it and why do you do it?

A:

Testing and validation are ongoing processes that happen throughout product development, not just at one stage. Early on, I focus on understanding user needs and validating assumptions using methods like interviews, contextual inquiries, and surveys. As the product develops, I shift to testing concepts and interaction design, often through usability studies and prototype evaluations. Closer to launch, research becomes more formal, with structured usability testing to ensure the product performs well in real-world conditions and meets necessary standards, especially in regulated environments like healthcare.

How I approach testing depends on the product’s maturity and the decisions the team needs to make—it can be quick and exploratory or more structured and data-driven. The main goal is always to reduce risk: making sure we’re building the right thing, avoiding usability issues, and meeting user needs. Testing and validation ensure we make informed decisions and deliver products that truly work for users.

Q:

When you are validating a new product concept, what are the first three things you test for?

A:

When validating a new product concept, I first look for problem and solution fit, asking if we are solving a real and meaningful problem for users or just creating a solution in search of a problem. Next, I check if the concept aligns with users’ mental models, making sure it fits how they naturally think about the task rather than introducing confusion. Finally, I assess the feasibility of interaction, ensuring users can intuitively understand how to engage with the product even at the earliest prototype stage. These three areas help ensure we’re building something valuable, understandable, and usable from the start.

Q:

From your experience, what’s a common pitfall or blind spot that designers often have when it comes to testing and validating their own work, and what’s the best way to overcome it?

A:

A common pitfall I see is confirmation bias. Designers are naturally invested in their work and want to see their solutions succeed, which is a strength, but it can make it difficult to stay neutral during testing. This often leads to unintentionally framing questions or interpreting user feedback in a way that supports the existing design, or overlooking negative signals and interpreting ambiguous feedback as positive. For example, I’ve seen designers react to user struggles by thinking, “They’re just not doing it right,” instead of asking why the user’s approach is different from what was intended.

To overcome this, I recommend using structured and objective research protocols and involving a neutral party, such as a researcher or another designer who wasn’t involved in the project, to help design and interpret the findings. If that’s not possible, it’s helpful to focus on testing hypotheses rather than designs. Instead of asking if users like a layout, ask if they can complete the intended task efficiently with that layout. This shift moves the focus away from seeking approval and toward uncovering the truth about user behavior. It leads to much deeper and more actionable insights, helping teams improve their designs based on real user needs rather than assumptions.

Q:

How do you define the role of a user researcher and strategist, especially in the context of a product’s development cycle?

A:

2 day user research conducted with Amazon drivers using Interwoven’s prototypes.

A user researcher acts as both an investigator and a translator throughout the product development cycle. Their primary role is to uncover users’ needs, behaviors, and mental models, then translate these findings into actionable insights for product and design teams. This ensures that decisions are informed by real user data.

As a strategist, the researcher defines which problems matter and identifies when research will have the most impact. They guide teams on integrating research, considering constraints like time, budget, and business goals. By joining early—often before a roadmap—they help plan user touchpoints and ensure solutions address the right problems. During development, they stay involved to provide both strategic direction and hands-on support.

Ultimately, user researchers don’t just ask if users like something—they dig into the reasons behind user feedback and help teams understand how to improve products based on those deeper insights.

Q:

You’ve worked in both consumer tech and the healthcare industry. What are the key differences in testing and validation between those two very different fields?

A:

The biggest difference between testing and validation in consumer tech versus healthcare is rigor and regulatory oversight. In healthcare, usability issues can cause serious consequences, including clinical errors or patient harm. Validation is highly structured and meticulously documented. Strict standards like IEC 62366 govern usability engineering and compliance. Ethics boards or institutional review boards often oversee participant recruitment and protocol approval. Every step follows regulatory frameworks, with higher stakes because patient safety is critical.

In contrast, consumer tech allows for more flexibility and speed. There’s a culture of rapid iteration and experimentation, which is great for innovation but can sometimes come at the expense of thoroughness and depth. While the risks in consumer tech are different, they are not insignificant—especially when products handle sensitive data or reach vulnerable user groups.

Because of this, I try to bring some of the discipline and best practices from healthcare into consumer tech environments. This includes careful documentation, ethical research practices, and a focus on accessibility and long-term impact, not just short-term outcomes. Ultimately, it’s about finding the right balance between moving quickly and ensuring that the products we build are safe, responsible, and truly meet the needs of users.

Q:

What are some of your favorite testing methodologies, and how do you decide which one to use for a given project?

A:

Interwoven’s 2 day user research conducted with Amazon drivers.

I’m a strong advocate for mixed methods research because combining qualitative insights with quantitative data gives a much fuller picture of user behavior and needs. One of my favorite methodologies is contextual inquiry, which involves observing and talking with people in their own environment as they use a product or complete a task. This approach helps me understand not just what users say, but how they actually interact with products in real-world settings. For example, if we’re studying a grocery shopping app, I might go to the store with participants to see their process firsthand, which reveals details and pain points that wouldn’t surface in a simple interview.

Virtual moderated interviews are another favorite. These allow me to reach participants regardless of location and see how they use products remotely, which is especially valuable in today’s distributed work environment. The ability to connect over video calls means I can gather feedback from a diverse range of users and see their reactions and interactions in real time.

Unmoderated usability testing is useful for scaling research quickly. I can set up scenarios for participants to complete on their own, then observe their behavior and gather feedback without being present. This method is efficient and allows us to collect data from a larger group, but it’s most effective for digital products where hands-on interaction is straightforward.

Surveys are also a key tool, especially for reaching larger groups and adding quantitative context to qualitative findings. By layering survey results with insights from interviews or usability tests, I can validate trends and prioritize next steps based on broader user input.

When choosing a method, I consider the development stage, confidence needed, and the decision we’re supporting. For early exploration, I use interviews and contextual studies to uncover deeper insights. For later validation, I combine unmoderated testing with surveys to scale and triangulate findings. Time, budget, and business constraints matter, but I start with the best-fit approach and adjust. If a decision is critical, I recommend rigorous methods, even if they require more time or cost. With constraints, we may compromise on depth or scale, but I maintain strong standards and ensure insights are actionable.

Q:

Can you share an example of a time when user testing completely changed the direction of a product you were working on? What was the most surprising thing you learned?

A:

At Sonos, I led a study visiting homes to observe how families interacted with audio devices. We expected simple patterns of use, but discovered much more complexity and personalization. Some children used bedroom speakers to create private spaces, shielding themselves from household sounds. Adults set audio timers to structure routines, signaling dinner or the day’s end. We also saw people moving speakers between rooms, challenging our assumptions about fixed device placement.

These observations revealed that audio was not just about individual enjoyment or entertainment. It was deeply tied to family dynamics, daily routines, and personal boundaries. The most surprising thing was how much people customized their use of the technology to fit their unique household needs, often in ways we hadn’t anticipated. This insight shifted our focus from simply improving the product’s core features to considering how we could better support multi-user households and flexible use cases.

As a direct result of this research, our team rethought both hardware and software design. We prioritized features that allowed for easier movement of devices and better support for multiple users. Internally, the conversation changed from how do we improve the product for one user to how do we create an experience that works for everyone in the home. This experience reinforced the importance of observing real-world use and being open to unexpected insights that can fundamentally change a product’s direction.

Q:

How do regulatory requirements and patient safety impact your testing process, particularly for medical products?

A:

In medical device development, every usability study is part of risk mitigation, validating that products can be used safely and effectively in real-world clinical settings. This involves formal task analyses, carefully designed protocols, and adherence to standards like IEC 62366 and FDA guidance. Studies often require ethics board approval, and documentation must be audit-ready. Usability is a core safety and regulatory requirement, not just a UX concern.

Q:

Considering your experience with wearable technology, what are the unique validation challenges for products that collect sensitive user data?

A:

Whenever we gather user insights, we work with sensitive data. This is especially true for wearables, which collect continuous personal information. Devices track health metrics, location, and daily habits, raising privacy concerns. A main challenge is ensuring responsible handling through secure storage, anonymization, and proper user consent. In healthcare, frameworks like HIPAA set strict standards for protecting sensitive information. In consumer tech, guidelines are often less rigorous or poorly understood.

Another challenge is that users may not always realize how much personal information they are sharing or how it could be used. During research sessions, people can reveal surprisingly personal details, so it’s important for researchers to be transparent about data practices and make sure participants are comfortable and fully informed about how their data will be used.

It’s also critical to ensure that everyone on the research team understands and follows best practices for privacy and data security, especially when collaborating across teams or using external vendors. Balancing the need for meaningful insights with the responsibility to minimize the collection of sensitive information is an ongoing challenge.

Finally, as wearable devices often collect data continuously and in real-world contexts, validating their accuracy and reliability can be challenging. Researchers must design studies that reflect real-life usage while still protecting privacy, and be prepared to address concerns from users who may be wary of how their data is managed. Ultimately, building trust with users and being transparent about data practices are essential for successful validation of these products.

Q:

How do you see the role of AI impacting user research and testing?

A:

AI is changing research by automating tasks like transcription, summarizing sessions, and analyzing sentiment at scale. This frees researchers to focus on interpretation and strategy. The real value is in AI augmenting human judgment, such as tagging, synthesis, and participant recruitment. However, it’s important to remain critical, as AI can accelerate both good and bad research. Thoughtful study design and human oversight are still essential.

Q:

What’s one innovation in testing or validation that you’re most excited about right now?

A:

I’m excited about agentic AI, which helps synthesize large volumes of qualitative data. I’m currently using an AI agent to surface patterns and themes across ongoing customer interviews, making insights more accessible and actionable. This saves time and democratizes access to user voice, amplifying the impact of research.

Q:

What’s one piece of advice you would give someone who wants to include rigorous testing into their product development cycle?

A:

Start small, start early, and test often.

You don’t need an elaborate usability lab, a lengthy protocol, or even a fully working prototype to begin gathering meaningful feedback. The most important thing is to make testing a habit from the very beginning of the development process. Validate your assumptions before you focus on finalizing interfaces or features. Even simple methods, such as walking through a concept or asking users to think aloud as they attempt basic tasks, can uncover critical insights early on. This is when it is easiest and least expensive to make changes.

Involve your entire team in the process. When designers, engineers, and product managers watch real users, it builds empathy and alignment. Seeing user struggles or successes often drives better, more user-centered decisions. Remember, you are not the user, and assumptions can be unexpectedly challenged. Start small and include everyone to create a learning culture. This continuous improvement leads to stronger products and better outcomes for users.

User Research in product development cycle

—

Please reach out!

A Q&A with Soft Goods Designer Anthony Parrucci

Spotlight articles shine a light on designers we admire, asking leaders in the field about their work and their design journey. For this installment of our Spotlight series, we caught up with former Interwoven Design Group designer Anthony Parrucci, now a Soft Goods Designer at Newell Brands in Atlanta. From his early days dreaming of designing hockey gear to building innovative products for the baby industry, Anthony has carved a path defined by curiosity, collaboration, and a deep respect for hands-on making. In this conversation with Interwoven founder Rebeccah Pailes-Friedman, he reflects on conceptual prototyping, the power of “sketching in 3D,” and how early models can unlock new insights into user interaction and scale.

Anthony earned his master’s degree in Industrial Design from Rochester Institute of Technology after completing undergraduate studies in Business Administration and Art at Elmira College. Before joining Newell Brands, he spent three years at Interwoven Design Group, where he helped develop products across the athletic, medical, and military sectors—ranging from exoskeleton suits to technical bags and soft goods. His approach blends material experimentation with a strong focus on real-world usability. Outside the studio, Anthony brings the same discipline and drive he once applied to ice hockey, which he played at the professional and collegiate levels. Whether on the rink or in the workshop, he’s always been drawn to how performance, form, and human connection intersect.

Q:

Tell us a little bit about your background and how you found your way into industrial design.

A:

As far back as I can remember, I always wanted to be a hockey player. That was the dream. But what I found most exciting was the equipment—sticks, pads, helmets—and the idea of designing it myself. I knew I wanted to be the person behind the gear, making things better for athletes. But the funny thing was, while everyone could tell me how to become a pro hockey player, no one had any clue how to become a product designer. I kept asking, but nobody could point me in the right direction.

Anthony Parrucci sewing a prototype at Interwoven, working on soft goods design. — *Anthony Parrucci at Interwoven, focused on soft goods prototyping*

It wasn’t until undergrad that I met a professor who changed everything. He helped me find the path and really took me under his wing. I went to RIT, studied industrial design, and honed my skills while finishing up my hockey career. After graduation, I interned at Interwoven, and that turned into a full-time job—which was honestly one of the best places to grow as a young designer. I spent about three years there, getting my hands dirty, building fast mockups, and learning how to make ideas real. Now, I’m working at Newell Brands as a soft goods designer, focusing on the baby space. It’s a change of pace from Interwoven—bigger team, different structure—but the fundamentals of good design still apply.

Q:

What does conceptual prototyping mean to you, and what role does it play in your process?

A:

To me, conceptual prototyping is one of the most important parts of product design—especially when you’re working on the front end of a project. In fast-paced environments, having a way to quickly explore and communicate ideas is everything. I remember when I was in school, I was so hesitant to make mockups. I worried that if something was built with cardboard or hot glue, people would judge it. I’d think, “This muslin has raw edges—are they going to take it seriously?” It took me a while to realize that the point of those early models isn’t perfection—it’s validation. You’re trying to test an idea, not deliver a polished object.

Whitecloud Ideation — *At Interwoven, muslin prototypes help bring design ideas to life.*

Once you get over that mental hurdle and stop caring about fidelity, you’re limitless. You can make a crude mockup and say, “Imagine this part holds electronics,” and suddenly you’re in a conversation about function, user interaction, and viability. At Interwoven, that was a big part of the culture. You could build something messy, cheap, fast—and the point was to learn. It wasn’t about impressing people with how pretty something looked; it was about getting information quickly, failing fast, and saving money in the process.

Sometimes a $1 muslin model tells you more than a $300 3D print. That’s the ROI of prototyping. Even though there’s no exact formula for it, you learn so much by making something tangible. And that knowledge pays off tenfold when you move to the next stage.

Q:

At Interwoven Design, we often talk about “sketching in 3D.” How do you think 3D prototyping compares to 2D sketching in your process? When do you choose one over the other—or do you use both?

A:

A lot of the time, they happen in parallel. I’ll jump back and forth between 2D sketching and physical prototyping depending on what I’m trying to figure out. But if I’m being honest, there were definitely moments—especially during projects at Interwoven—where I found myself sketching too much. I’d get stuck in the lines, trying to make things look good on paper, but I wasn’t really proving anything. I’d realize I was spending all this time drawing, but not actually learning how something would work in the real world.

That’s why I’ve always loved working in 3D early. I remember being in the studio with muslin draped on a form, sketching right on the body, ripping paper, taping things together. There’s just something about the immediacy of that. You’re not just imagining a form—you’re shaping it in real time, and often that translates right into pattern-making or the next stage of development.

Sometimes, when you’ve got a tight timeline or the project is super function-driven, I’ll skip 2D altogether and go straight to building. I’ll bring a quick muslin or cardboard mock-up to a team meeting and say, “This is what I think it’s doing.” That way, people can touch it, react to it, and we can talk through pros and cons on the spot. You don’t get that level of feedback from a sketch alone.

So yeah, I still sketch—but physical modeling is where I uncover the really good stuff. And often, once I understand how something works in 3D, then I’ll go back to 2D to refine the aesthetics or create a more polished representation. It’s a constant back-and-forth.

Q:

Can you share a specific example of a conceptual prototype that helped solve a problem or clarified your thinking during a project?

A:

Woman wearing the Ninja Frost Vault soft cooler backpack outdoors, surrounded by trees. — *The Ninja Frost Vault soft cooler — a functional, fun design born from rapid prototyping.*

The Ninja Frost Valut soft cooler project comes to mind immediately. That one was a wild ride in the best way. They came to us with a super tight turnaround—like two weeks—and said, “We need something functional and fun, and we need to validate the user interaction.” And keep in mind, this was a client with all the resources in the world. They had access to 3D printers, high-end materials, whatever they wanted. But even they knew that to move fast, we needed to get scrappy.

So instead of building out a full-size, high-fidelity prototype, we started with quick, rough mockups—cardboard, muslin, whatever we could use to visualize the structure. It was about figuring out how the top door worked, how the zipper would interact with the opening, how the compartments connected on the inside. They told us, “We want to fit 18 cans and a wine bottle,” which sounds specific but gets tricky once you start shaping the actual space.

That’s the beauty of these early mockups. They let you work within constraints and still explore. You’re building something real enough to evaluate, but flexible enough to change on the fly. We’d hold the model, try different openings, move things around. If we’d started with a polished CAD file or waited on a perfect 3D print, we would’ve lost valuable time—and we probably wouldn’t have caught some of the spatial issues until much later.

So even in a super corporate environment, the quick and dirty models were essential. They gave us clarity, speed, and insight—all things you can’t afford to miss when you’re on a tight timeline.

Q:

Can you give an example of a quick model that taught you something you wouldn’t have learned on paper?

A:

a warehouse worker wears the Apex Exosuit — *IDEA Gold Award 2021 winner: Apex Exosuit*

Totally. One of the best examples I can think of actually goes back to the HeroWear Apex exosuit. We were working on the early development of the wearable, and we were designing things like the shoulder straps and leg portions—really important areas for comfort and function. And the thing is, you can look at all the biomechanics research in the world, but until you physically mock something up and put it on a body, you don’t feel the impact of the design.

I remember making these super rudimentary models—muslin straps, cardboard cutouts, foam forms—and just trying things on. One tiny change, like shifting the sternum strap half an inch higher, would totally throw off the balance. It would start pulling back on the upper plate in this weird way, or it would choke you a little if there was any tension. It was a great reminder that the human body doesn’t care what the sketch says—it cares how it feels.

model wearing exosuit mockup harness — *A model wearing a mockup of the the Apex Exosuit, rear view*

That was especially true when we were testing on different bodies. Something that fit me well didn’t necessarily work on Aybuke or Meghan. We were seeing, in real-time, how much variation there is in anatomy. And we weren’t just looking at fit—we were watching how people used the prototypes. One person would put on a backpack starting with their left arm, another would hoist it from the bottom, someone else would swing it over their shoulder. All of those micro-behaviors matter.

So in that case, the mockups weren’t just about proving fit—they were about revealing differences in interaction, body types, motion, all of it. None of that was visible in the drawings. You had to build it and put it on people. That was the only way to really learn.

Q:

What kinds of materials do you gravitate toward when making these sketch models, and how do those choices shape the way you think through a problem?

A:

It really depends on what I’m trying to solve. I’ll use muslin if I need something that drapes or behaves like fabric, cardboard when I’m looking at form and structure, and EVA foam is kind of the wildcard that I love to use when I need something that does a little bit of everything. That stuff is gold—it can act like a soft shell, a flexible strap, even simulate Velcro depending on how you cut and tape it.

The thing you have to watch out for, though, is that people will take whatever you show them literally. If you’re showing a conceptual prototype to marketing or upper leadership and you use a stretchy mesh just because it looks good or is easy to sew with, they might say, “Oh wow, this feels amazing—we should use this!” And you’re like, “No, no, this isn’t the real material! It’s just here for the mock-up.” So I’ve gotten more strategic over time.

Breg CrossRunner™ Soft Knee Brace illustration and prototype on user — *A colorful EVA foam prototype of the Breg knee brace*

For example, when I was working on the Breg knee brace, I used EVA foam in all these crazy colors—turquoise, lime green, bright yellow—on purpose. If I’d made the models in black, which is what the final product was supposed to be, people would’ve gotten way too literal. But the wild colors kind of divorced the client from the final form just enough so they could focus on what the prototype was doing, not what it looked like.

So material choice isn’t just about function—it’s about communication. It’s about knowing who you’re showing it to and what message they might take away from it. I’ve learned to be really intentional about that.

Q:

What kinds of insights have you gained from building models that surprised you?

A:

So many. One of the most memorable was while working on the Apex exosuit for HeroWear. We were testing strap placements, and even with minimal tension, a small shift in sternum strap height could cause major fit issues. It made us more aware of how anatomical differences—especially between male and female bodies—affect fit. You also learn a lot just by watching how people put things on. No two users interact the same way.

Q:

How did your time at Interwoven shape the way you design and prototype today? Are there any techniques, habits, or philosophies you still carry with you?

A:

For sure. I think the biggest thing that Interwoven gave me—besides hands-on experience—was confidence. Confidence to put unfinished ideas in front of other people and say, “Here’s where I’m at,” even if it’s not polished. That’s a hard thing to do straight out of school. I was so used to trying to perfect everything before I shared it. But at Interwoven, we moved so fast. You didn’t have time to obsess. You had to get your idea out there, test it, talk about it, and then move on to the next iteration.

I remember the first time Rebeccah handed me a piece of EVA foam and said, “Just mark it up. Make a model.” And I was like, “Wait—what?” But once I did it, it unlocked something. It gave me permission to try things and not worry if they were ugly or halfway done. That mindset—that a rough idea is still a valid idea—has stayed with me. I carry that into everything I do now.

At Interwoven, we prototyped constantly. Blue-sky concepts, tech that didn’t even exist yet—we still made physical mockups to explore layout, user interface, ergonomics. Whether it was figuring out battery placement in a pet harness or mapping electronics onto soft goods, we always built first, then refined. That method taught me how valuable foam, muslin, and tape can be.

So even now, when I’m working at a much bigger company, that habit of diving in, getting hands-on early, and iterating fast is something I always go back to. It’s fundamental.

Q:

Conceptual prototypes aren’t always easy for clients or stakeholders to understand. How do you communicate their value without people taking them too literally?

A:

That’s such a good question—and it’s a challenge for sure. I think the biggest thing is knowing your audience. You have to anticipate what people are going to expect based on who they are and what kind of background they’re coming from. If you’re dealing with a huge corporation, they might be used to seeing fully 3D-printed, sanded, spray-painted mockups. That’s their norm. But someone else might be totally fine with cardboard and tape if it helps them understand the idea.

What I try to do is build in smaller checkpoints. Instead of waiting for a big Phase 2 presentation where everything’s supposed to be clean and “done,” I’ll push for a mid-phase touchpoint. It gives you a chance to say, “Here’s where we’re at—we haven’t spent too much time or money yet, but we’re getting important feedback now so we can steer in the right direction.” That sets expectations early and helps people focus on the ideas, not the finish.

Another trick I use is playing with scale and color. If you build something small, or in colors that clearly don’t belong in the final product—like making a knee brace mockup in bright turquoise and neon yellow—people immediately understand that it’s not final. It helps create that separation, so they look at the concept, not the aesthetics.

And sometimes you just have to say it directly: “This isn’t a final product. This is about exploring function, interaction, or layout.” That helps shift the mindset. The point is to open the door for feedback—not to get approval on a finished design.

Q:

In what ways does physical modeling—taping, folding, building—inform your digital work, and vice versa? When do you bring CAD into your process?

A:

I think physical and digital work are more intertwined than people realize. For me, they constantly inform each other. If I’ve built something to scale—like a muslin vest or a foam form—I’ll take photos of it and bring those into Illustrator. I might drop the opacity down and sketch over it. Or I’ll use it as the base for a tech pack, especially if we’re moving into a pattern-making phase.

Interwoven muslin prototype pinup — *At Interwoven, hands-on muslin builds inform the digital process, revealing nuances that screens alone can’t show.*

Sometimes I’ll scan the flats of a muslin build and start drawing from there. That becomes the foundation for my Illustrator files or even for 3D modeling. And then as you start building in CAD, that’s when you find the real-world limitations—like, “Oh, we can’t mount this piece the way I thought,” or “This part is interfering with another component.” It’s like a back-and-forth conversation between the physical model and the digital file.

If you jump straight into CAD without building anything first, you miss so much nuance—especially around ergonomics and body interaction. The screen gives you precision, but the shop gives you truth. And once you have something physical, even a rough version, it makes your digital work smarter and more intentional.

Q:

What’s your take on failure in the prototyping process?

A:

Failure is 95% of it. You build quick mock-ups, find out what doesn’t work, and share them anyway. At Interwoven, we’d make 10 different models and walk through them as a team. Even if three of mine failed, someone else might spot something worth carrying forward. That back-and-forth was always valuable.

Q:

Final question: What advice would you give a young designer about sketch modeling?

A:

Get up from your desk. Go to the shop. Talk to people. Learn how things are made. And most importantly—don’t be afraid to fail in front of others. That confidence builds with time. Every mock-up, even the rough ones, teaches you something. And you never know who might see something in it that you missed.

—

Please reach out!