Target Users

Using the proof-of-concept (POC) as a basis of discussion, I began exploring how the Propag8 would be used in the lab. In user conversation it quickly became clear that the scope of the POC was too narrow in two ways.

Firstly, the POC lacked a feature to record experiments. Researchers stressed the importance of this information being added to the Propag8 record. They highlighted that the choice of stock can be based on whether it was was used in a certain experiment.

Secondly, before the POC was ignorant to the fact that researchers would use the app to plan their work. In discussion it became clear that Propag8 would gain a lot of value if it also allowed for users to plan record line generation tasks.

As the scope of the app expanded I found it useful to document the expected usage scenarios as use-cases. This step also allowed me to explore user goals in more depth, prioritise features and organize ideas for future iterations (alpha, beta, ..).

With the a clearer idea of the scope of the app I decided that mid-level researchers (PostDocs) would be the first target group. The thought was that in this carreer-stage projects would be demanding enough for the alpha of Propag8 to provide significant value and researchers would still have the flexability to adopt new workflows.

The Path to Alpha

The purpose of the Prototype was to function as a basis for user discussion (as was for the POC) and generate interest in the Propag8 app (not the case for POC). However, with the prototype in hand I was planning to interview a wider set of reseachers and start generating interest in Propag8.

To get as many people as possilbe to register their interest via a mailing list, the prototype would have to demonstrate the potential of Propag8. One objective of the prototype was to have one or two use-cases polished that would serve as a showcase of the vision of the final product (see Minimal Path to Awesome, www.artofproductpodcast.com).

Opinionated vs. Customization Options

I had been following the development of a task-management app (Taskwarrior) and was aware of the subjectiveness of a "good" task-manager. Ideally, I would have implemented a full customizable task-management feature, but this was clearly out of the scope of tne prototype. Therefore I had to choose between:

1. Providing an interface to existing task-management solutions
2. Implement an opinionated task-management feature

As some task statuses could be updated based on user-interaction with the records, I decided to add an opinionated task-management feature. I deliberately kept the task-manager UI seperate to the main UI, so users could "opt-out" of using it.

The Result

As a solo developer I found keeping requirements as use-cases exceptionally helpful during UI design. For example when modifying the "Stocks" activity to allow for the assignment to experiments, I could easily see the all the other usage scenarios that touched this activity.

The most difficult part of this iteration turned out to be the task-manager design. The intention was to allow users to add tasks to different entities in Propag8 and have all unfinished tasks displayed in a single view. I eventually designed a activity akin to a Trello board, with the different sections corresponding to the stages of the line-generation cycle.

I chose which features to refine as part of the Minimal Path to Awesome strategy mainly on past user conversations. The chosen use-cases started with the task-manager and ended with a history-view of a specific stock, as those were the features people were most enthusiatic about. In later stages Bootstrap CSS, although it allowed for rapid early development, started to get in the way of generating an appealing UI (the alpha release will use Tailwind CSS).

User-speicific encryption significantly impacted development speed of the prototype, as it made many quality-of-live features of Ecto unusable. However, it speaks to adaptability of Elixir and Ecto that the feature was feasible in a prototype context.