System map

We created a system map for our... well, system. It consists of more than an app; there are also physical vending machines that are part of it. Given the problem we set out to solve, we need to design multiple components and involve many actors:

• The women who will use the app
• The gynecologists who will verify information
• Workplaces and universities who will put up vending machines in bathrooms
  • The cleaning workers who refill the machines
• Women's orgs who accept donations and provide support
• Manufacturers of menstrual hygiene products

A system maps allows us to model the links between components and actors of our system.

Coming from a programming background, the first thing I noticed about system maps is that they don't have a single convention. In software engineering, we often make diagrams in UML, which has many shapes with precise meanings. In comparison, our system map used conventions that we made up for our own use.

Many prominent people in the software engineering world question the usefulness of UML diagrams. In comparison, I think system maps are definitely useful! Making our system map let us reach a consensus on what kind of system we were actually designing. Often, someone would question why a line was drawn, and the conversation would reveal that we disagreed on how the system would work. I'm definitely glad that we didn't jump into making a wireframe without this step!

In another comparison to UML, we often use automated tools to draw those diagrams. Arranging our system map felt tedious. We actually copied and remade the whole map after receiving feedback, in order to have a cleaner layout. In retrospect, I think the layout constraints affected our system design in a good way. For example, placing Women at the center of our map helped us put the women who used the system at the center of our design. This is because anything that was too far away from the Women block or wasn't connected to it was subject to removal.