Quotemarks is a project I began two years ago in my spare time to practice software development process. In recent years I’ve been the one providing the technical insight while the high-level nature of a project has been the responsibility of a peer. This project allowed me to wear different hats such as that of a project and product manager and to apply what I’ve learned to better inform future endeavors. What follows is the process I used in creating what eventually became Quotemarks which I shipped just in time for the new year. First, I walk through defining a vision and creating prototypes to rapidly iterate over ideas. Then, armed objectives towards a minimum viable product I focused on process where I delve into some insights in documentation.
I chose a bite-sized project so as to not get caught up in the details of a massive project. While nothing novel nor technically sophisticated, I settled on a mobile app for organizing a collection of quotes that I kept finding often in the most peculiar of places. I was unhappy with the many apps and websites already out there which focus on discovering quotations that someone else has already curated for you. Instead, I wanted individuals to collect found quotations in the way that I had. A mobile app seemed like the most intuitive solution.
Early on I imposed upon this project a defining value: Data liberation. This is the suggestion that data you’ve created should be accessible to you. My view is that any rational person would not use this app unless they had a way to get their data out of it. The outcome of this value was that I made data exporting a day one feature. This up-front cost turned out to be a beneficial for speeding up early prototyping and development.
The first step was defining initial requirements from which to build a prototype. I create two personas almost like character descriptions in a theatrical play. This helped me clarify who I thought my potential users might be. If this weren’t a solo endeavor, these personas would have also been valuable when collaborating with other people over the lifetime of the project. People come and go and organizations pivot. It’s easy to forget who your users are so personas keeps everyone grounded. These personas informed the project’s use cases which turned into feature requirements.
At this point some might drive in to code if they haven’t already. Hold on, we don’t know exactly what we’re building yet. Instead, I started by creating a low-fidelity “paper” prototype to allow for rapid iteration of it. I proposed two different sensical interface paradigms before settling on one which from I refined. These prototypes are not really paper but rather PDFs containing rough sketches of interface components with links between pages of the interface in different states. Setting the PDF viewer to view as a single page gives the illusion of a navigate-able interface. This is a powerful tool. It’s one thing to come up with an idea and it’s another thing to rapidly test whether it really works. The intention behind these black and white paper sketches is not to fool anyone into getting caught up about the appearance of the application. This was an exercise in information architecture and user interaction rather than aesthetic design. The result seems obvious now which is perhaps an indicator of good choices.
With an initial prototype I faced a conundrum about how best to derive a minimum viable product. Ideally, I’d document requirements, estimate time, and then execute. This is like floating a boat down Niagara Falls. The reality was I was still defining the product and there were still some lingering questions. Us engineers would like everything to be perfect from the get-go so that we don’t have to repeat effort. That doesn’t always work out since sometimes we don’t know what’s going to work in context until we try. What I needed was a process. I originally divvied tasks up based on role but this was too much overhead for a solo project. I settled on informally using Kanban cards. I’d occasionally re-assess and re-prioritize based on how things were going.
With a process in place, I needed to validate my work by way of a minimum viable product. The rapid prototype helped to go through various scenarios but it failed to place the app in context. This is like building a boat having only ever seen pictures of bodies of water. In particular, I had a feature where users could assign a quotation from their collection as a kind of “quotation of the day” that displays from outside of the app as a system extension. A prototype wasn’t much help here; I had to try it out. This led to defining a minimum viable product by prioritizing features and by considering what questions I needed to answer. I ended up with piecemeal milestone builds for review until I reached my objective.
Defining the necessary feature set for a minimum viable product is not always clear cut. For example, when I first submitted the app I was surprised by a rejection from App Store reviewers on grounds of “app completeness.” Although I had spent the time nailing down the user interface and implementing the important features to make it a usable product my design skills leave much to be desired to the point that someone else thought I hadn’t gone far enough.
What surprised me most was deciding what to keep and cut under a looming deadline and then how to go about defining subsequent releases. At last minute I dropped an important feature that wasn’t quite ready in order to meet the release deadline. In the end, the release got delayed by an external factor and in the interim I addressed the issue to make the release I had intended. In retrospect, while it’s easy to get caught up in the moment, hitting that deadline was less important than getting the release done right.
Throughout the development process I produced documentation as a form of communication and record-keeping. Organizations often treat documentation as secondary or outright omit it. Knowledge about how a product is intended to function and rationale for decisions made are locked away in people’s minds and forgotten or mis-remembered. It wastes time and creates bugs where the root cause is human negligence. While there’s a tradeoff to consider this is generally why documentation is critical.
Fortunately, just about anything can be construed as documentation. Some things that come to mind are test cases, code, requirements, personas, use cases, prototypes, email and chat correspondences, work logs, commit logs, tickets and comments in an issue tracking system. Documentation empowers people to do their best and so I feel that documenting should be the responsibility of everyone.
For this side project the best I could do was be mindful. My initial intention was to have living documentation and release documentation to match the release cycle. I would have liked to incorporated documentation into my development process to accompany deliverables as opposed to treating it separate. Unfortunately, an all too common scenario was that I would aggregated documentation only when revisiting a topic. Nonetheless, the documentation I had produced proved exceedingly helpful for me when needing to revisit certain topics.
For this project I had an opportunity to wear many hats which greatly increased my understanding of the essence of different roles. I am not a designer but I do think having an understanding of the user experience is helpful for any engineer regardless of their role. It was fun to experiment as a product and project manager where I could see myself excelling in these roles in the future. At the end of the day I am a software engineer.