medium bookmark / Raindrop.io |
Product Designer. Writer. I invented a word processor. Check it out @ http://voltawriter.com/
“You don’t need to be a font savant, or be a Creative Cloud wizard, or even have a degree in design in order to be a highly effective product designer.”
– Stephanie Engle: Product Designer, Facebook
In my research for this post I came across several quotes like the one above. Between them all it would seem you don’t have to be good at much to make it as a Product Designer. If these statements weren’t so often followed by some other super profound shit that you actually do have to be good at, this might be welcome news for a generation with no shortage of people who aren’t particularly good at anything.
In the case of web or mobile app design, hard skills like drawing and coding (or whatever else: typography, etc.) are of course great skills to have. They can give you a leg up in certain sub-disciplines, and at minimum, they make cross-functional collaboration much that smoother, but as Engle points out, they’re not the real asks.
Take Material for example, Google’s all encompassing compendium of design principles that govern the aesthetics and interactivity of Google applications. Material was undoubtedly the product of a vast hoard of artists, developers, and geniuses of every other sort you could imagine, but all their efforts would have been for naught without the following:
If you’re considering a career in digital product design and are perhaps lacking in hard skills, the good news for you is that these are all areas in which anyone willing to put in the work can contribute.
To Engle’s point, over the past few years, countless new tools, resources, and refinements in design processes have emerged, making the field significantly more accessible to those who were never really groomed for it. So while she’s correct in that you don’t have to be master of all the hard skills to make it as a Product Designer, she’s also correct in the point I think she was really trying to make, which is that you can do this. It’s available to you if you want it.
Though the knowledge and skills needed to make it as a Product Designer are important, they’re not nearly as important as the inert qualities one must have which lay the foundation for everything else. If you’re empathetic by nature, and you have a head for problem solving, along with a thorough understanding of general design principles and processes, a healthy combination of functional and aesthetic sensibilities, a willingness to learn, and you enjoy the work, of course there’s no reason you can’t quit your shit job as soon as possible, so that you might do what you were really born to do.
Primer
If you’re at least two years out of college, you’re probably aware that most of what you learned while you were in college is now long forgotten. Hopefully, some of the more important stuff stuck with you. What you’re about to read is a summary of some of the more important stuff you would want to retain well after you graduated from a design program. It won’t instantly transform you into a professional designer, but it will provide you with a comprehensive overview of the fundamentals you need to know to get your career started, along with some valuable insights on industry best practices, effective approaches to solving common design problems, and a curation of tools and resources you’ll need for the job.
Before we begin, I want to preface by saying none of this is dogma. Different methods work for different conditions, and as a designer, you’ll find that those conditions are constantly in flux.
In my experience, product design can best be described as a war of attrition against dilemma. Every minute or dollar spent on one thing comes at the expense or delay of another. Every good designer wants to make products that customers want with features they value. But how do you determine which features are the right features? What’s valuable to one customer might cost you a hundred others, and this begs the question, how do you know which customers are the right customers? Where do you begin? How do you know when you “have something?” And on top of all that, how do you figure all this stuff out on a shoestring budget, and at the blazing speeds expected by most of today’s 12-year-old tech CEO’s?
These are the kinds of problems designers and product managers think about every day. On top of actually designing the product, it often falls on the designer to articulate the solutions, not only so they can do their job, but so they can backup their decisions.
Without a proper framework for working through these kinds of problems, design can be a truly miserable experience. Fortunately for us, people have been chipping away at such problems since the first designer designed the first thing. This is how we came to have strategic frameworks like Lean UX, Design Thinking, and BJ Fogg’s Behavior Model. As a designer, you might not necessarily use all of these methods, but odds are that some of the people you’re working with will, so it’s good to know about them.
Lean UX
You may be familiar with Lean Startup or Agile Development methodologies? Lean UX is kind of like Agile for UX Design. It advocates a philosophy and practice of rapid experimentation and continuous iteration of minimum viable solutions. It’s value is in its potential to help designers systematically identify risky assumptions early and swiftly so they don’t end up wasting months of work on something nobody wants. It also provides designers with a variety of techniques for rapid prototyping and testing, and it helps designers develop a mindset for fostering outcomes as opposed to deliverables.
Design Thinking
Another highly regarded framework in the design community is the Design Thinking Model, which was popularized by David Kelly, founder of the renowned design firm IDEO in the early 90’s. Setting aside the unfortunate ambiguity of the term and its high susceptibility to misuse, Design Thinking can be a powerful tool for creating better user outcomes.
IDEO Design Thinking Model
Design Thinking compliments Lean UX’s structured validation approach with a more holistic approach focused on user-centered outcomes — a staple of Human Centered Design, another popular IDEO framework.
What I like about Design Thinking is that it encourages contributors across disciplines to generate and cultivate what would otherwise be considered ludicrous ideas without fear of reprieve — a process that forces us to consider what we take for granted, cultivates new perspectives, and opens doorways to true innovation.
Both Design Thinking and Lean UX emphasize close collaboration with clients, users, and engineers throughout the design process, as well as the necessity to maximize efforts on understanding problems and minimize efforts on the production of features whose requirements are likely to change. For more on Design Thinking, check out Tim Brown’s write-up in Harvard Business Review.
Fogg Behavior Model
A good yardstick for figuring out whether you’re you’re on the right track with a feature is the Fogg Behavior Model — a test, which scores ease of use and motivation for different kinds of user behaviors:
Image Credit: BJ Fogg
The rationale behind the Fogg model is that if a task in application is easy to do and people are highly motivated to do it, they’ll be more likely to do it, which will increase your chances of success with your app. Through Lean UX you can extrapolate the minimum means of achieving high scores on the Fogg Model. Certain tasks will never achieve high scores, or they’ll only achieve high scores with certain segments, and that’s okay, just as long you’re aware of it. If nothing else, the Fogg Model helps raise that awareness.
Every stage in the Design Thinking model involves an element of learning. During the discovery stage, designers need to learn tentative answers to the following:
Where applicable, it’s also good to tack on a “why” to the ends of these questions. The “why” helps you figure out what problems really need solving and where you the designer can make the greatest impact.
“Requirements are assumptions.” ~ Jeffery Gothelf, Lean UX
A good thing to keep in mind when gathering requirements is that without hard evidence (which is often the case early on in a project), requirements are really whatever you believe them to be. Even with hard evidence, assumptions are still interpretations that could very well be wrong in light of what you have yet to learn. Beliefs are based on assumptions. Shaping your beliefs to fit a pre-existing product idea can be tempting, but it can also lead to solving problems that don’t exist.
Instead of setting yourself on an unalterable trajectory toward a single solution, first try to figure out if you’re asking the right questions. Instead of asking “How do we build a bridge?” ask “How do we get across the river?” That’s where understanding the “why” and knowledge of your customer comes in. Sometimes, it might be appropriate to build a bridge, but if you don’t have to build a bridge, don’t build one! Do something else. Maybe pull an Oregon Trail, caulk the wagon, and float that fucker across!
Image Credit: Oregon Trail, MECC
No Problem? No problem!
After you take on a few projects, you’ll start to see that the relationships between the product you’re building and the problems you’re trying to solve can be a little opaque. That’s fine. In 2003, no one had any concept of the awesome power of a “like button.” If you can’t quite articulate the connection between a problem and a solution, it doesn’t mean you should abandon the idea. These ideas come from real places of need, often at the sub-conscious level. The more you understand about the landscape of those places, the closer you’ll find yourself to the best solutions.
In Hooked: How to Build Habit Forming Products, author Nir Eyal talks about how there are two kinds of products in this world: “vitamins” and “painkillers.” Vitamins represent solutions for non-urgent problems. They’re nice to haves, they improve something (supposedly), but the world would most likely go on just fine without them. Half of the items you might find in Brookstone or the Sharper Image could fall into this category. Painkillers, however, solve more urgent problems. It’s easy to confuse the two, but they can be distinguished by the emotions they incite and the impact they have on the market.
When you’re building a new product or market with no real precedent to guide you, figuring out if the thing you’re designing is a vitamin or a painkiller can be tricky. If this is the case, ask yourself how the problem is currently solved and what the outcome is like. Even if your solution is more efficient than what’s currently out there, if the outcome is the same, odds are your product will fall into the same category. From a business perspective, it makes sense for stakeholders to prefer painkillers because people are more dependent upon them, which makes them easier to sell.
On the other hand, every once in a while a rare vitamin comes along and changes the course of history. How does this happen?
“Over time vitamins can become painkillers.” ~ Nir Eyal
It’s good to remember that when you’re dealing with vitamins, the problems they’re associated with might not exist… or might not exist yet. A product designed with the foresight of changing market conditions will undoubtedly have better odds of transforming from a vitamin to a painkiller, which is all the more reason you should always keep a close relationship with your user base.
Conversely, a good strategy you can use to curb your product toward the path of the painkiller is to work habit forming mechanics into the foundation of the user experience:
Image Credit: Hooked Canvas, Nir Eyal
Trigger: The event, often an emotion or external event that compels someone to use a product. Ex. hunger, commercial for Wendy’s.
Action: The event one engages in order to satisfy the trigger: Ex. checking FB satisfies need for social interaction; checking Google satisfies curiosity, etc.
Reward: The emotion or event that happens as a result of the action: Ex. the surge of pleasure you feel when someone you’re attracted to “likes” your FB post; the instant gratification you feel when Uber pulls up within seconds of your ride request (and of course the actual ride home). The more variability a reward may have the more valuable the reward will appear to be.
Investment: What users give for the promise of a future reward. This loads the trigger for the next cycle through the hooked loop. It also increases the value of the product. The more you invest, the better the payoff (ideally). Ex. producing the content for a FB post, which you will check for likes next time you login.
When gathering requirements keep a close eye on the interplay between the product’s user experience and these four components. If these components enhance the user experience, the product likely has the potential to be a painkiller. If you’re uncovering risky assumptions left and right, check them against the hooked loop. You might just discover some new habits waiting to be born. Eg. the entire casual gaming industry.
Whatever you do, don’t force the hooked loop into your UX. Many have tried. Many have died! 🙂
Even if you’re a member of your target audience, before you go all out on something you want to design for yourself, you should probably get some insight from other potential users. You have to talk them, and you have to listen to what they have to say, regardless of how stupid they may sound. During these conversations, it’s always best to keep the tone of the conversation as casual as possible, so they’ll feel comfortable and free of any avoidable biases. Don’t ask them if they would be interested in your idea(s). Don’t ask them to tell you what they would want in a product. Don’t pass judgement on their ideas. Just try to find out as much as you can about the problem itself (if not, the habit forming potential pursuant to the solution) and try to explore the full extent of the person’s relationship with that problem on as many levels as possible. Pay close attention to emotions and tiny details. Get examples. Remember the “why.”
The analysis of your feedback should be as systematic as possible. The objective of user research is to look for patterns you can use to help you develop a design strategy. When collecting data, break down your research subjects into as many segments as possible: age, gender, profession, income, education, interests, habits, etc. Note who is interested (or not interested) in what. Then later, when you’re fleshing out your product or your branding, you can fall back on the patterns from particular segments to help guide your decisions.
Risky assumptions will often make themselves known through the requirement gathering and user research processes. Addressing and mitigating these assumptions can be painful for anyone, particularly clients. The frustrating thing is that game-changing products are always bound to be loaded with risky assumptions, and your job as a designer isn’t to crush the client’s dreams (or your own); it’s to solve the problems that need solving.
It helps to see risky assumptions as opportunities. I.e. the crazier the idea, the more of a chance you have to demonstrate your chops as a designer. If you keep user needs in clear sight, you can usually find a solution. Often the tricky part is simply balancing the needs of the user with the needs of the business, so when you’re dealing with a risky assumption, it’s good to start there. Try to pinpoint the disconnect. Then try to find a way to make the two sides align in a natural and mutually beneficial manner. Sometimes, what you think is a risky assumption might be the client just not communicating their vision as clearly or as completely as they could. In any case, try to give them the benefit of the doubt, and hedge your bets with multiple options for any given scenario.
To help foster empathy for their users, designers will sometimes construct a hypothetical user based on their research, and they’ll create journey maps to illustrate the routes users might take from broad goals to different states in the application.
The following is an early persona I created for a writing app I designed called Volta:
Volta — Provisional User Persona
Provisional personas like this one are designed with little to no data. They’re just a starting off point based on reasonable assumptions. The idea is to put yourself in step with the user’s goals and frustrations, then update your persona as you get more data. Once the app/site is out in the world collecting data, personas start to look more and more like power users or members of key market segments. This is (part of) what is meant by the term “data driven design.”
User journey maps or task-flows often accompany personas in interviews for design roles, and they can be a great resource for mapping out information architecture (which we’ll get into shortly). A journey map will contain product screens and features, but they should be designed with user goals in mind first, not product or business goals. Remember the bridge/river metaphor:
Volta Prototype Journey Map
As you collect more data, really try to put yourself in the mind of your user. Think about the nuances of their day-to-day routines, and use journey maps to reflect your insights.
A term you’ll hear often as a designer is information architecture (IA), which might sound like fluffy nonsense, but is actually a major component of most web and mobile app design projects. For our purposes, it means how things on an app or website are categorized and organized hierarchically. UX Booth does a great piece on IA that’s definitely worth a read:
On my first pass, I generally follow the requirement gathering stage with IA and navigation for the same reasons authors construct outlines before they set out to write. Mapping out IA gives designers a bird’s eye view of the application as a whole. It helps them better understand connections between functionality, and it helps them organize that functionality in a way that makes the most sense to the user.
Card sorting example , Image Credit: UX Matters
Designers rely on a number of different testing tactics to help improve IA. Card sorting is a common and simple exercise in which you write various app functions on the back of notecards, mix them up, then have a potential user organize them according to category in the way that makes the most sense to them. Do this with several different users, then look for patterns. If patterns emerge, congratulations! You’re one step closer to better information architecture!
So what’s the difference between IA and navigation?
Eloquently put by Information Architect Jennifer Cardello, “IA is the information backbone of the site; navigation refers to those elements in the UI that allow users to reach specific information on the site.”
When you’re designing navigation, here are some best practices to follow:
So now we’re starting to really cook. Take a step back. Breathe. Think about everything you just learned! Nice!
Tools
Obviously as a designer, you‘re gonna need a design application. I prefer Sketch because it’s easy to use, it has a lot of great features for UI, and it comes with comprehensive templates that help you design to Apple and Google specifications. It also has a vast library of open source plugins that stretch its functionality far beyond its initial purview. If you go with Sketch, make sure to get Sketch Toolbox, which simplifies plugin installation. UXPin and Adobe XD are also good for general design, but more geared toward prototyping, which will discuss shortly.
Wireframes
A wireframe is a good way to quickly figure out where everything should go on a screen. A typical wireframe is done with black or gray marker on graph paper or white board and contains as little detail as possible. The lack of detail is key because it forces the designer to focus on layout. It also frees up more time to experiment. If you’re not the best with pens or markers, there are plenty of easy-to-use tools out there like Balsamiq Mockups, which make wireframing a breeze. There are also countless free kits available from sites like UI8 or Sketchappsources.
Early Volta Project Wireframe
Once you have a solid handle on the structural aspects of your project (information architecture, journey mapping, and wireframes), you can start fleshing out the visual design. This encompasses things like typography, iconography, color schemes, spacing, shapes, little dudes doing the hula, or whatever. All of these elements will eventually be curated into a library or UI Kit.
Paper Prototypes
Once you have navigation and information architecture worked out, and you have everything down on wireframes, you have the the makings of a paper prototype.
Image Credit: Behance
Label the elements on your wireframes and use the opportunity to see how potential users interact with what you’ve come up with. Have them work through certain scenarios and see what routes they take. Also have them describe their thought process as they go along. You’ll be amazed at how insightful these tests can be. You might find that you have a lot of iterating to do, and this will set you back, but you’ll also be relieved that it only took a few sketches to learn where you went wrong, as opposed to months of coding and thousands of dollars.
Typography
“God is in the kerning.”
~ Matteo Bologna
For visual design (the visual style of an app or website) a good rule of thumb is to start with typography so you can use it as a basis for the rest of the site/app’s vertical rhythm:
Typography designed for the grid using 27px blocks on Sketch. Sample from Gridlover.net. Note the consistency in the body text. This is achieved by matching grid block size with line height.
It’s also good to get familiar with the lingo of typography, if for no other reason than to know what the hell they’re talking about in the design programs you use. If you really want to have some fun learning typography, check out Type Terms:
With visual design elements like typography or color schemes it’s best to keep it simple. No more than three fonts per project (at least when you’re first starting out). Two is fine, and is typically the norm. Serif and a Sans-serif pair nicely, usually as header and body. Keep it under six font-sizes per project, and remember, the larger the font, the more flexibility you have in terms of font-weight. Also try to keep the length of any line of text under 90 characters. This will make your text easier to read.
If you’re curious about what fonts are on your favorite websites, this extension can identify the font, font-size, and line-height of any typographical element on any live webpage.
Iconography
As you probably are well-aware, in the wake of the smartphone era, scores of new visual languages have come into being, transforming the way we communicate in the process. Companies like Google and Apple have developed open guidelines and icon libraries, consisting of icons for nearly every function of an application across platforms. Additionally, sites like the Noun Project have popped up, providing simple visual representations for every communicative scenario you can imagine.
Open source icon fonts have also become very popular. Some staple icon fonts are Font Awesome and Glyphicons. These are cool because they come with cheat sheets that let you copy characters you can then paste directly into your design files. Once you’re ready to create your own icon font, check out Fontello, which allows you to import SVG files into a collection you can then export into font files.
A good best practice for iconography is to remember how frustrating it is to look for a feature, only to find some stupid ambiguous icon that could mean anything. Unless the meaning of your icons are painfully obvious, it’s probably a good idea to avoid using them without labels whenever possible. It might take up more space, but your users will have a much easier time navigating your app.
Color
The semantics of color theory can be a real black hole, so for now we’ll just stick to the fundamentals. A good way to understand color is to think of it the way you think of chemistry. Colors aren’t inherently good or bad, but they do have their own unique attributes which produce certain psychological effects that can be perceived as good or bad or everything in between.
Medium color palette made with Palettable
Like the elements in the periodic table, some colors play nice together. Some don’t. Why certain color combinations are more aesthetically pleasing than others or why they produce certain psychological effects has been the subject of scholarly debate for centuries, and a lot of it has to do with context. For example 500 years ago warm colors like red and yellow might have made you think of fire. Now it might make you think of McDonalds. The triggers we associate with colors are rooted in social constructs. And awareness of those constructs can help designers better connect with their audiences.
Color Vocabulary
As a designer, you’ll hear a million and one ambiguous terms to describe different kinds of colors, often from people who don’t really know what they’re describing. You’ll hear words like muted and washed, intermediate, neutral. Well what the hell is the difference between intermediate and neutral? How does one mute a color?
What’s interesting about this is that there is no such thing as a fixed muted color. There are just the colors people have in their heads when they hear the term “muted.” To mute a color means to reduce its saturation (oh great, what the hell is saturation?). Saturation can best be understood as the spectrum between gray and pure color. The less gray a color is the more saturated it is.
In the palatable figure above, you’ll notice some numbers in each color bar. These are called hexadecimal numbers and they’re used to identify different colors on a spectrum of 16 million possible colors.
Color schemes
I’ve found the best way to get my color schemes to look right is to study the color schemes of the products I like to look at. Chrome has a great extension for extracting color codes from any element on a web page. Another great resource for studying color is Dribbble (a showcase site for artists and designers) because the color schemes for each Dribbble project are included in the project posts.
Just like typography, when it comes to color less is more. Up to six main colors per project is fine. Different tints of these colors can be used for things like hovers, overlays, down-states, etc. Millions of colors will obviously come into the fold once your dealing with images, and it won’t always be possible to completely adhere to your color scheme, but when you can, try to stick with photos that look like they match or compliment your color scheme. And define principles for using certain colors in certain situations. This way your site/app will appear to have more consistency.
Component Library/UI Kit
So now you’re like… way into a project. You know the route every user will take to solve every problem. You know how your navigation works and where everything is supposed to go. You know what you want the navbars, menus, and buttons to look like. You’ve settled on typography, color schemes, icons. You have all your sizing, spacing, and dimension considerations figured out. We’ve referenced Material or HIG respectively for compatibility with Google or iOS design requirements. It’s starting to come together!
The next step is to construct a design doc that lays out all your UI elements in an accessible manor. It’s kind of like a digital lego kit, just a way of keeping everything organized and consistent so that you know exactly where to find whatever you need for any possible use case. In Sketch you can classify these elements as symbols. This way, whenever you change a symbol, every instance where the symbol is used will also change:
Medium Style Guide/UI Kit
Remember when you’re designing, you’re not just designing for one screen. To make life a little easier on yourself in the beginning, try to aim for components that work well across screens. Sketch’s responsive web templates can be really helpful here.
Side note: You’ll often hear the phrases Style Guide, UI Kit, or Component Library used interchangeably. I’m not 100% on what the academic ruling is for this one, but as I understand it, style guide can refer to coding or branding guidelines, where as the other two refer primarily to product design. Though I’ve often heard the former used to describe both cases, including the phrase “living style guide” which refers to a style guide that’s regularly updated by both designers and/or engineers.
Mockups & Working Prototypes
A mockup or comp is a non-working replica of a screen from your app or website. Every element that goes into a mockup can be taken from your UI Kit. Once your mockups are ready, you can piece them together in a prototype that simulates functionality and what it’s like to go from screen to screen. More advanced designers or designers coming from coding backgrounds will sometimes hand-code their prototypes. If you don’t know how to code, you can easily produce solid prototypes (code-free) with programs like InVision, Marvel, Principle, and of course the afore mentioned UXPin and Adobe XP.
Throughout a project, designers are constantly running experiments to validate or invalidate their ideas. As you may remember from 8th grade biology, most if not all effective experiments utilize the scientific method. You can use the scientific method through the lens of UX Design to optimize user outcomes:
Scientific Method
To learn about different kinds of user experiments you can run, check out this lovely article written by the fine folks at Hansonic. But before you start running any tests, it’s imperative to learn about the cognitive biases that can contaminate your results. There are a million of them, so we’ll just touch a few biggies to watch out for here:
Confirmation Bias: An observer expectancy effect that causes researchers to search for or interpret information in a way that confirms one’s preconceptions, leading to statistical errors.
Anchoring: A tendency to rely heavily on our first impressions (or ‘anchor’ information) when making a decision. This can generate inaccurate results (false positives) in a design experiment when user testers rate one part of their experience based on another. Test in isolation to mitigate this effect when possible, or at least consider that causality might not always stem from whatever you’re testing.
Conformity Bias: When people change their judgement to conform with a group. This is a big reason good products often don’t do well or why bad products sometimes do. Network or mass effect changes our perception of what is good. It also keeps us rooted in what we’re already used to. This is why being first to market is so important.
Observer Effect: When people modify their behavior because they know they’re being studied. Not a whole lot you can do about this aside from getting out of the way.
Sample Bias: When certain members of your sample audience are over or under represented. If an idea doesn’t go over with one person or group, it doesn’t always mean it’s a bad idea or that there isn’t a market for it. Just the same, just because one person or group loves your idea, it doesn’t mean there is a market for it. The only way you’ll ever really know is to get your product out there.
When Should I Test?
The saying goes, “Test early. Test often.” I say test when you have something that needs a test. Research first. Ideate. Let your ideas incubate before you obliterate them. Let your creativity dance before you turn off the music! When you have something that looks like it’s going to require some serious resources, it‘s probably time to test. For consumer-facing applications, remember to run it against the hooked loop. The BJ Fogg Model is great for testing enterprise applications. Strive to foster an environment that screens for cognitive biases. Use card sorting or paper prototypes to test things like information architecture or user flow. If you’re looking at things like pricing points, or ad campaigns, you’ll want to run some a/b tests. Hook up with marketing people for help. They’re really good with that kind of thing, or at least they claim to be.
Avoid the Homer
Constructing a valid design experiment can often be just as challenging as designing the product itself. So when you feel like you’re ready to do some serious testing, remember the scientific method, watch out for cognitive biases, and always be sure to test the test!
Also keep in mind, your users mean well, but they are not designers. They don’t have the information that you do, and their uninformed whims can often lead inexperienced designers into making terrible design decisions.
When putting together your portfolio, be sure to tell a good story with each project. Describe your decision making process. Illustrate the progression of the project, the challenges you faced along the way, and what you learned. For portfolio platforms, check out My Portfolio, Squarespace or Wix, any of which can help you get the job done code-free. When you get really good, setup a Behance, which will give you the social proof you need to convince hiring managers that you got the good stuff.
That’s it! Thanks for reading! If you found this post helpful, please recommend it, or share it with anyone you know who might be interested in a career in product design. If you forget everything else, remember empathy, empathy, empathy! Remember the “why!”
Also, try to connect with other designers (like me). We are lonely and love the sound of our own voices. Toodles!
Special thanks to Jake Flemming, Zac Halbert, and Rachel Donné for editing.
AI-driven updates, curated by humans and hand-edited for the Prototypr community
