Design Manifesto
INTRODUCTION

Design Manifesto
INTRODUCTION
Over the course of this semester, working on different design projects and going through design processes has taught me a lot of new strategies to consider when designing something. I personally took away that the most important thing about a design process is clarity. Whether this is about a certain component of an idea, or about who a design is being made for, a good design cannot be made to reach its fullest potential without clarity in the design process.
POINTS DEFINING THE DESIGN PROCESS (FOR ME)
Various ideas help the designers achieve clarity during the process. These include: rough sketching, interviews, design sheets, low-fidelity prototyping, and evaluation statements. All of these things come together to create a productive design process, and thus, lead to the making of a good final product.
ROUGH SKETCHES
When brainstorming and coming up with a myriad of ideas, I have learned that sketching these ideas out helps a ton. Similar to design sheets, it helps visualize every idea (of course it is not as structured a process, since this is just free brainstorming, sketching down whatever one can think of) and compare them more efficiently as a result, since we will have a working image of the idea in our minds.
Rough Sketches for the Health Design Project
My post about this project: https://medium.com/@namansahni2001/health-design-708ea2b9479a
For this individual project, I came up with and made a low-fidelity design for an app that people could use to create personalized workout plans, with easy access to workout tutorials. When initially deciding on a design for each screen and its components, I made rough many rough sketches for each screen, experimenting with as many different features as I could. Here is an example of the home screen.

Idea 1

Idea 2

Idea 3

Idea 4 (left) and Idea 5 (right)

Idea 6 (top left), Idea 7 (top right), Idea 8 (bottom left), and Idea 9 (bottom right)
As can be seen above, I experimented with lots of different layouts for the homepage. This showed me the strengths and weaknesses of each layout and component much more clearly than just thinking about it or writing it down would have. For instance, from sketching out ideas 1, 4, and 6, I saw how cluttered the home screen would look if it asked for such information as shown in those sketches on the first screen. It also showed me that this made the welcome screen seem extremely unwelcoming, by straight away asking the user a bunch of questions and forcing them to do a bunch of reading; it made the app devoid of any personality. With idea 3, I checked to see how having a background image would look. And this drawing showed me how apt it was for this app. It gave the user an idea of what the app is all about, without having a big block of text on it. I also added a welcome message to make the users feel comfortable. Learning all these things led to me putting it all together and coming up with the final design for the screen as shown below.

The final design I settled on
Thus, rough sketching of the ideas flowing in my head helped me a great deal in deciding what works and what does not. It is an exceedingly simple yet efficient practice for figuring out good components for a design.
INTERVIEWS
Sources I read about and incorporated this technique from:
*https://hci.stanford.edu/courses/cs147/2021/wi/readings/FIELDGUIDE-Screen-DTBC-March-2015-V2.pdf*
Interviews are an integral part of the design process. They require a clear understanding of a design’s target audience so that the right people can be interviewed, and good feedback can be received and acted upon. Knowing the target audience also allows one to think about end-users (users on either extreme of their target). Forcing me to consider the target audience first and foremost, helped me to look at the design from an outside eye (that of the audience), rather than my own, thus reducing biases in design. In other words, it helped design for the masses, rather than for myself. Since the target audience is interviewed, the feedback is always significant, no matter how minor it may seem. It allows one to fine-tune the design to fit the wants and needs of the targets perfectly.
Interviews were included in most of the projects I worked on over the semester, whether individual or group projects. Here are a few examples.
Interviews for the Needfinding Individual Project
My post about this project: https://medium.com/@namansahni2001/needfinding-8db19d47d30
For this project, I was thinking of a design for an app that would help people create workout plans based on their personalized settings as well as provide them with easy access to workout tutorials. Its objective would be to basically rid people of anxiety regarding working out and instead get them excited about it. People get intimidated by working out a lot, and I wanted this app to combat that. So, I figured out that my target audience is people who have maybe worked out a bit in the past but are complete beginners, which would suggest some anxiety or worry regarding working out. This allowed me to interview some people fitting that target, as well as an end-user who has been working out for a long time. Interviewing them provided me with so much feedback that I incorporated into the next project, which was prototyping this design idea (will be discussed later in the Low-Fidelity Prototyping section). The feedback I got was so relevant and I was able to really understand my intended audience’s inner thoughts and opinions on working out and the idea and potential components of my app. I was able to add new components, improve old ones, and remove obsolete ones, making my design much more appropriate for my audience.

My sheet of notes of questions I asked (there were of course improvised questions too in the heat of an interview)
For these interviews, I created empathy maps to understand the needs of the users. Here is an example.

Empathy map for one of the interviewees
This was just a convenient way of listing feedback for this project. For the group projects, we simply listed the relevant feedback in a more straightforward manner, with just points listed down.
Interviews for the Virtual Reality Project
My post about this project: https://medium.com/@namansahni2001/design-for-another-world-witchs-cauldron-6e3daaf8e24d
Again, in the same way, we first made sure we knew what our target audience would be for the VR potion brewing/cooking simulator that we wanted to make. Our target audience was decided to be people who are familiar with the concept of VR and VR gaming but are not necessarily avid VR gamers. We chose this as the target as we wanted to make something that would be appealing or inviting to all types of people, rather than a niche for just a small set of hardcore gamers. Thus, having clarified this, we were able to interview such people, as well as a couple of end-users, who either had not played VR at all or had a good amount of experience or knowledge about VR, more so than the average person. Here are the questions we came up with (there were, of course, impromptu questions in interviews not listed here).

Interview Questions
Here are the responses we received.

Responses to our interviews
These interviews, once again, provided us with great feedback and ideas that we incorporated into our final design. They also helped us understand what the majority likes, by looking at common answers among interviewees. For instance, one significant commonality was the audience’s preference for free play over a timed mode. We had been struggling to decide which mode to give priority to, and these interviews completely alleviated this struggle, by telling us point-blank what the intended users want. In addition to these interviews, we also asked a group of students in the library to pick between two design templates. We were unsure whether to make our game look more realistic, or more blatantly like a game (an artistic choice that has worked for many games in the past). We asked this group which template they like more and why. This provided us with the general opinions of the populace, rather than our own as biased designers, and forced us to choose what they liked since that is what the masses prefer and that is, of course, who we want to please to have a successful product. Thus, this is yet another example highlighting the importance of interviews and how they can go a long way in figuring out designs and ideas.
Interviews for the Physical Prototyping Project
My post about this project: https://medium.com/@namansahni2001/re-design-and-extend-the-emory-claw-stuff-cs-machine-a1a7a8b07631
For the physical prototyping project, we, once again, used interviews to pick between features and improve on our existing idea of the crane machine. Since this machine was to be a physical prototype for the Emory CS department, our target audience would be current CS students at Emory. This also allowed us to find end-users who would be students not majoring in CS.
Here is a list of questions we asked.

Interview Questions
Here are the responses.

Response 1

Response 2

Response 3

Response 4
These responses, yet again, gave us user opinions on our existing ideas and components and suggested to us how to improve them and what more to add. As an example, a common feedback we got was students being confused about courses for the CS major, the order in which to take them, etc. This strongly motivated us to work harder on making the course tree and also on its accessibility.
DESIGN SHEETS
Sources I read about and incorporated this technique from:
Design sheets using the Five-Design Sheet approach is something I was introduced to this semester. It was a game-changer. It made the design process so much easier and comprehensible. It involves one sheet of a rough design idea, up to 3 sheets of specific components of this design idea, which helps iron it out, and then one last sheet of the final design idea. This is a really good way of displaying the progression of an idea, as well as all the components of a particular design. The design sheets, of course, differ slightly with the type of design. That is another thing I like about them, their flexibility. Here are the design sheets for some of the projects I worked on this semester, to further explore and display the usage and usefulness of these sheets. First, we are looking at the sheets for the data visualization project I worked on earlier this semester.
Design Sheets for Data Visualization Project
My post about this project: https://medium.com/@namansahni2001/design-for-understanding-aliens-real-or-not-6bc9bc180f6

Design Sheet 1 for Data Visualization Project
As described, and as can be seen in the picture above, design sheet 1 talks about the basic idea for the visualization of the statistical analysis of the UFO sightings dataset. It also makes it easier to understand by dividing the sheet into different sections: the original rough ideas, filtering out (removing some ideas, while keeping others after group discussion), describing the separate categories of the visual, how these categories will be connected to each other, and finally, questions that these design ideas aim to evoke in viewers and answer.

Design Sheet 2 for Data Visualization Project

Design Sheet 3 for Data Visualization Project

Design Sheet 4 for Data Visualization Project
Moving onto design sheets 2,3, and 4, these describe the specific components of the visualization design. These descriptions include the layout of the component, the focus of the component, the operations the design will include, and a discussion about the component, weighing the pros and cons of its traits. These sheets help understand the inner workings of the design and also help the designers evaluate the best and worst parts of their design, allowing them to edit it in whatever way required as a result.

Design Sheet 5 for the data visualization project
Finally, design sheet 5 takes all the information from the previous sheets and summarizes the final idea based on this information. It is a step-by-step process and really aids in making it easy to continually improve on the design and refine it. For further evidence of this approach’s efficiency, here is our final design of the analysis visualization and the demo video.
Analysis team visualizations: https://public.tableau.com/app/profile/andy5659/viz/UFOVis/FinalDashboard?publish=yes
Analysis team demo video: https://youtu.be/Ojy7ddlO-vQ
The final design exemplifies just how much we took from the design sheets, seeing how the operations have been implemented as described, the pros and cons have been weighed and improvements have been made in the final product as a result, addressing these points. It is a really good way of making one’s design better and closer to the best it can be.
Here is an example of design sheets for our physical prototype project, just to show the approach’s flexibility.
Design Sheets for Physical Prototyping Project
My post about this project: https://medium.com/@namansahni2001/re-design-and-extend-the-emory-claw-stuff-cs-machine-a1a7a8b07631

Design Sheet 1 for the physical prototype project
Again, sheet 1 had many ideas, some of which we incorporated, and some of which we got rid of.

Design Sheets 2, 3, and 4 for the physical prototype project
Here, these three sheets describe the different components of the claw machine roughly described in sheet 1. Sheet 2 talks about keychains with scanners linked to the Emory CS website, which we included in our final design.

Play-doh keychain next to an example of an NFC reader that has been put inside it
Sheet 3 talks about a course tree for a CS major, that we also made and linked to an online version of said course tree.

The course tree
Sheet 4 talks about putting all these together into our crane machine idea, which again we did, resulting in the following.

The CS Machine!
Once again, these sheets, while for a completely different type of design (data visualization V.S. physical prototyping), remained largely the same in concept and achieved success with both. The sheets allowed us to brainstorm and expand on ideas and even connect them together in creative ways. They also made it easier for us to picture the components through the sketches and almost gave us a manual to simply just copy our design from the sheet into a different medium.
LOW-FIDELITY PROTOTYPING
Low-fidelity prototyping is a component of the design process quite connected to all the others mentioned. It is almost a direct next step to rough sketching, pushed to the extreme. It is a cost-effective as well as time-effective way of examining how a particular design operates overall. A low-fidelity prototype should be able to perform the significant functions of a design so that the designers can evaluate what works well, and also allow others to experiment with the prototype, and provide feedback on the design. All in all, it is just another way of assessing a design’s current state, which works extremely well.
Low-Fidelity Prototyping in the Health Design Project
My post about this project: https://medium.com/@namansahni2001/health-design-708ea2b9479a
For this project, I made a whole interactive prototype of my app and its various screens, using paper cutouts. Here is an example of one of the screens and its low-fidelity prototype. I am showing the Workout Plans screen of the app as it has the most interactivity. The screen below shows the different workout days involved in the current workout plan.

“Workout plans created” screen
Clicking on either one expands them, showing the exercises to be done on that day. I displayed this interactivity through an extra cutout of paper as shown below.

The exercises to be done on a certain day
If one clicks on “Expand”, then the description of the exercise will expand. If one clicks on the play button of the video to the right, a video from a credible source opens up and shows a tutorial of the specified exercise. This interactivity is shown below.

Expanded workout information and workout tutorial video
This was a simple example of a low-fidelity prototype. All I used was a pencil, a notebook, and a pair of scissors, and yet, I was able to so efficiently communicate the specifics of the design ideas and the workings of the features of my app. This is why I think low-fidelity prototyping is essential to the process; it depicts all the important required things of a design, with minimal resources, and is extremely easy to achieve! I cannot imagine a design process without this.
Low-Fidelity Prototyping in the Physical Prototyping Project
My post about this project: https://medium.com/@namansahni2001/re-design-and-extend-the-emory-claw-stuff-cs-machine-a1a7a8b07631
The crane machine we made for this project is another great example of effective low-fidelity prototyping.

The CS Machine (again)!
The specifics of this design have been talked about in the design sheets section already, so I will not repeat them all here. The important point to make here is that this prototype that we made — using cardboard and Play-Doh— of our ambitious idea, so clearly highlighted what we wanted to achieve with this idea, given more time and resources. It had all the most important aspects in it, consisting of the crane used to grab keychains with NFC readers linked to the Emory CS website and a course tree. Once again, a prototype with minimal time and resources involved helped display the main function of an idea, while also providing a base or skeleton for future improved designs.
EVALUATION STATEMENTS
Evaluation statements provide clarity to the designers about their own designs as well as to potential users, just like the other points above, except in a different way. While the other points focus on feedback and visual aid, this point helps simply through the text itself. Coming up with evaluation statements is not straightforward. It forces the designers to think intimately about their entire design idea as a whole and come up with apt statements relevant to this idea. This leads to the designers gaining a clearer understanding and objective of their ideas, and it also provides users with a concise explanation of what the design is and how it works, and what it wants to achieve.
Evaluation Statements in the Virtual Reality Project
My post about this project: https://medium.com/@namansahni2001/design-for-another-world-witchs-cauldron-6e3daaf8e24d
Here are the evaluation statements we wrote for this project. I think these are great examples of evaluation statements.

Evaluation statements
Here, the design goal statement provides a clear description of what the main idea is, the user experience statement explains the interactivity idea of the design, the realistic statement sets achievable standards and objectives for the project given the time and resources, and the stretch statement sets ambitious standards and eventual objectives for the project, given an ideal amount of time and resources. As mentioned before, these statements provide the target users with a precise idea and objective of the design. It also helps the designers make a layout for their design, making them set goals, timelines, and expectations for the project. It definitely did so for our project, as it helped us all be clear about what we wanted to achieve in a week and aided us in staying on the same page and working efficiently.
CONCLUSION
I believe, through repeated experiences, this semester, that rough sketches, interviews, design sheets, low-fidelity prototyping, and evaluation statements all go hand in hand in providing cohesive, well-rounded clarity during a design process. They make clear what the target users want from a design, what in the current design works and what does not work, what are the pros and cons of a design, what is the future of the current design, and what is achievable in the design idea given one’s time and resources. To make the best design that you are capable of, including these techniques in the design process will do nothing but help you get there as it did for me.
메타데이터
- post_id
- 1eccb211673a
- slug
- design-manifesto-1eccb211673a
- url
- https://medium.com/@namansahni2001/design-manifesto-1eccb211673a
- canonical_url
- https://medium.com/@namansahni2001/design-manifesto-1eccb211673a
- author_url
- https://medium.com/@namansahni2001
- status
- ok
- fetched_at
- 2026-06-27 23:56:40