4/7/2014— Kelsey Breseman
I’ve been on-and-off designing the first run experience for Tessel since January, and wanted to share a bit of the process and thinking behind our first run/installation sequence.
One of the major selling points of Tessel is its ease of use: the code should be intuitive to a web developer. Adding physical modules should be just like adding code modules. You should be able to get from idea to simple prototype very quickly, and without any frustration related to using our tools.
Therefore, in making the first run experience for Tessel, I want to show you how quickly you can make your code interact with physical hardware. I set a goal of two minutes maximum from unboxing to working code.
I started here, thinking about all of the different backgrounds of our users and how we might serve each individually. There were two main components of this:
- Different modules for different people: everybody gets a different set of modules. I didn’t want to waste people’s time with modules they didn’t have, but wanted to make sure everyone got the instructions they needed.
- Different skill levels: most of our users are experienced web programmers. However, we do have a few who have never used the command line or even written a line of code. I wanted to make sure that our first run didn’t alienate anyone, even absolute beginners (this is something I’m still trying to resolve– suggestions welcome).
This led me to make a first page with a lot of options:
Original Page 1
You could select any grouping of modules, and then click on one of the two big buttons. The “I’ve never programmed” option took you through a command line tutorial before proceeding on the main path of installation > tutorials > projects (filtered to show only projects involving your modules).
On the page teaching use of each module, I only showed the modules the user had selected. You could switch between relevant tutorials by clicking on the icons shown at the top:
Original modules tutorial page
On the face of it, this was a nice “choose your own adventure” tutorial: you get just the information relevant to you by telling the tutorial your unique situation. But when I showed it to users (one advantage of a coworking space is how often people who have no idea what you’re working on wander by), they were paralyzed by choice.
As I now recall, I hated “Choose Your Own Adventure” books as a kid. I always wanted to know what would happen if I made a different choice, and there were just too many choices to follow every forking plot line. Simultaneously, I felt boxed in by the choices I was allowed to make: I didn’t want to select from the multiple choice menu, I wanted to make my own creative decisions.
Something similar was happening here: people had to make choices right away, with no information. Not only was module selection unclear, but they worried that if they skipped the beginner button, they’d be in over their heads and might not be able to turn back.
So my next design made the choice a bit easier. The module icons were made more obvious with an increase in size, and I shrunk the text on the beginner button, adding explanatory text below on mouseover:
Clip from Rev. 2 of the first page
I implemented similar slight design changes throughout the first run experience in response to user feedback– and these changes did improve successive users’ flow through the process. However, there’s only so far you can go with a basically flawed design, and I realized that I’d become stuck in my original design paradigm. So I asked the team for a design review with a focus on improving the overall flow– somewhat inspired by this blog post.
Design reviews are great. I highly recommend going back and forth between talking to users and getting feedback from your team, because they provide different kinds of feedback. Users can show you that they have a specific problem or reaction. Teammates in a design review are more likely to assess your bigger picture design.
My team had some really good feedback as a group, and by the end of twenty minutes, I had some solid design paradigms and ideas for implementation, which have driven my next round of edits.
Here’s the current flow (still in development, so anything could change):
First page: install. (No, you can’t install tessel from npm yet. Soon.)
First code: blink some lights.
Modules page: an expandable list of each module, also navigable by the sidebar menu, which expands on this page to show each module.
Modules page with the accelerometer tutorial expanded
…and more to follow! I’m still messing with the tweet-from-a-Tessel tutorial and the page of projects at the end.
Is there anything you’d particularly like to see? Any particularly good first run experiences I should use as examples? Let me know.