Once you have an idea in mind, but before you begin making a product, it is just about always a good idea to draw things out first as a way to visually communicate your idea. This form of visual communication is incredibly helpful to make sure everyone (your team members, co-designer, mentors, and even your own brain) is on the same page, particularly when trying to communicate about potentially nebulous ideas that have yet to physically materialize.

Some people – particularly students who have been exposed to computer-aided design (CAD) programs in school - may have an initial instinct to reach for the CAD software they’re most comfortable with – SolidWorks, Inventor, Fusion 360, and so on. Oftentimes, however, it is more helpful to start more simply with a sketch. The purpose of a sketch is to convey a set of ideas about a form, a space, or an activity quickly and efficiently. Sketching can help you refine ideas, realize issues about space and shape and size, and think through how a user might interact with a product without being encumbered by more detailed (and time-consuming) drawing methods.

There are various approaches to sketching that are in part influenced by your end solution's form factor, whether it be a physical product, an app, a garment, etc. Regardless, assuming a human being will interact with your solution (which is a given for CRE[AT]E), a very helpful place to start is by storyboarding.

Storyboarding: communicating user interactions

Storyboarding is sort of like drawing a comic book. You want to draw a set of cells that depict a process that shows your single-sentence product objective being met. This is the big picture, starting from before the user interacts with the product, to their use of the product, potentially in a variety of settings, and showing how it enables a solution to the user needs you identified. Because this is big picture, it can be helpful to use storyboarding to think of multiple ways that a product or process might be used and to further refine your ideas.

This part of the design process is particularly important to do with and/or review with your co-designer, as well as any other stakeholders (parents, caretakers, therapists, etc.). Co-designers’ experiences here are a powerful corrective for ideas that other members of the team may have, but wouldn’t quite work the way then envisioned because of some detail they didn’t think of, perhaps about the environment that the product would be used (e.g. the co-designer’s home), the co-designer’s abilities, the presence or absence of external help, etc. It may also reveal parts of the user interaction that you didn’t think about or mismatches between your and your teammates' assumptions of how something would work.

A good place to start is by making a list of all the actions your user would undergo with your product from start to finish (you may need to think creatively about what constitutes "start" and "finish" for your particular product or interaction), as if you were narrating their day. Then, create quick sketches (panels) to illustrate your list! There’s no need to go into a huge amount of detail here – full-on inked comic strip this is not. And you may not need all that many panels – aim for three to ten, something long enough to force you to lay out the steps, but short enough so that your focus is still on the big picture.

To see examples of storyboarding from talented designers and engineers, along with great explanations on why + how to create storyboards , we recommend the following two resources. Note that you don't need to create high-fidelity storyboards for this Challenge, but feel free to read the sections discussing them if you'd like:

• This Medium article by Cheryl Platz, who has been a designer for Microsoft and Amazon, very articulately describes the motivation behind storyboarding, shows beautiful examples, and provides tips for creating your own storyboards in the context of designing user experiences.

• Here's another approach by product designer Veronica Spencer focused on storyboarding for product design.

Drawing & Sketching Your Solution

Drawing for Physical Products

When drawing an idea for a physical product, you may start with something as simple as a line drawing. For these, you want to pay attention to proportions and shapes, but that’s really what they’re there to help you visualize. Adding shading or hatching, and choosing a proper perspective for your drawing can help give a better sense of depth in your product, and place it more firmly in 3D space. After that, you may want to add color as a way of conveying the materials of different parts of the product, as you figure out those components. If you happen to be drawing your product on a tablet, doing these steps on different layers in the drawing software can be a good way to add or remove detail as needed, depending on what you want the focus to be.

Importantly, many assistive technology products are used in a way that is very closely tied to the user, whether it is because the product is wearable, or because it is adapted to a particular physical feature of the user, or so on. In these cases, it can be important to have additional sketches that include the physical relationship between the product and the user – how does it fit, where is the “front,” how big are the parts in relation to any relevant body parts? Similar to placing the product in 3D space, this kind of drawing places the product in the user’s workspace, and can help identify body parts where you may need to get more precise measurements, or places where you can get away with more rough measurements.

“But I suck at drawing!” says many an early maker, who would much prefer the precision of CAD. Drawing is a skill, and skills take practice. This is not the book to teach you how to draw, but there are many of those out there (and many, many videos, exercises, and so on). The flexibility of drawing over CAD should not be overlooked, especially in the early stages of design. CAD had a tendency to force thinking in the direction of cubes and rectangles, perfect circles and extrusions, because that is how the computer thinks about designs. You don’t want to get boxed in too early.

But… eventually you may want to go to CAD. This step is not always necessary (or appropriate) for physical products. CAD for many soft products, for example, is still a relatively immature and niche technology that is likely not worth the learning curve for a maker-style product design cycle. However, when it is appropriate, the amount of detail that CAD software forces you to hand before it renders your design can be a good way to step through decisions about lengths, and volumes, and details like how things are connected, or what edges need chamfers or fillets. CAD is a powerful tool, but be careful not to use it too early.

Drawing for Software and User Interfaces

What if you’re not making a physical product? In software, drawing can become an even more integral part of your prototyping process than in hardware through the use of paper prototypes . Paper prototypes are sketches that represent different “screens” that a user would see during an interaction with a piece of software. At the most basic level, they can be hand-drawn, and help your design team figure out the workflow of the software, the look and feel of an app, and things like what information needs to be on which screens, button sizes and placement, and so on. They are also instrumental for early user testing.

Much like how drawings for physical products often get turned into CAD in later iterations, sketched-out paper prototypes will often give way to computer-based versions of the same, using tools like Figma, Canva, Adobe XD, or even PowerPoint, which can replicate some of the common features of software interfaces a little more accurately, and allow for more seamless testing as button clicks may actually be made to respond by moving on to different screens.

Sketch-based paper prototypes still have an early advantage in that they are more flexible during your testing, and can allow you to change things on the fly more easily, even during user testing. You can imagine how quickly you might be able to test a change in the size of a button, or how the next screen looks, just by drawing it as a user steps through the interaction with the product.

Here are some tips for making paper prototypes of apps or other graphical user interfaces:

• Think through all the interactions necessary to successfully use your app/piece of SW: did you forget a button somewhere? What about small details like a menu icon or settings?

• Make these roughly to scale: if you expect your co-designer to interact with your piece of SW on a smart phone, your paper prototypes should be the size of their phone screen. If too large, you may over-estimate the amount of content you can fit on one screen or neglect usability requirements around text legibility.

• Don't get caught up on little details like colors, background patterns, etc. just yet. At this stage, it's best to keep your prototypes simple so you can focus on the user interaction and quickly make adjustments as needed.

• Be flexible! If you realize you should add/subtract an element or modify your prototype in any way based on user feedback, be ready to quickly do so with some Sharpie magic.

• When testing, it can be helpful to designate 1-2 team members as the "paper flippers" who will place the next "screen" in front of your co-designer based on the last button they pressed. One team member should work alongside your co-designer to help guide them through the interaction and answer any questions, being careful not to lead them to any particular interaction pattern (you're trying to learn what they would naturally do if given your app). You can also instruct your co-designer to verbalize (if possible) a) what they want to happen next at any given moment, and b) what they expect to happen when they press a button / otherwise interact with the prototype. Finally, it's also quite helpful to film your testing session so you can review the interaction pattern desired/expected by your co-designer.

• You might need to go through this design + testing process more than once. Once you've ironed out the interaction pattern and met your user needs through paper prototyping, you can translate to digital!

Digital Drawing Details

Raster-based art typically refers to art saved digitally as an image with pixels. Think about zooming into a photo and seeing it become more pixelated as you do. DPI refers to dots per inch, or the quality of the file you're saving. A higher DPI is a larger, but better quality file better suited for very large images. Raster files are saved with DPI settings in common formats such as .jpg and .png. Examples of design software that are raster-based are Photoshop, Procreate, Gimp (free), and Paint.

Vector-based art typically refers to art saved as a reference to various lines and shapes. This is more scalable - a vector file will easily scale because its information is encoded in equations to form lines and curves and bodies that can be multiplied by a computer. This is the preferred format for designs that will be translated to CAD for manufacturing processes like 3D printing and laser cutting. You can better specify dimensions and scalable design intent for physical products with vector-based images. Vector files are saved in formats such as .svg, .pdf, .eps, and .ai (for Adobe Illustrator). Examples of design software that are vector-based are Adobe Illustrator and Inkscape (free).

Digital drawing in both raster and vector forms can be turned into directions for a laser cutter, making it possible for you to go directly from a drawing to a physical product in some cases.