Piper Inc. is an education technology company that creates a computer kit for children ages 8-13 and we prioritize B2B sales toward schools and education. Our product focuses on teaching how to create circuits and control hardware components using code. The kit is a real-world and digital experience, from building the kit, to assembling electrical components, to writing code with Google Blockly to control those components. We released a product called the Sensor Explorer kit as an add-on to the computer kit where kids learn how to use sensors in their coding adventure. The following is a redesign and addition of features to their coding experience PiperCode.
My role at Piper is centered around design mixing physical interactions with digital experiences. How a person learns to code with the software and builds with electrical components in the physical space. Art and visual design direction were developed farther in production, but UX and interaction designs were established in 4 weeks.
My Role and Duration
Tools and Methods
Usability Testing, Heuristic Analysis, Competitive Analysis, Sketching, Wireframes, Prototyping, Vector art for polished UI, Sketch, Figma, Adobe Photoshop and Illustrator
Project Goals
This project was created for the Sensor Explorer release. Sensor explorer includes the addition of 3 new sensors and new content that will be shipped with it.
Ultrasonic Range Finder
Color Sensor
Temperature Sensor
The following are goals for Piper code in regards to sensor explorer:
Set the stage for new features with minor adjustments to user-interface
Develop visual representations within the UI for data that is being collected by the new sensors.
Create a component resource library for the hardware that students could use during their projects.
Every feature needs careful introduction and placement for a semi-guided experience.
Through usability testing, we found that kids weren’t learning how the code and circuitry were working together. There was a feature that assisted them in understanding this but, it was hidden in a menu the user never went into and so the user never knew it existed.
Aside from testing, After heuristic and competitive analysis of products for this age group, it became clear that children ages 8 -13 needed more guided experiences. it was important to create simple interface that isn’t too busy. As we keep adding more features to the experience, this will become harder to target for this user base. With that in mind, making sure there is a design system and information architecture targeted toward their learning capability became a priority goal in this design update.
User Needs
Early research on this user group (ages 8-13) showed that experiences targeted at children in this age group tend to be very guided. However, as this is an educational product, there needs to be some learning and problem solving built into the editor to enable them to grow in their critical thinking skills.
The Problems
Present complex interfaces with familiar design systems for an audience that needs guidance, but also enables them to search when they hit a road block.
Restructure the editor to create familiar design systems that reinforces learning goals.
Provide the access to data they are recording with sensors and other similar features, while letting them edit and see their code.
Creating a resource library for hardware components that enables them to dig for answers.
Solutions
Part 1: Setting the Stage for New Features
Pre-Update
Updated
Before diving deep into specific features, we wanted to make simple adjustments to set the stage for new features and align PiperCode with common design patterns. I began with a heuristic analysis, competitive analysis, and research into what applications and interfaces users in this age group were used to interacting with and other applications that were succeeding in the same space we are developing in. I also made sure to consider the educational goals of our product before presenting a solution.
Each section would have a purpose the user would learn. The goal is to create a design system that users would understand where to consult to find information they need to solve their problems.
Designs
The left “Magenta” panel is for tools. This is where the user finds the Google Blockly code to drag in to their workspace to assemble the code. The “projects”/back button was also added here to conform to design patterns of left to right progression.
The middle “Red” section is for the workspace and visualization. This is where the blockly code would be assembled. The bottom visualization tabs were added to display the console, sensor visualizers and python viewer. When these tabs expand, it allows those sections to be viewed while the blockly code is visible. This was an important addition in this update because we saw in testing and interviews, children were not grasping the connection of blockly code as a representation of code. With the addition of the data visualization tab, this felt like a good space for users to see what impact their blockly code was making on the python code.
The right “Blue” section is where projects and any information they might need would be. This includes the project writeups and component resource library.
At the beginning of the project, the usability testing and reports from teachers who were using the product in their classrooms showed students were not connecting how the code and electronics were working together. We realized students were rarely using the Raspberry Pi pin map which showed that interaction while the code was running. The flow we were seeing was, they would be reading through a tutorial. assembling the blockly code and trying out their code, but, the pin map was hidden under the electronics tab outside of this flow.
Python View Before - Python code replacing Google Blockly code.
Python View After - Split view, seeing Google Blockly code and Python together.
Raspberry Pi Pin Map Before - no labels, excess information, and incorrect Raspberry Pi numbering. There are 2 pins we do not want them to use, and so we changed the blue pins to no color to discourage their use.
Raspberry Pi Pin Map After - Added labels and focused on only giving them information they need for our product experience.
The design of the Raspberry Pi diagram was adjusted to show the pins they need with labeling for the colors while also removing unnecessary information about voltage and specific constraints per pin as those elements were not focused on in our planned product experience. Our pin numbers were also changed to match the Raspberry Pi’s official numbering patterns, so our users would not have a problem going from our experience to using the Raspberry Pi for their own projects outside of our experience.
The Raspberry Pi diagram was also moved to the right panel. It’s constant presence as they complete a project will hopefully have them see how the pins and the code are working together. The piece of code and the respective pins would outline green when they are active.
Part 2: Introducing Data Analysis to Young Coders
With the introduction of sensors, the addition of data analysis to track the sensors was on the top of the list of additions to PiperCode.
The sensors collect data that students would use in various PiperCode projects and often used in conjunction with other components. We developed a visual representation of that data in the PiperCode editor.
Education Goals
Present recorded data while the user is developing their code to enable them to use that data in their projects.
Designs
When creating the data visualizers for each sensor, we needed to have it visible while the code was visible because our goal was to enable kids to use the data in their projects. This helped us decide this general format of bottom expandable panel. The visualizers fell under the “data” tab with 3 sensor tabs after that. The word “Data” was used as a catch all for various types of visualization as more sensor explorer kits could be released in the future.
The Ultrasonic Range Finder needed to be a graph that depicted range over time.
This data visualizer as well as the other visualizers were made to mirror how students would already be learning about these topics. We looked at graphs that were normally used in schools and took inspiration with our implementation.
Minor changes were made according to our lesson plan and also depending on hardware limitations established in consultation with the software team.
Temperature sensor visualization has two modes for Fahrenheit and Celsius. Original iterations of this had both temperature graphs on the same graph but this was confusing and the two running in parallel didn’t necessarily convey the correct message educationally.
We created a RBG graph to show how much of each value was in the color and then a visualizer for that color.
A goal in this release was to provide a resource library for PiperCode users to be able to review wiring diagrams for each hardware component and supporting information that shows them how to use those hardware components.
Education Goals
Part 3: Hardware Resources for Easy Reference
We realized through testing that there were times where they would forget how to use components from prior lessons either during pre-made tutorials or when students were trying to create their own projects.
Users would need to be able to access the resource library in the midst of projects.
With the addition of a resource library, having a way to navigate to those specific electrical components that was appropriate for their age group and learning capability.
User Needs
To create a non-intimidating resource library that would fit in the editor. We split the components provided in the Piper Computer Kit into 4 categories and sub-sections using vocabulary users encounter throughout the tutorials.
Designs
From those sub-sections they would be able to pick specific components.
Basic Hardware
Outputs
Inputs
Sensors
Component pages had specific prioritization rules. When users come to these pages, they are most likely looking for the wiring diagram. Having that at the top is most important. After that, a brief description explaining information that they would need in pairing with the diagram. Further information can be place below it as needed but, this format assigned value to putting exactly what the user needs at the top and less valuable information would be below it.
As the project prepares for release, next steps would be to test more with our users and see how they stumble through our software and make adjustments accordingly. The project was an interesting challenge, of creating a code editor’s design systems, as well as an information architecture for a user base that tends to need a more guided experience. I will take the lessons I’ve learned in this project moving forward, bringing care in providing complex experiences to younger audiences.