Background and Concepts

Have you ever wanted to learn a new language, but struggled to get engaged with the learning process? Our Korean Language Exchange website seeks to resolve this problem by giving users the opportunity to study and learn together, enhancing their personal connection to the language and the process. This is accomplished through demographic matchmaking and video calling, among other features that enhance the user experience. Our users will gain a deeper, more personal understanding of the Korean and English languages through these cross-cultural connections and practices.

This was my Junior Design project at Georgia Tech. We developed the project in its third iteration over the course of two semesters under a client. The course’s intended purpose was to introduce us to a work environment outside of college, similar to what you might see at a computer science company. It included client and team charters, designing/drafting, researching users, LoFi and HiFi prototyping, an Agile development cycle across six sprints utilizing Jira, documenting every aspect of the project, writing memos, and other smaller duties.

Our client was an associate professor of Korean in the School of Modern Languages at Georgia Tech. This was rare among our peers, as many other teams’ clients were outside of the college, but it did present us with a very unique project. Georgia Tech has an exchange program with Yonsei University where the “exchange” is students of each school having the opportunity to study abroad. It is an amazing way for students of each school to learn the culture of the other school and country. Our client is one of the key figures in this exchange program, and he is also the head professor of Korean 1001: Elementary Korean 1. He recognized that learning a language by reading off of slides or flashcards does not get anyone engaged or culturally knowledgeable about the language and its practices. He sought to use the exchange program as a way to “exchange” languages. Rather than the typical language learning practices, he envisioned students studying Korean at Georgia Tech engaging with students studying English at Yonsei University and exchanging their culture alongside the languages, creating a much more engaging and culturally rich study environment.

Learning Curve

Okay, this may be the hardest project I have ever worked on. It was dang well at least the longest! Multiple factors contributed to the challenge of this project, pushing both my soft and hard skills.

As far as my soft skills were concerned, it was one of the most difficult projects I have had to manage. Let me start off by saying that I am in no way blaming my teammates for anything. Although they did challenge me on occasion, I for sure challenged them as well. We struggled as a team I assure you. It was primarily just the situation of our project. Iterating on a project over the course of eight months is a lot. I recognize that this is nothing compared to the length of projects I may work on in future jobs, but it was especially a struggle when we were the third iteration of the project with no documentation to look back on, hardly any of the core ideas of the project were things we had a say in, the actual course was not very friendly to continuation projects, and myself and all of my teammates had tons of other responsibilities, including other courses, internships, jobs, and even freaking getting married! All of that on top of our project responsibilities was just a lot, and I was barely able to keep it together, but it did get better over time. The beauty of having a project this length is that you get to iterate on yourself as well. I started not knowing my team well at all, especially their strengths and weaknesses as designers and developers. I assigned them to tasks that were not their forte, and it set back the project on occasion. For example, I assigned my teammate who was very experienced at MySQL to update our Agora.io features, unknowingly removing him from focusing on our MySQL for the entire course of the project. This forced another teammate to take up that responsibility; however, he was an amazing UI/UX developer, which our project desperately needed, so the MySQL work took time away from the UI/UX work. As you may can tell, I regret some of my managerial decisions… Over time, I grew to understand each of my team members and started recognizing these strengths, and by our last sprints, we were knocking tasks out a lot more efficiently. I will not take all of the credit, however, because a lot of that came down to us learning our tech stack over time.

As far as my hard skills were concerned, this was the hardest project I have ever worked on, no competition. As stated, the situation of our project was just not the best. Going into the project, we knew it was a continuation, and we assumed it would be fairly easier since a lot of the groundwork had been laid. Unfortunately, that groundwork was pretty shoddy. We had zero prior documentation which made it very difficult to work with the tech stack that we were given, especially the various APIs/SDKs we worked with. And since we worked on the third iteration, our codebase was pretty expansive. It made it very difficult to fully grasp what we were working in/with. This all resolved over time and with some extensive research. The only thing we had was the previous iteration’s repository which did not even work when we cloned it, and that rang true for many of the existing features in the project. It was extremely hard to develop new features when the previous features broke, and I hate to say that because the previous iteration did a lot of good work. One of the previous members of that iteration also told me that they inherited the project in a shoddy state as well, so it seems like it came down to no iteration having the time, ability, or objective required to get this project to a better state. I know for certain one aspect of this was the course not being super friendly to continuation projects, as I also previously stated. It seemed like every sprint we had to have new features, and because we were so focused on implementing new features and the old features just kept breaking or creating problems, we sunk further and further into a project that was simply not presentable. It all worked and we did do some good work, but it looked and functioned poorly. Thankfully, our professors recognized our struggles, and after having a difficult talk with our client where we explained how we would have to drop a feature he wanted in, we wiped our sprint 5 clean and focused solely on improving our UI and functionality. Let me tell you, it felt so great. We could actually see our hard work pay off in a fully functioning application that looks amazing. And the best part came during our Expo where multiple people, both judges and students, were very enamored by and interested in our project. When you get so sunk into a project that is beating you down, it is very hard to realize that you are making something potentially really good and interesting. It seems our hard work really paid off.

Development

The entire course/project was broken up between two semesters, with the first focused more on designing, drafting, prototyping, and researching and the second more focused on the actual implementation.

Research and User Stories

Following our team and client charters, we first created a vision statement detailing our motivation and potential users for the application. This led directly to our researching potential users, who we determined are primarily students at Georgia Tech learning Korean. This application has a lot of potential to be expanded for future languages, but that was beyond the scope of our iteration, unfortunately. We also really wanted Yonsei University students studying English to be a target audience as well, but that also fell out of scope. Because the application needed a lot of improvement work, we were primarily focused on expanding on current features or making existing features work better, so brand-new ideas and scaling the application up were not the primary objectives. I did our primary research, where I chose to do a post-event protocol on a student who previously took Korean 1001 at Georgia Tech. The main question I sought to answer was: Does this application accurately engage students in learning Korean? Since this is the third iteration, we decided that the best course of action in the progression of the application is to first understand how students react to it in its current state. The best method of achieving this was the post-event protocol since it allows us to observe students viewing the application uninterrupted as if it were the final product, and having a participant who previously took one of Tech’s introductory Korean courses can give us direct insight into what their specific needs are. We needed direct feedback on the application and this method gave us the best representation of that. The feedback we received was down the middle. On one hand, the concept really intrigued the participant and they loved how inclusive it felt. On the other hand, the participant stated what we already knew: The look and feel of the application was poor. All this told us was to strengthen what we already had, which directly influenced how we went about development starting with developing user stories. While these were the first drafts and got reset following the conclusion of the first semester, developing user stories helped our team understand exactly who we are making this application for, why they want it for, and what we need to do to meet their expectations. An example user story was: “As a user, I want to propagate a friends list so I can continue to chat with previous partners whom I connected well with.”

Minimum Viable Product (MVP)

Developing our potential users allowed us to map out our project's iteration. This was done by creating a Minimal Viable Product, which implores many Minimum Marketable Features (MMF) that connect a variety of user stories into actual goals and tasks. Like with many development cycles, this fluxuated as we went forward.