Our hardware and software puts users back in control of computing–but, you may be wondering, can we do the same with our services? With Librem One, the answer is yes. We have big, no, huge dreams about what we can achieve with your support and the wealth of free software that already exists. But we need to keep our feet firmly on the ground.
In this post we will outline the touchstones we have used to do just that–engineer trustworthy services that everyone can use–with a design process called user-centered software engineering. We hope it will facilitate communication with friends and colleagues as we hack towards a common goal… and also show all non-technical readers that human beings are at the center of our bits and bytes. So, how did we do it?
In the beginning, we created user stories. A user story is a plain-language description of the goal that you, the person using the services, want to achieve–and represents a high-level system feature.
I am an everyday user without my own infrastructure. I want a single point of trust (account and applications), so that communication from my existing devices is both safe and easy.
This story highlights the essential reason we all use online services: we use our phones and laptops to communicate with others, and we don’t own or control all the machines in between. Typically, we need at least one “go-between” to relay messages.
I am a well-intentioned sysadmin. I want to host a service on a hostile network (the Internet), so that I can help strangers communicate without compromising their digital civil rights.
This story highlights a key difference between Librem One and other online services. Our ultimate goal is that anyone with infrastructure and time should be able to rebrand and replicate our services. Users at either provider should still be able to communicate, just like you can email or phone anyone else, no matter who their email or telephone provider is.
While user stories are abstract, user personas are character sketches that help designers and developers keep a concrete person in mind, while they talk about kerning and for-loops. (These personas are minimal and not based on ethnological observation, so do take them with a grain of salt.)
Alice, Haruto and Thandi are college friends who keep in touch. They’re aware of front-page privacy issues (Snowden, Cambridge Analytica…) and are unhappy knowing that their messages, and those of their friends and family, are mined, monetized and otherwise abused.
Alice is a doctor who uses phone and email to communicate with colleagues, and short text messages to keep in touch with her family during the day. She has a demanding job and an active social life, so she doesn’t have much time to fiddle with her laptop and phone, or log support issues. She expects software to “just work”. She is our reference for an everyday user.
Alice illustrates that just because you know where the palatine uvula is, it doesn’t mean you have the time–or the inclination–to learn every technical trick there is just to stay private.
Haruto is a grief counselor who uses email for work, and a variety of tools to communicate with clients about personal, sensitive issues. He enjoys trying out new apps and features in his spare time, but would never compromise the trust of his clients. He expects core communication tools to “just work”, but doesn’t mind tweaking or reinstalling experimental tools, posting questions on forums or reporting problems informally. He is our reference for a privacy enthusiast.
Haruto illustrates that, no matter how mild our threat model, at some point we all rely on the tools that fascinate us.
Thandi is a sysadmin by day, managing sensitive data on a corporate intranet and VPN, and a sysadmin by night, managing infrastructures for local at-risk communities–none of whom she knows in person. She has professional expertise in software development and engineering (including command-line usage and logging reproducible issues in an issue tracker) and security best practices. She is our reference for an experienced user.
Thandi illustrates that, as expertise and responsibility grow, time diminishes. And additionally, that your recommendations and contributions impact real people.
This post has hopefully outlined the high-level concerns driving our development process. But there are, of course, many other issues to consider: legal, technical, compatibility, accessibility, language, demographics… the list goes on, but the important thing for us is that the human element always remains at the center.
And, in case you liked them, please feel free to re-use our user stories, personas and images (drawn by David Revoy) under our always-on BY-SA license.