How UX research at Code School led to Projects
Today, Code School launched a new feature called Projects.
Code School has always focused on teaching people how to code in the browser. It’s fast, it’s safe, and you don’t have to Google things like, “What does Failed to build native extension mean?”
Courses are an amazing way to get started and to build enthusiasm about a topic, but how do we keep that momentum going through the sometimes tedious transition into real-world development?
That’s a problem we kept hearing about from Code School users wherever they could talk to us, and we’ve set out to solve it!
But I’m getting ahead of myself. How did we land on projects as a solution? And what are they?
Directed discovery is a term coined by Nate Walkingshaw, Pluralsight’s Chief Experience Officer. Pluralsight acquired Code School almost two years ago, and we’ve since been able to learn a lot from their product team — including how they decide on and build products.
This is a UX process as much as it is a product process. The end goal is to create products that solve problems for our users. We decided to give this process a go on the question:
How do we help students transition from our courses to the real world?
What we did next was talk to some people!
Voice of the customer
Voice of the customer interviews are short, 30-minute chats with people. In these chats, we get to know someone, the problems they’re facing in their journey to learn how to code — and eventually ask about our specific theme in as roundabout a way as possible.
After doing this with a bunch of people, themes start to emerge. These three stood out to us:
When I finish a course, I try to do a project using that technology.
This came up a lot. People want to put what they used into practice. Just setting up a new project can be tough though!
I want to do something on my local machine.
Yay! This validated our hypothesis!
I don’t know how to use Git or GitHub, but want to learn for a job.
People want to use GitHub! We heard this over and over.
Customer preference testing
So, all we have to do is create something where people build a project on their local machine using GitHub and everyone will love it, right?
If only it were that simple.
How do we help people get set up? What if they get stuck? How do we validate that the project is done? How do we communicate what’s expected in the project — and what should be done to complete it?
This is where customer preference testing comes into play. We created a prototype that we believed would solve users’ problems and scheduled several interviews to show it to them and get feedback. We use InVision for this, which has been amazing for creating fast prototypes that allow us to get feedback and iterate on user flows long before we step into code.
The format for this CPT-style interview is an hour-long chat with over a dozen users to walk through this prototype and get their take on every little bit of it. The format of this is very simple:
Five- to 10-minute chat to understand the user. Where do they work? Why are they learning to code? How have they learned in the past? What are their goals? What technologies are they most interested in?
Forty-minute prototype walkthrough. This may sound like a lot of time, but it usually flies by. This is the hardest thing to do. You have to sit back and be uncomfortable here — not leading, not driving, but somehow guiding the student to give useful feedback.
Ten-minute debrief with the user to ask additional questions and see what questions they have.
We record these sessions on BlueJeans and always have three people in them at the very least. We always want there to be a product manager, a designer, and a developer in the room for these. This has been huge in helping to pour user empathy into the product from all roles involved in building it.
When we were initially thinking about this, it sounded like it might overwhelm our developers with meetings, but luckily that hasn’t been the case. We try to limit each developer to one of these a week at most, which gives them enough time to still, you know, develop.
Moving out of the prototype stage
Throughout these CPT interviews, we were iterating and changing our prototype to solve the common problems people ran into. During this time, we realized how much education we’d need to do about how to use Git and GitHub. People wanted to learn it, so we shouldn’t just assume people know the terms.
Once we got to the point where major issues were no longer being brought up with our prototype (or at least ones we didn’t have a plan for), we moved out of the prototype stage and decided to build it! So, what did we build?
What are Projects?
There’s a lot there, so let me break this apart a little bit.
Authentication with GitHub
In order to play a Project, you’ll first authenticate with GitHub. We don’t ask for any special permissions here — we just need your GitHub username.
Fork a repository
Each project starts in a repository on Code School that we’ve already set up for you. Jump over to GitHub and fork the repository, and Code School will verify that you forked it.
Clone and set up
Cloning in the GitHub world means copying the project down to work on it locally. The next step is do this as well is the setup for a project.
This is the step where we jump from the browser to the local machine. We knew from chatting with a bunch of people that this step would be a new one for many. We added extra videos elaborating on how to set up GitHub Desktop on your local computer.
The next step is to build it! Unlike Code School courses, where you’re working in the browser, for Projects, you’ll work locally in your preferred code editor (I love Atom myself). We’ll give you some tasks to complete within a project and even include a test suite with every project for you to be able to validate that you’ve completed all the tasks.
Once you’ve completed all the tasks, push your code back up to your fork in GitHub. When you click “Check My Work on GitHub,” we’ll verify that you have completed all tasks! Checking your work only takes a few seconds. If any tasks are incomplete, we’ll provide a suggestion to fix. You can submit as many times as you like.
This is a drastically different process than our usual courses, but we’re excited to see what people think!
Each project has some Next Steps you can do after completing it. For web applications, this could include giving directions on how to deploy the site and make it public. For example, check out the demo for the Use jQuery to Fetch and Show Code School Badges Using Ajax project. In the next steps, we show how to deploy it to GitHub Pages.
Getting stuck on a project is a lot different than getting help on a course. There’s no easy “answer” available in a click. Instead, we’ve provided a few places for people to get un-stuck!
- Getting set up with GitHub and a code editor video
- Answer Video — The author walks through the project from beginning to end.
- Code School Discussion Forum — Chat about this project and others.
- Code School Slack — Chat with other users.
Try Projects today!
What do you think of projects? Would you take them?