Skip to main content

Step-by-step

The guidance below is for organizations that want to set up their own copy of the Assembly Line, not for individual automators.

Below is a brief explanation of the content on our sample Trello boards.

Pre-processing​

The pre-processing Trello board is where you will:

  1. clean up the template file
  2. add our standardized labels
  3. get a peer to review your work adding labels to catch mistakes early on

Development​

The phase that you will spend the most time on for your app--development--gets just one Trello board.

Development Template Board

Using the Weaver​

First, run your form through the Weaver.

Refining in the Docassemble playground​

Next, customize your form.

Getting expert review​

Get feedback from your subject matter experts. Turn the feedback into actionable Github issues that you can triage later.

Getting plain language review​

Hopefully you kept in mind our guidance on writing good questions. Nevertheless, get a second opinion that focuses just on how readable and easy to understand the substantive content of your app is.

Getting feedback from team members and external stakeholders​

At our peak, we had multiple weekly meetings with 5-15 members of our team. These were excellent places to ask developers to demonstrate their work and get more holistic feedback on the app: focusing on aspects including:

and any other aspects that required a bigger-picture view of the app.

On a smaller team, you may want to set up structured demos with potential stakeholders.

If you have time, budget, and access to real users, you may set up one-on-one or focus-group sessions to observe real users of your product.

Assembly line forms also include an embedded feedback link that will create a GitHub issue, so if you lack the ability to set up structured sessions, you could directly share a testing link with potential users to get feedback.

In either case: use this time, again, to turn the feedback into actionable Github issues. Spend time afterwards triaging and prioritizing the feedback.

Iteration​

The point of gathering this feedback, of course, is to move on from your first runnable prototype into a refined final product.

Read more about iteration.

Some important points to keep in mind is:

  1. not all feedback can be implemented
  2. an imperfect tool may be better than a perfect tool that is never released or used.

We developed the legal app maturity model to provide a very concrete guidance as to which features should be prioritized.

Testing​

Testing should be incorporated into multiple stages of development, but we provided some more specific guidance on our testing Trello board.

We found it effective to test using this approach:

  1. understand and create a high-level feature matrix
  2. write realistic user scenarios that provide good coverage of the features you want to test
  3. use multiple testers to use the scenarios as a rough guide to help with quasi-random input testing.

It is a good idea to ask your testers to record their tests on Zoom as they work. This lets you rewind and spot the exact sequence of events that causes an error.