InVision presents

Principles of Product Design


by Aarron Walter

Successful design-driven companies building the best products with the strongest design teams have practices in common. These extensively researched core best practices will help your team design better, faster, and more collaboratively. Combined with the power of design thinking, these product design principles will accelerate your team’s design practice.


Go to Chapter
Guess less
Stop wasting time

The software industry celebrates stories of lightning-strike success so much, you’d think hunches and risky bets could create unicorns. The best product design teams understand the reality—customer research forms the bedrock of successful products and companies.

Go to Chapter
Go to Chapter
Story first
Find your North Star

Humans have used stories to foster collective understanding since the beginning. The most powerful designs start with a story—the why—and where your designs fit into people’s lives. Using product stories, journey maps, storyboards, and user personas, teams can build empathy and understanding before designing.

Go to Chapter
Go to Chapter
Pencils before pixels
Think divergently

Every design begins somewhere, in imperfection. Sketching brings together designers and key stakeholders so they can collaboratively find the best solutions without getting lost in design details.

Go to Chapter
Go to Chapter
Show and tell
Create a culture of feedback

When it comes to feedback, there’s little room for polite reserve within a design team. Use design reviews, retrospectives, design standups, and careful space planning to facilitate a culture of feedback within your team—your designs and designers will benefit.

Go to Chapter
Go to Chapter
Fast feedback
Product prototyping—accelerated

Building great products requires an iterative process. The more your team tests their designs through prototyping, the faster you’ll discover needed course corrections or new possibilities. Through building blocks like pattern libraries and user feedback, teams can always design with fresh eyes.

Go to Chapter
Go to Chapter
Lateral design
We're better together

Your org chart can greatly influence the design process at your company. Bridge gaps between design, engineering, research, product, and others with cross-functional teams, sprints, working groups, and other structural changes that enable better lateral design.

Go to Chapter
Go to Chapter
Break the black box
Product design is people

As your company and design org mature and scale, it gets harder to maintain the visibility and transparency crucial for great product design. You’ll need to take on streamlining communication, surfacing design within the company, and more big-picture challenges beyond your desk.

Go to Chapter
05

Fast feedback

Product prototyping—accelerated

Listen to Chapter

Have you ever watched a great chef at work—the kind of chef worthy of a coveted Michelin Star? Whether she’s in the kitchen, the field, or at the market, she’s always tasting the food. Her palette guides her to the right flavors, aromas, and textures that combine to create an unforgettable meal. The alchemy of great cooking can only happen when the chef gets feedback at each step of her process.

Similarly, design teams that produce great products have something in common—they habitually test their designs. Before a single line of code is written, they build high-fidelity prototypes and put them in the hands of colleagues and customers, collecting fast feedback and correcting course before development.

These product design teams have a huge competitive advantage over those that get feedback only after their product ships: they learn faster. They spot problems quickly and fix them. They talk to customers early and align the product to their needs.

The software industry isn’t the first to grasp this principle. The animation industry was transformed by an underdog studio in Los Angeles that found a way to learn faster than the big New York studios by getting fast feedback.

Learn fast, leap forward

In the early 20th century, the boundaries of animation had been drawn and the industry was happily operating within them. The medium was crude—settings were flat, characters lacked personality, and the content was often limited to slapstick gags.

Then Walt Disney Studios changed everything.

Disney’s faith in the medium as an artform pushed the studio to experiment with new ideas that lead to astounding technical achievements. In 1928, they introduced sound with the release of Steamboat Willie, and in 1932 they introduced full color with Flowers and Trees. Each is an impressive achievement, but it was the studio’s contributions to process that enabled animation to evolve into the rich medium we know today.

In 1931, seeking faster feedback on their drawings, Disney animators began making what they called “pencil tests:” rough drawings on inexpensive negative film that they fed into the Moviola, a device with a small screen for viewing footage.

This process let Disney animators meticulously refine their drawings immediately, not weeks or months later, and enabled them to learn the art of the medium faster than any other studio. Soon the animators began stringing together pencil tests to review entire scenes, the interaction of characters, and the delivery of the story.

Walt Disney Studios’ prototyping method pushed the medium into new territory. While other studios produced silly gag films to make people laugh, Disney created art with emotionally complex characters that made audiences cry.

By building fast feedback into their creative process, Walt Disney Studios was able to make a huge leap. What worked for Disney can work for your design team too. Don’t worry, you won’t need to track down a Moviola on eBay. All you need is a high-fidelity prototype.

A pencil test from the production of Disney's Snow White

Prototyping and tools

Prototypes let us present product concepts to colleagues and customers without diving into the production process. A good prototype is a balancing act—it feels like a real product, but doesn’t require a lot of time to build.

I used to create prototypes using HTML, CSS, and JavaScript. It was a painful, time-consuming process that affected my judgement when testing. I’d spend a week or more producing a prototype that was vaguely realistic enough to show customers. When feedback called for big changes, I found myself reluctant to act, as the work seemed daunting.

That process seems ridiculous today, as we’re in a golden age of product design tools. We can now create prototypes that are much higher fidelity in less time without writing a single line of code. With less time invested, tweaks to a prototype come easy.

There are a number of prototyping tools on the market—more than we can cover here. Do some research to find the right fit for your needs. As you consider various prototyping tools, ask yourself these questions:

  • Is it easy to focus on product design problems, or will I be fiddling with the tool or code?
  • Can I deploy my prototype to various devices to create a realistic testing experience?
  • If you’re working remotely, is it easy to share the prototype and conduct remote testing?

InVision and Sketch

As you might’ve guessed, we’re partial to prototyping with InVision. Before joining InVision, my product design team at MailChimp used InVision to prototype new apps and explore feature concepts. It helped us move fast and get the feedback we needed. We shared InVision prototypes with the engineering team early to get feedback and keep everyone in sync.

Many product designers have transitioned from Photoshop to Sketch, which lets you work on multiple screens in a single file. You can save common UI elements like buttons and forms as shared symbols to build a screen quickly. There are a number of great learning resources to guide you if you’ve yet to make the leap to Sketch.

Craft by InVision, a suite of free plugins for Sketch and Photoshop, creates a tight integration between Sketch and InVision, shortening the prototype design process. It lets you pull real data from an API, fetch content from a site, or grab elegant photos and drop them into your design file to make your UI more realistic. Craft even lets you build a prototype directly in Sketch.

Design tools today are doing for product design what Disney’s pencil tests and the Moviola did for animation—they’re shortening the learning process so the craft can evolve faster.

Keynote

Keynote, Apple’s popular presentation software, has become a go-to prototyping tool for many designers. It’s simple enough that almost anyone can prototype with it, and sophisticated enough to do elegant animations that make a series of images feel like a real app.

Install Keynote on your iPhone or iPad to run prototypes on the target device, making the testing experience more realistic. Design prototypes in Keynote faster with Keynotopia’s UI templates for both iOS and Android. If you end up doing a lot of prototyping, you’ll probably want to take some time to create your own UI template library so you don’t have to continuously apply your brand’s colors and style to stock elements.

Faster prototyping with a pattern library

Your product prototyping process can be accelerated exponentially when you work with a pattern library—a collection of standard elements that can be combined like LEGO blocks to create a new UI. Creating a pattern library is time consuming work, but it pays off with the design of each new product or feature.

Facing UI fragmentation across many products and platforms, the design team at NASDAQ revised their schedule to spend time creating a pattern library. The process was intense, but helped them unify the user experience across all of their products. There was an additional benefit they hadn’t initially anticipated—prototyping with a pattern library helped them move very quickly.

Spending less time noodling on UI treatments means designers can focus more on aligning the product to customers’ needs. Companies like Salesforce, IBM, Atlassian, MailChimp, Spotify, and Westpac have all developed detailed design systems that help them design new products quickly.

Getting feedback on your prototype

Testing internally

With your prototype built, you can start collecting feedback. Before you put your prototype in front of customers, spend time talking with your design and engineering colleagues. They’ll help you look at the UI with fresh eyes, and reconnect with the key objectives of the project. Now’s a great time to conduct a design review.

Deploy your prototype to the devices you’ll be targeting so everyone can get a feel for the real experience. It’s not uncommon for designers to walk around the building to grab a few colleagues for an impromptu test of a prototype. Great feedback can come from unexpected places, so look beyond the design and engineering teams.

With feedback in hand, revise your prototype accordingly and get ready to test with real customers.

Testing with customers

You’re going to learn a lot as you show your product prototype to your customers. Your ideas and assumptions will be put to the test, which may at times make you uncomfortable. It can be frustrating to watch users struggle with your design.

Your instincts might lead you to help customers figure out how to use your app, but you’ll taint the feedback if you do. Instead, stick to your testing script or work with a moderator who can conduct the tests impartially.

Michael Margolis, UX Research Partner at GV, follows a very simple process as he conducts tests with customers: a welcome, an ice breaking period, the introduction of the prototype, the test, and a debrief. Michael’s script is wonderfully simple and easy to remember. Dive into his process in more detail in the book Sprint from GV.

According to research conducted by the Nielsen Norman Group, the majority of problems with your prototype will be identified after testing with just 5 customers. Instead of testing more customers, Jakob Nielsen recommends another small batch of tests after refinements have been made.

Recruiting customers

Running the test is actually the easy part of the feedback process. Finding test subjects is the hard part. If you have an existing customer base, query your database to find power users. Devout customers are often excited to see new design concepts, and will likely give more informed feedback. This is their chance to influence the design process!

If you’re testing a prototype for a brand new product, you’ll need to be more creative in how you recruit. Once again, the GV team has a clever solution. They create a form to screen customers that asks a few carefully considered questions. A worksheet guides them to create a screener that will target the right kinds of people. They post a link to their screener form on Craigslist, Twitter, Facebook, and send to an existing mailing list if available. Since you’ll only need about 5 test subjects, you don’t need a high response rate to the screener.

Be prepared to compensate your customers for their time—remember, they’re doing you a big favor by testing your prototype.

Alternatively, you could hire a professional recruiter to find customers for you. The downside is it can be very expensive, and it won’t be a hands-off process. You’ll still need to give them enough information to target the right customers.

Testing remotely

Not all the customers you recruit will live nearby. You’ll need to make plans to conduct tests remotely too. Gregg Bernstein, Senior User Researcher for Vox Media, has developed an elegant system to conduct tests with users remotely using inexpensive, freely available software—a rig that runs just $99, a small price to pay for fast feedback!

Here’s how he does it:

  • Gregg shares a Calendly link with a potential test participant, letting her select a convenient test time. Calendly also lets Gregg ask for permission to record the session, and lets him send details on what the test participant can expect.
  • The Vox design team posts a prototype to InVision.
  • Gregg invites the participant to an InVision LiveShare—a shared screen with voice chat where the customer can use the prototype while Gregg asks questions, observes, and takes notes.
  • The session is recorded using ScreenFlow.
  • After the test session is complete, Gregg re-watches the video to fill in gaps in his notes. He then shares those notes and his insights with his Product team via Slack.

This process is simple and fast, yet effective. It lets Vox’s remote product team get feedback from users anywhere without hopping on a plane.

A service like Lookback.io can also help you get fast feedback from both colleagues and customers remotely. InVision and Lookback integrate to let you test a mobile app prototype with customers. It records the customer’s screen, their interactions with your prototype, and even overlays a video of their face as they use your app, helping you read their emotional state.

When your app is built, your developers can integrate Lookback into your app so test sessions can be triggered any time. Users can shake their phone to reveal a secret button that triggers Lookback’s recording feature. All sessions are stored in a central dashboard for designers and developers to review and make revisions.

Lindsey Campbell, UX researcher at InVision, has a unique approach to getting customer feedback remotely. She’s set up a Slack channel to share prototypes with devout customers to get early feedback and bring customers into the design process. The design team monitors the feedback and tweaks the product as needed.

Related: Get stakeholder approval 46% faster

Better, faster product prototyping and testing

Like a chef sampling her ingredients, designers need to get a taste of the user’s experience while designing, not just after the product ships. When you shorten the feedback loop, you can learn faster how to make a product that will appeal to your audience. Here’s some guidance to get you started.

  • When should I build a prototype? After you’ve done initial research and worked through many ideas on paper.
  • How much of the app should I build in my prototype? Don’t waste time prototyping the entire app. Focus instead on the parts about which you have the most questions.
  • How real should my prototype be? It should be real enough that customers won’t realize it’s just a prototype.
  • When should I show others my prototype? Early and often. Don’t let yourself get too far down a single path before you start getting feedback from colleagues. Show your prototype to customers after you and your colleagues have ironed out the kinks.
  • Who should I show it to? Start with the people in your design or product team. Be sure to get an engineer’s perspective to ensure the design you’re proposing is technically feasible.
  • How should I present my prototype? It’s always best to show the prototype on the target device if possible. Frame the problem you’re trying to solve before you ask for feedback from others.

We’re fortunate to know the importance of testing, and to have access to tools that make capturing feedback cheap and easy. Whether remote or in person, your team can build fast feedback into your process so you can build better products faster.

06

Lateral design

We're better together

Listen to Chapter

To design better, we need to look beyond the confines of our craft. Design is more than color and form; design is the act of planning with the intention to serve others. Under this definition, the borders of design stretch beyond a single team.

Engineers, product managers, and researchers all have an important part to play in the design of a product. Their work, like ours, shapes the user experience. But despite shared interests, teams are often siloed by discipline, which makes collaboration and communication difficult, even dysfunctional.

Organizational design influences product design—significantly. If the relationship between the people who make a product is broken, the product will be broken too.

Broken teams, broken product

Here’s a scenario that plays out in companies far too often: Courtney and her team spent weeks perfecting the design of a new product. They presented the final concepts to stakeholders, got immediate sign off, then handed off their design files to Everett and his engineering team.

Though the dashboard design was stunning, Everett’s team had to gut it because the data Courtney’s team wanted to display wasn’t actually available. They also had to throw out the account sign up design because the designers hadn’t included all the necessary fields.

As Everett’s team continued to build the app, the distance between the intentions of designers and the execution of engineers widened. When Courtney finally got a peek at the app, she was horrified and said, “This looks nothing like the design we created!”

She walked across the building to engineering and stormed into Everett’s office to demand an explanation. Everett, frustrated that he and his team weren’t consulted earlier, curtly explained the design concept was ignorant of engineering requirements.

The relationship between design and engineering was already rocky—this wasn’t the first time they’d felt out of sync. Now it had gone from bad to worse, and the product was a reflection of their animosity. It was a mess.

Like an episode of HBO’s Silicon Valley, this story may hit a little too close to home. Courtney and Everett are out of step, as their organization is operating with a handicap—they have a vertical relationship. Design, at the top of the process, passes work down to engineering to execute—engineers aren’t part of the problem solving phase. Subsequently, Courtney’s team missed key technical details and key parts of the design had to be scrapped.

Vertical relationships also flow the other way—from engineering to design. Engineers rush to build a product’s infrastructure and pass it to designers for decoration afterwards. The results are equally disjointed, as buttons and type might look nice, but workflows built around database models instead of mental models leave users confused and frustrated.

Both scenarios are broken. Great products blend design and technology seamlessly. The feel and function of a product are interconnected, and equally important—like the right and left hemispheres of our brain that pass information laterally to synthesize creative thinking and logic.

We can take a cue from nature. When we bring teams together to work laterally—working on the product at the same time in the same place—we can reduce process entropy and create better products.

Cross-functional teams

Cross-functional teams are a hallmark of the Agile process. They bring together engineers, designers, and a product manager to define a product’s purpose, function, and feel.

Cross-functional teams work laterally. Together product managers, designers, and engineers work to understand the problem and conceptualize solutions concurrently, not linearly, giving each team member a voice in key decisions.

Unlike the vertical workflow Courtney and Everett followed, cross-functional teams have no grand handoffs where communication falls apart and political battles erupt. No one is downstream. Pixels and code come together simultaneously around a clear business strategy.

Cross-functional teams have many benefits:

  • Working closely, designers and engineers develop a strong understanding of their colleagues’ craft.
  • The rapport established within cross-functional teams fosters empathy and respect that make collaboration easier (and more fun).
  • Communication is much faster; designers are immediately made aware of the technical challenges their decisions create, and engineers learn when function diminishes form.
  • Diverse perspectives each step of the way lead to better product solutions.
  • Shared ownership dampens political fighting and builds trust.

Though a team may disband after a feature launches, strong bonds remain (like friendships formed in summer camp). This can only strengthen the company culture.

 

Dipping a toe in the water

To make sustainable improvements to the way your organization designs products, you may need to take a red pen to your organizational chart. These sorts of changes don’t come easy or quickly.

But before doing anything drastic, you can test the waters with some small experiments. Small projects with tight deadlines are a great place to start experimenting with cross-functional teams.

If time is tight, start by investing just 1 week in a Design Sprint.

Design sprints

A design sprint is a 5-day process developed by Google Ventures for answering critical business questions through design, prototyping, and testing ideas with customers. Because it takes just 1 week, it’s a low-risk way to try out a lateral design process in a cross-functional team.

The Google Ventures group goes into great detail in their Sprint book and its related websites, but in short, over 5 days a small team will go from understanding the problem space to validating a design solution.

If you survive the sprint and produce a great product idea, you’ll have set the stage for more cross-functional teamwork in the future.

Working groups

Like design sprints, working groups assemble a cross-functional team to tackle a tough problem. But working groups stay together much longer than a week to produce a final product that’s actually shipped to customers. After the project is complete, everyone returns to their respective teams.

Working groups have:

  • Clearly defined objectives and metrics to measure success
  • Designers, engineers, a product manager, and maybe even a design researcher
  • The autonomy to make key decisions about the product they’re building
  • A deadline to ship

MailChimp has a long history of assembling working groups to focus on hairy projects. One such team was created to design a new drag-and-drop email editor.

A designer, a front-end developer, and 2 engineers—one of whom had a talent for prototyping—sequestered themselves behind closed door in a small MailChimp office to tackle the project. Sketching and debating, they looked at the problem from all angles.

Sketches turned into simple prototypes. The designer explored UI concepts and made refinements. Developers coded out the new design, tweaking interactions as they went. Back and forth they worked, always sharing progress with each other immediately and inviting debate.

Eventually, the prototype had reached its limits. After testing with the whole company and select customers, the new editor, Neapolitan, eventually shipped. This working group gave the company the opportunity to escape the gravitational pull of the product roadmap to go deep on an important feature that made working in MailChimp easier and faster.

Everyone on the working group returned to their respective teams with respect for their colleagues and their craft, and knowledge of what could be accomplished when designing laterally.

Going further: Institutionalizing lateral design

Big wins from working group projects can spark conversations about optimizing the rest of the company. The cross-functional team structure that enables lateral design can be scaled up by uniting engineering, product management, and design in an organizational structure commonly referred to as EPD.

Alex Schleifer, VP of Design at Airbnb, describes EPD as a 3-legged stool that supports the organization.

A stool with 1 leg shorter than the others causes instability and imbalance. Similarly, EPD organizations are unstable when a function of the troika is weaker or more powerful than the others. EPD’s strength comes from sharing power.

Each function of EPD must be involved and aligned from a product’s inception to its launch. EPD teams are typically organized around product features by areas of the user experience:

  • Facebook organizes its teams by product feature like news feed, profile, or messenger.
  • Airbnb organizes teams around areas of the user experience like the guest or host experience.

Like workgroups, each team is cross-functional, with representation from each leg of the EPD stool.

The success of EPD is directly connected to the health of the relationships among the 3 leaders of engineering, product management, and design. Dysfunction from the top will trickle down to the respective teams quickly. It’s imperative that these 3 leaders remain united in their leadership and communication to the company.

The challenges of cross-functional teams

Though cross-functional teams offer a number of advantages, they can be challenging. Workgroups, because they’re temporary, rarely surface significant issues. Instead, designers might feel like they’re on a vacation—they get to learn new things before returning to the comforts of home.

Permanent cross-functional teams are more like expatriating—designers will wrestle with their identity and struggle to adapt to a foreign land. Read on to learn how these problems, though common, are being solved at a lot of great companies. Going into an EPD structure with open eyes and a set of solutions will help you transition smoothly.

Isolation

As we saw in Show and Tell, designers need regular feedback from other designers. In a cross-functional team, it’s common for a designer to operate alone, which leaves them craving conversations with peers. Organizations like Slack, Twitter, and the BBC offer some interesting solutions.

Slack: Paired design

Lateral design in cross-functional teams is a mainstay at Slack, but designers always work in pairs, with 1 acting as the lead designer.

You can pair designers even if you’re short staffed. Pair a designer with a colleague from another team who can spend about 8 hours per week (or just a little over an hour per day) working in tandem on design problems.

Twitter: Design reviews

In early 2014, Twitter transitioned from a centralized design team to embedding designers in cross-functional teams. In order to prevent designers from feeling isolated or unable to consistently learn from their colleagues, Mike Davidson, VP of Design, scheduled weekly design reviews and other activities in the design studio to bring everyone together as a team. Congregating regularly gave all designers the opportunity to discuss the overall design style of the company and keep everyone in sync.

BBC: Rotate teams

The BBC, with more than 20,000 employees, lets employees work on a new team every year. This policy helps all employees, not just designers, form new relationships and broaden their understanding of the organization.

Designers who want to rotate within the UX&D team speak to their manager to explore the idea. Approval is common if they’ve spent over a year on the same team. The resource manager facilitates the transfer, taking into account the designer’s skills, career goals, and current team availabilities.

Aligning style and values

Decentralized design teams have to work a bit harder to make sure design remains consistent across features and products. The style of each UI and the values that guide design decisions can fall into disarray if teams are left without clear guidelines. Many large organizations are working hard to solve this problem, but few more than Spotify.

Spotify: Design systems and values

As a company scales, design consistency becomes more difficult to manage. Companies like Salesforce, IBM, the BBC, and Atlassian created a design system to solve UI consistency issues, but Spotify used their design system to solve an organizational problem too.

The team that manages Spotify’s design language—called GLUE (a Global Language for a Unified Experience)—is the center of the design universe in the company around which all other design work orbits. Designers regularly sync up with the GLUE team to get guidance on new UIs and suggest additions to the design language.

Design systems, once thought of as an occasional side project, are playing a more central role in large organizations, making them a perfect place for designers to converge and find common solutions.

Guilds

Designers in cross-functional teams throughout Spotify are joined together by a design guild—a community of interest where knowledge, tools, and best practices can be shared. Anyone, not just designers, is welcome to join discussions in the design guild. A guild coordinator is responsible for managing activities.

Spotify’s guild structure comes from the Agile practices developed by the engineering team.

Values

Outnumbered as they often are in cross-functional teams, designers acquiesce to engineers who encourage smaller design iterations and a simpler approach. Do we really need that animated transition? Does it add much value? It’s difficult to champion the necessity of small details when you’re the lone designer. Many simply give in and get back to work.

There’s nothing wrong with a little pushback between designers and engineers—it keeps both from becoming self-indulgent. But often, engineers push back on design simply because they don’t understand how to measure the success of a design.

Engineers measure success quantitatively:

  • How many lines of code were required?
  • Did this impact site performance?
  • How many bugs did we ship?

Designers measure success qualitatively:

  • Does it look good?
  • Is it easy to use?
  • Is it delightful?

Just as an engineer’s work shouldn’t be measured by design metrics, a designer’s work shouldn’t be measured by those of an engineer. Instead, designers and engineers, working together, must form a shared understanding of what constitutes success.

Recognizing this need, Spotify articulated a series of design values—principles that communicate what’s most important when solving a design problem—and made them available to the whole company. Common values help designers articulate their design decisions.

For example, a large image occupying key space in a UI may seem indulgent to an engineer—Is this photo really necessary? We could fit more data here if we get rid of it. With the support of well defined design values in the vein of Spotify, a designer might respond, “Our design values state that a UI should ‘be alive’. This image creates movement, adds color, and brings an otherwise stagnate UI to life.”

With a shared set of design values, priorities and how they’re communicated becomes clearer.

Lateral design in practice

Lateral design is not organizational dogma. Whether your company is Agile, Lean, or something in between, it creates a spirit of respect and empathy between domains to produce great products.

Organizational design influences product design. Shared ownership, collaborative problem solving, and blended teams are key.

Here’s your to-do list as you put lateral design into practice in your company:

  • Starting small with a 1-week design sprint.
  • When you’ve had a taste of the benefits of cross-functional teams, create a working group to tackle a project with a clear timeline and defined outcomes. You should have designers, developers, and a product manager on the team.
  • When your organization is ready to go further, organize teams in an EPD structure. Engineering, product, and design should share power, and report directly to the CEO or COO.

About the Authors

Aarron Walter
VP of Design Education

As the VP of Design Education at InVision, Aarron Walter draws upon 15 years of experience running product teams and teaching design to help companies enact design best practices. Aarron founded the UX practice at MailChimp and helped grow the product from a few thousand users to more than 10 million.

He is the author of the best selling book Designing for Emotion from A Book Apart. You’ll find Aarron on Twitter and Medium sharing thoughts on design. Learn more at http://aarronwalter.com.

Eli Woolery
Director of Design Education

Eli is the Director of Design Education at InVision. His design career spans both physical and digital products, and he has worked with companies ranging from startups (his own and others) to Fortune 500 companies.

In addition to his background in product and industrial design, he has been a professional photographer and filmmaker. He teaches the senior capstone class Implementation to undergraduate Product Designers at Stanford University. You can find Eli on Twitter and Medium.

Principles of Product Design
Principles of Product Design

Design better. Faster. Together.

Transform your products with the world's leading digital product design platform

GET STARTED NOW