A few weeks ago, we released eCasework to a small group of people. We’ve been working on the app for almost a year now, trying to update the old system and usher in a new way for councillors to handle their casework. As it hadn’t been touched in a while, we decided to completely rebuild the system from the ground up. Yep, that’s right. We looked at the previous version, saw what worked, looked more closely at our userbase’s habits, and then wiped the slate clean.
Design is key
Well, not completely clean. We started out by defining and designing the essential parts of the system, the features that absolutely needed to be present if the app was to be useful. After a few weeks coding these, we revisited the design with fresh minds to think about the extra features that would set us apart from competitors.
Planning breeds efficiency
Now we had a fair body of work. Inside a couple of months, we had managed to develop an entire system, plan extra features, and started to extend its functionality beyond simple case management. Having said that, the app had plenty of bugs, extra features weren’t entirely integrated, and to top it off we only had a few channels to tell people about our product.
Time to prioritise. Cups of tea and notebooks at the ready, we started sorting and prioritising the list of features necessary for councillors to cogently manage their casework. Having laid to rest several whiteboard markers and at least two packets of biscuits (brain-fuel is essential…and sugary), we had specifications for versions 0.1, 1.0 and 1.1.
The three Ts: testing, testing, and testing
Software development wouldn’t be complete without this necessary step. Once a feature is built and bolted on, it’s time to put everything through its paces. More often than not, this proved to be a useful step by presenting methods we hadn’t previously considered. ‘What happens if I just do this one little thing differently?’ you wonder. And then up pops a bug, showing you another way to make the system more robust.