Pop!_OS will adhere to the System76 product development process. This is an extended version of the process we’ve developed with our hardware product design project. There are seven parts.
Pop!_OS is for people who use their computer to create, particularly in computer science and maker fields. This means that our research, user testing, and features will focus on these customers exclusively. The purpose is to make the most productive tool possible for these users.
Pop!_Theme elements were chosen and modified to match the System76 brand. The design changes as additional new developments reveal previously unknown information. For instance, in desktop hardware, the design evolved as we’ve refined the techniques we’ll use to manufacture. Refinement will continue through the product’s life.
Start experimenting with basic principles and components. For Pop!_OS we know we want a fast and streamlined install and user setup, so we began work there. The purpose is to create a baseline – the platform to build on. There aren’t major features decided or created. For example, in our desktop hardware design, we knew we wanted an easily serviceable chassis, so we started experimenting with how different chassis parts could come together and separate.
We will determine what features to create by observing people using Pop!_OS. The process will be open and transparent with shared results for public analysis and conversations about solutions.
For instance, if while observing customers work on their computers they regularly stop to check text messages on their phone, a solution may be to show the message on their computer with the ability to reply. If, through user testing, it’s found that customers have trouble finding application features in menus, we will conduct an OS menu study and test proposed solutions.
Feature requests can only be proposed from research and modeling process results. The research and modeling process that we build will be open source so any project or individual can participate.
The pool of testers are exclusively the people that we’re building the product for.
Common customer pain points reveal themselves through customer support. We’ll mine the data to find trends. One example was Ubiquity crashing due to a lack of WPA Enterprise WiFi support. Fixing the bug removed a customer pain point, which improved the out-of-box experience, and reduced the technical support burden.
Prioritize based on how much each feature will benefit the broader customer base. Keep features small and focused. User-test to determine efficacy and release.
Finally, there are always bugs to work on and we want to keep quality high. We’ll revive Ubuntu’s 100 paper cuts program under the moniker Bite-sized Bugs.