“Progress doesn’t always mean the next phase of the process sometimes it’s just the opposite.”
One of my favorite quotes is from Yvon Chouinard “When everything goes wrong, that’s when the adventure starts”. I like to think that’s how this project began. I’ve had a passion for education and wanted to start in on a project to teach people something. One of my best friends that I’ve been on numerous adventures with, Austin, majored in computer engineering and has a passion for coding firmware and hardware. The part that went wrong in our eyes, is once we printed all the books, and we learned how to build these complex machines with all sorts of moving parts, we stopped challenging and progressing in our materials we used to teach it.
I set out to start branding, this project. I needed a name, logo icon, colors, themes, fonts, and general look and feel for the product. I knew this project would just be the first steps in likely a much bigger project, but for the purpose of this write up I wanted to focus on the branding. In order to achieve that I was going to need to start down the road of the product to build parameters and context for the decisions I was going to make but that I needed to start somewhere.
My process I took follows a general Design Thinking process which consists of in order: empathize, define, ideate, execute. The empathize and ideate phases will broaden the project and thinking, and the define and execute will narrow it down.
The first steps I took was to talk with Austin at length about who we were going to do what for. Understanding our audience, their challenges, goals, and how that related to the job market, education, current infrastructure for learning, and what role we could play allowed us to look big picture and broaden out our ideas of teaching hardware. We talked about who all could benefit from our product, made note cards gave these people real names and created personas. We looked at what options they had available to learn these principles. How did those products brand themselves, who else was in the eLearning market. We found that no one was teaching hardware specifically. They were all teaching software, how to code apps, programs, and websites. We needed to make some leaps into what we were going to do ourselves. I started to find people that I knew or sort of knew to talk to about their experience learning firmware and hardware, I then reached out to some college friends who were currently learning about computer engineering. This built a lot of empathy to understand in more detail who my audience was. Two other important audience members were eLearning sites/bootcamps and professors, they would need to have some interest as well in using our product as they would be more closely tied to making purchasing decisions, and would be using our product to oversee their students learning. I had conversations about integrating this into their lesson plans they already had, how this could benefit their in-class lectures, and speed up the grading process. They gave me a lot about what they might expect from the product or what could help them better mentor a student and not have to worry about the boring parts of their job. At this point I had broadened my knowledge on the subject with empathy and listening to our intended audience.
I needed to categorize, group, and compartmentalize what I learned. Generally we had 3 types of students:
– College students, and possibly high school students
– Bootcamp/eLearning site students
– Individuals or self learners
Each of these would need slightly different user interfaces in order for them to accomplish their learning goals inside of their environment. The thing that did not change across the three was interests and desires of the student themselves. While a college student might need to have their grades seen by a professor, or a individual need some sort of certification they could show a potential employer, all of them had a need for re-assurance, each had a ‘nerdy’ side, most of them liked video games with an above average baseline, and enjoyed specifically story/adventure based games. I needed to consider this, I needed it to be modern, but not too kid like, and needed to include progress capture and ways to see how they are moving through the information toward a goal. It needed to be fun and self-aware that the subject material is on the more technical ‘geeky’ side of things. What coder doesn’t dream of being ‘the guy in the chair’ like Ned from the recent Spiderman movies aspired to be. One of the ways I began to organize this information was with notecards, a lot of my processes involved note cards. I put down key points of information on lots of different cards, and used those to organize them into groups and collections.
I needed to start on the name. This stage of the process needs me to broaden again and look at lots of possibilities. Here is where I think there are lots of ‘wrong turns’ or ‘bad ideas’ made. I know for myself I need to get those things out, like a truck hauling a porta potty trailer, it’s better if I call it what it is and let it pass by instead of parking it on the street and trying to avoid it. We threw out a variety directions for ideas, we thought we might go with, from things like greek gods, or elements, or random nouns generated by AI. I eventually turned back to a process I have always enjoyed called ‘word-mapping’. I wrote something in the middle, hardware, and then drew lines with words that came to mind from that, and then expanded from there, over and over again until I had hundreds of words, ideas, scribbles, phrases, etc. I felt a bit stuck and I will talk more to this in the challenges section, but here I began to start down different roads executing on several of these names and trying to create a logo mark to go with them.
Over a two week period I went back and forth with Austin over 6 or 7 different name ideas and dozens of logo mark ideas for each. We started to narrow down and landed on Diode. Diodes are integral to any system working, they allow for change in direction, they turn things on and off, they move information from one place to another, they are the gate that needs to be passed through if you are going to accomplish anything. We wanted our product to be that gate that someone who wanted to learned and code complex things can pass through to get to where they wanted to be. Diode was also a very simple 2 almost 1 and half syllable word that could be mentioned easily in passing, in class, and amongst friends. Diode would also be an easily recognizable part by beginners and experts in the field. I then began looking at symbols on technical drawings that represented different types of diodes and decided on the Junction Diode. It functions as a gate often in solar cells by pulling in energy and pushing in a new direction. When used in the opposite direction it is used often in Light Emitting Diodes. I thought this was perfect for what I wanted to represent. The ability to absorb energy (or information) and then push in a new direction, or to take energy and have that ‘aha’ moment and a light bulb turn on for you. The logo mark then after 100’s of sketches focused on mixing the capital D from diode and the symbol for a junction Diode. I selected a bold stable font, something grounded, a small nod to a term in working with circuits and power. I wanted I created a bit of flow by causing the D to wrap and not be fully connected and notched the top left to tie in the angular look of busses and copper wiring on a circuit board.
After this was finished I moved onto fonts, and colors. The process was a bit more convoluted as I needed to start into designing the product itself in a prototyping program and following a UX process. I followed similar steps as above, using cards to list out requirements and actions users needed to take or view. Then organizing those into a screens. I took those and turned them into a box diagram. From here I had to get definition on possible flows that user might take to accomplish their goals in the product depending on their persona; professor, college student, individual learner, etc. Here I broadened outwards again in ideating on how the screen might include all of these needs in different types of layouts. Here is where I started to understand and make decisions again in execution of the design. I had to come up with styles, fonts, and themes in order to put the screen together. I again had to move back and forth from ideation to execution and even back to definition from time to time to better understand what question I should be answering.
All in all, I have created what I think is a solid guide for the product to move forward and create several different patterns that speak to the user’s and express the sentiments we want to share with those who are trying to learn a this new skill.
I think the biggest challenge here was the cyclical process of pushing forward with the design of the product, and then working on the styling, and then forward again on the product with the updated styling. The process of ebbing and flowing like a wave was a principle I mentioned quite a bit in some of my progress captures. This idea or concept was by the far the most helpful, my mentor in this project helped me to understand that the process isn’t perfectly linear, that one step doesn’t finish entirely before we take the next step. Being able to take a step back during the process and ‘ebb’ back into ideation phase gave me the exact perspective I needed when I ‘flowed’ back into the execution phase of the process.
Here is an overview of my project in video form.
Insights and Takeaways
To me the golden nuggets really came out of trying to define clearly. the process and figuring out how to make the definition work more fluidly to cover this idea of floating back and forth between ideating and executing and back to the problem space as well to better define my questions in order to not only solve the problem, but to solve the right problem.