A look at onboarding
The following case study was created as part of Skillshare's interview process.
Before we dive in I'd like to outline my process and the format for this case study. My product design process generally moves in order through the following phases: Research, Sketch, Review, Wireframe, Test, UI Design, Test (if necessary/possible), Learn, and Iterate. The scope of this assignment is smaller so I can't check all those boxes off the list. Instead, we'll be taking a look at what I've done for Research, Sketching, and Wireframing. I'll also give you context as to what would follow in the closing What's Next? section.
To kick things off, I needed to understand as much as I could about the current state of Skillshare's onboarding flow from a UX and UI perspective. Furthermore, I needed to identify and clearly state what I did not and could not know as a Skillshare outsider.
Any time I touch something that already exists, I perform an audit. I keep them simple and do them in tandem with my first run through so I can capture first impressions. Here's a look my audit, if you're curious.
So, a pretty solid looking and working flow without knowing any of the pain points the data reveals. I did notice a few areas of improvement, however, and set some goals for the work based on everything I knew, didn't know, and on some low hanging fruit.
I sketch for nearly everything I do. There's something about pencil and paper (or Pencil and iPad nowadays) that helps me give form to ideas.
While sketching, I arrived at three options for the picker I wanted to move forward on. There were also two options for solving the non-signed in user Home feed. I could reuse the one a signed in user sees or try something new.
So, let's make some wireframes.
Each of these picker variations attempts to do two things—allow a user to quickly pick a skill and to see a selection of popular, curated, or recent classes within that skill.
Tinder for skills, am I right? It might seem counter intuitive to break out each topic into discrete cards if keeping things concise was a goal. You might be right. However, it's a joyful, familiar interaction that allows a user to move through content quickly. The wager here is that the interactivity balances out the one-by-one approach needed to provide more context.
More cards! This time the sample classes are tucked away under a secondary tap that expands the card. Users can still pick a skill without looking at the samples.
This final variation is a mashup of the previous two. I was looking for a way to reduce the size of each tapable element in the list and keep the sample classes from taking up space in the UI. The solution was a two part component that allows users to check off a skill or see a detail modal of the skill and samples classes if they tap on the title.
For the Home tab, I created a new user area at the top that houses buttons for each skill selected. They take a user to a list view of classes within that vertical. The intention is to repurpose the list view users get when they tap "see all" for some of the carousels.
We've reached this section already? That's it!? WHICH PICKER WINS!?
Yes, yes, and I'm curious about that too. A little review with the team and some user testing is how I'd determine which of the pickers is the best to move forward with. Perhaps the team knocks one out and user test the other two against each other. Maybe one stands out based on the product vision and we verify it's usable via a round of testing. Either way, I can't say which one is best without some user feedback.
Without jumping to conclusions, however, here's a sample of what some of the elements in those wireframes might look like when they reach the UI design phase.
I hope you enjoyed the ride. Thank you for your time and consideration.