G-Code Connect
End-to-end design of an academic support platform for a coding bootcamp
End-to-end design of an academic support platform for a coding bootcamp
Overview
G-Code is a non-profit that helps under-employed Black, Brown, Indigenous women and non-binary people break into tech through an online coding course. As part of the effort to improve student retention and graduation rate, my team helped G-Code build an online learning community and office hours scheduling platform. As the only designer on the team, I did the end-to-end design and the project was shipped in 2023.
My Role
Team
Project Type
Design Timeline
Solo Product Design
User Research
Design Systems
Branding
1 Product Manager
1 Tech Lead
4 Front-End Engineers
6 Back-End Engineers
Community project for a local non-profit
Shipped
3 Months, Fall 2022
G{Code} is a non-profit that helps under-employed Black, Brown, Indigenous women and non-binary people break into tech through an online introductory coding course, with a unique community-focused model.
Problem
G{Code}’s mission is to help underserved students thrive through mentorship. However, because instructors are volunteers, they hold virtual drop-in office hours irregularly and notify students last-minute via a Slack Bot. As a result, student feedback shows that they couldn't always get help timely. In many cases, this made them fall behind, thus decreasing student engagement and retention rate.
Through user research, identified three problems that made getting academic support difficult -- scheduling friction, inflexibility with the current system, and the feeling of imposition when asking mentors for help. To solve these problems, I advocated for creating a platform that's different from what the spec initially asked for.
Tech Stack
Getting Started
Traditionally, JumboCode expected designers to work with little or no research. But, since our spec was too broad, I advocated for research. First, I took the initiative to do a stakeholder interview with the Director at G{Code} to understand their organizational needs, challenges, and the success metrics of this project, and got contacts for user interviews.
User Interviews + Insights
Then, to understand the tasks students do when they get stuck and identify potential pain points, I conducted 8 semi-structured interviews with G{Code} students and instructors.
Through analyzing user research, I identified 3 major pain points that deterred students who need assistance from receiving help.
The drop-in office hours usually don't work, but requesting sessions takes back-and-forth.
If office hours are not available, students can't get enough support.
Most G{Code} students never learned to code in a formal education setting, so many expressed feelings of imposter syndrome and some feel like asking for instructors' time is an imposition.
Goal: Make booking office hours fast across all use cases. We wanted to maximize schedule overlaps by letting students choose from instructors' marked availability in a few clicks.
The PM and I discussed the user flow and showed it to the Developers. We decided which features we wanted for the MLP and Blue Sky based on implementation feasibility.
We seek to create a system where students can get help regardless of appointment availability.
The first challenge was to decide how we display the calendar, the interaction of time selection, default appointment duration, and information hierarchy.
The Engineering team proposed the list view (Option 1). Though this would be easier to implement, the long scroll it takes for students to sort through all availability was against our design goal of efficiency. So, I made some quick wireframes to suggest alternatives.
We couldn't decide between the Monthly Calendar (Option 5) and Weekly Calendar views (Option 6), so I prototyped and tested the initial iteration. After several rounds of iterations and feedback, I made the scheduling tool more customized to G{Code} students' needs.
• Users don't find the monthly view useful
• Users were confused about the group sessions. They thought some available sessions weren't available, so it took longer to select a time. They also overlooked the 60 minutes option.
• Some users only wanted to see availability of a preferred instructor, but there is no way to do it.
• Users prefer this iteration since they only schedule a few days in advance. It's also easier for engineers to implement
• Eliminated clutter, as most students need 1-on-1 appointments at 30m duration
• Allow students to filter desired day, time, or instructor
Some students are anxious about cold-messaging instructors. Asking for help can feel like an imposition, and admitting that one needs help can feel like a sign of incompetence.
To our surprise, users prefer the weekly views over the side monthly calendar view, which was common amongst competitors. It is because they only schedule office hours a few days in advance, as assignment deadlines approach.
To our surprise, users prefer the weekly views over the side monthly calendar view, which was common amongst competitors. It is because they only schedule office hours a few days in advance, as assignment deadlines approach.
Another Round of User Testing
I ran more sessions with 5 G{Code} instructors/students. I designed tasks, and asked them to think aloud as they share their screen while using the click-through prototypes.
Referring back to user research, students often search independently and ask peers from their project groups if office hours are not available. However, it's hard to get answers from peers outside of their project groups. It's also hard for beginners to search CS forums, since strangers tend to explain solutions in concepts beyond the G{Code} curriculum. Several students and instructors expressed interest in getting a Community Forum.
👀 Thus, I proposed this feature to my PM, allowing students to ask questions to all instructors and students, and for instructors to post resources. Over time, this will become a curated knowledge base for students years to come. The design goal is to increase flexibility of the academic support system, giving students more control over how they get unstuck, in ways that fit their time the most.
After a few brainstorming sessions, I experimented with all different ways of walking users through training process: steppers, a training guide section, tips, navigation bar, training guide page…
✅ Increase scannability. Users prefer to search by the subject line first to digest information faster. Though the side by side view show more results, the details were not relevant in this stage.
✅ Suggest solidarity. Users said the questions with fewer "upvotes" in the original iteration could be ignored, so I changed upvotes to emoji reactions
✅ More efficient filters. The new iteration allows combining multiple filters, by week and by topic.
🥷 Referring back to the personas, we know that some G{Code} students experience imposter syndrome and they worried about being judged. Having an option to ask anonymously encourages more students to clarify their concerns.
I found that focusing on mentors' professional journey doesn't help users feel more comfortable reaching out. So I replaced "About" with a "I'm happy to help" section, adding instructor availability to make asking for availability feel less imposing, and include prompts to help break the ice.
• Sometime students feel the pressure to pretend they know more than they do, which deters them from clarifying all questions
• The form doesn't provide enough context for instructors to prepare for a session
.gif)
• Validates the worries of students who are stuck: "I'm so lost (and that's okay!)"
• Gives students topics to discuss
• Allow uploading a GitHub link or screenshot
• Joyful micro-interactions
Another Round of User Testing
I chose to use a visual language that values simplicity and playfulness, to break the stereotype that coding is intimidating and male-dominated. I also provided all the components and their states to guide the development process.
😫 Tackling Pain Point 1: Friction
Students can schedule a meeting in a few clicks, and upload their code to help instructors prepare.
😫 Tackling Pain Point 2: Inflexibility
Get quick answers from instructors and peers, and build a knowledge base curated for G{Code}.
😫 Tackling Pain Point 3: Vulnerability
Mentor profiles emphasize their availability and eagerness to help, so that students don't have to worry about imposing.
The director of G{Code} and several instructors said they will be champions for the platform! My designs are being implemented by the Engineering Team.
Once it’s launched, we seek to measure:
📈 Adaption rate
📈 Number of office hours scheduled on the platform
📈 Weekly number of posts on the forum
📈 Operation time and steps required to schedule appointments reduced
Also, G{Code} thinks this platform can be scaled up to connect alumni in the future, which could be design projects for next year's JumboCode team!
"Working with Ariya was an amazing experience. She was diligent in researching what our exact needs were and conceptualized a product even beyond our imagination. Her exceptional talent for design, combined with a deep understanding of user experience, has resulted in a beautifully crafted prototype that once built will exceed our expectations. The prototype has already received overwhelmingly positive feedback from our testers and we credit this success to Ariya's commitment to excellence. We highly recommend Ariya for any app design project and look forward to collaborating with her in the future."
"It has been great working with Ariya. Her initial mock-ups and designs have always been more than enough to get a conversation started, and her follow-up revisions have always taken my feedback into consideration in tasteful and refined ways. She's even quick with Figma to make changes to mock-ups on the fly as we discuss them so that we can see what we think about a decision. Ariya has been pro-active and consistent about reaching out to me for feedback. I'm confident our process will result in a better product that will improve our Fellows' learning experience."
Thanks to my team and the people at G{Code}, I grew a lot as a designer and team player and practice designing with empathy and intentionality. Being able to work with an industry client definitely made the entire thing much more realistic than a 'no-constraints' class project.
👩🏻💻💭 Getting feedback early and often
Working in a team is very different from designing alone. In the face of ambiguity, I learned to check in with Engineers early to make sure that my designs work for their constraints, and asked feedback from G{Code} users to make sure that designs are solving their problems. To me, every new feedback is like unlocking a new piece of puzzle, and seeing the project evolve to unexpected places was very satisfying.
🤠 Maintaining a flexible mindsetThe most interesting thing about this project was that what we initially thought was the problem wasn't the most pressing one at all.
It was only when I talked to users, understood their lives, fears, and goals, then I found surprising insights that added more dimensions to the problem.
