How (not) to develop a system
One of the systems we developed in the past was a sign in system for the lab. We wanted to keep a track of the number of people inside the lab at any given time — seems simple right? We used to use a piece of paper and a pen, where people would write their name and reason for attending, and we would then need to count and input this into a spreadsheet.
This became a very tedious task, it was difficult to detect regular users of the lab, or to get statistics like how long people were in the lab. These sorts of trends would provide valuable insight into how our facilities were used.
In order to try to solve this, we developed a simple web app. People signed up on a kiosk, and they were given a QR code. They needed to scan the QR on their way in, and scan it again on their way out. This would let us easily know who was coming to the lab, when they were coming, and start to identify trends in user behaviour.
What went wrong
While on paper the system sounded easy to use, when it came to actual usage, we ran into quite a few issues.
- There were many small bugs and outages. This meant people coming in saw conflicting information — a sign asking them to sign in, and a tablet that said ‘System error’. This caused quite a bit of confusion.
- Usability issues. As a developer, I made some key decisions and assumptions which I thought were normal. When users came to use the system, it wasn’t really clear to them what they had to do to sign in, and therefore they would either need assistance (which took staff time) or they would ignore the pedestal entirely.
- Little community consultation. We didn’t know whether this was the best way to do things. We had created a system to solve an issue on paper, but the community wasn’t really consulted on what they thought, and they were the end user.
What would I change
So after some time, we took the system down, and thought of what we could do to make it better in the future:
- Begin with community input. Since the community is the end user, they should be asked and consulted with what they want. This could have taken the form of quick questionnaires or interviews asking how they would like to clock into the lab/what would be easy for them.
- Developing a wire-frame, and conducting a usability test. Making sure that we interpreted the feedback correctly by testing a low fidelity prototype — could be just a series of papers — and making sure the users were happy with the proposed solution
- Bug testing. In order to prevent any technical hiccups, spending some time to use the system with a limited set of users would be nice to work out any bugs in the system, so when it is released, it casts a good impression with the public.
