Tomorrow, I will be taking part in the SUSU appathon. After a hackday where nobody coded, I’m excited to go to an event within my students union where I can do what I do best, and write software. It’s very easy to sit around and talk about what someone else should do, but it’s always better to be the one actually producing things.
Sadly, our students union (and as far as I can tell, those in the rest of the country) has missed the good news which us software types have managed to persuade even local government of in the past few years. They’ve lost their user focus. This is a shame, because in a students union it is much easier to be user focussed than anywhere else. Democracy is present and it is very direct. Anyone can get involved whether it’s complaining in a Facebook group or running to be a sabbatical officer.
To try and bring some of the benefits of user focus to our upcoming event, here’s the rules I’m going to try and stick to. With some luck we’ll be able to make a much better product than teams without this focus. Then I can pass this on and we can change SUSU software for the better.
This means that when we have a design decision to make we should ask ourselves some questions:
- Who are the users? (Odds are they are some subset of students)
- What do they want? (This could differ drastically from what the dev team want, or what the students union wants).
- How can we make it easy for them?
It’s not about the development team
When you write software it is very tempting to make it about you. This can be writing ‘clever’ code, or showing off the best features. Our apps shouldn’t use technology unless it achieves the goal of making things easier for the user.
Test It with the User
We’ll be on campus, at the weekend. There should be plenty of people around with time on their hands. We need to test the stuff we make. It’s easy to make something that you think is amazing and later learn that the user wanted something completely different. Without testing our software may as well not be written.
Publish the Code
Too much software is stuck behind the SUSU password protected secure area. Open Source means other students can work on it. Open Source means our fellow students in other unions can use it. Open Source means experts in our University can audit it. Open Source means we can’t be lazy and leave credentials lying around the code.
There’s no point us leaving our software quietly at the end of this event. Our current technology in SUSU is truly dire. We need to make something good and then have people use it. That way we can show that our approach works (and fix it when it doesn’t).
It’s going to be hard to keep to these rules through a 26 hour hack day. At times we’re going to be lazy or want to show off. But I hope to try and keep to them most of the time, and with enough effort maybe we can make something great.
To achieve this we’ll:
- Perform a user test, perhaps in the library, during the weekend, to get feedback about our product.
- Make sure the site is online, with correct live data, and ready to use at the end of the weekend.
- Make sure it’s open source with all sensitive data removed from code by the end of the weekend.