 Okay. Hi everyone. So I've given this talk like a couple times before. So if you've seen it before, like I apologize, but this will be a really speed version and it's going really fast. Okay. So hi everyone. My name is Hong and today I'm going to be talking to you about how we built Parking.sg all the way from initial prototypes to our final production launch. So for those of you who aren't familiar, this is the problem we're trying to solve. When you want to park your car in Singapore, you have to use these paper parking coupons and they're really annoying. The biggest problem about them is that let's say you're in a meeting and, you know, the meeting's running long. So you're sitting there and you'll know that you're running out of time on your parking coupons and as the minute ticks over, you just know you're going to get a parking ticket and there's nothing you can do about it. It's a really like excruciating feeling because there's nothing you can do about it and it's weird because it creates this really antagonistic relationship between you and these like little pieces of paper. And so this is our solution. We built a mobile app that does three things. One, it lets you pay using your phone. Two, you can extend your parking session even when you aren't physically at your vehicle. And three, you can get a refund for any unused time you have at the end. So this is sort of like the evolution of the app. Sorry, I know the colors are a bit wonky. All the way from our like our earliest like prototypes, just concept slides made in like literally PowerPoint all the way to our launch UI. And today I'll be walking you through sort of our process of how we built it. Starting from our initial prototypes back in September 2016 to our final launch and on all the while I'll be taking some like deep dive into some of the design decisions we made along the way. So phase one is the prototype. So this right here is the first ever concept slide for digital parking. It was done as a part of like a series of slides that we made in terms of brainstorming ideas that we could do in the government to help make people's lives better. And this sat along on the shelf along with a bunch of other ideas for about two years until 2016 where we built this. This here is the first ever prototype app of parking on SG is the first ever working prototype. And it is barely an app at all. So for those of you who know what Firebase is, we literally just had a Firebase database that we manually edited and added entries into as the user app. And then you had some crappy enforce app that just checked to see whether the license plate number was in the database. And that's it. That was the whole app. Because at this stage you're not worried about like polish or maintainability. You're not worried about any of these longer scale things. What you're worried of, what you're trying to do is you're trying to bridge the gap between your imagination and the person you're trying to convince. Because you just had an idea and you spend a bunch of time thinking about it, but you need to convince like a stakeholder or an agency or your boss or whatever. And because you spend a lot of time thinking about it, you obviously know much more about what the idea is. So you're not trying to build your completed magnum opus. You're just trying to figure out, get that seed of a thought in your head into that person's head so they can get it. You're trying to get it to the stage where they can point to that thing that you show them and say, you know that thing? That thing that I don't have the words to describe and I don't quite know what it is. I want that thing. Because that's how our team works. We tend to prototype before pitching. Because especially in the government, there's like a hundred slide decks all floating around, all promising to be the next big thing to save the world. But it's much easier to argue that something is possible when it's already real. And I cannot emphasise this enough. Having even a really like simple interactive mock that person can like touch with their fingers makes your argument that much stronger. And so that's what we did. We basically went to, we had a minister visit one day and between his official like agenda of seeing other things, we like pulled him aside for a few minutes and Kywin over here actually who helped me work on it, we showed him our like crappy little app and we were like, hey look you can use a phone to take a picture licensing number, isn't that cool? And he's like, that is cool. I want that. Why don't you go talk to our agency about it? And so we did. Which brings us to phase two, the proposal. So the goal of this, so phase one is about like, you know, just getting the basic idea to get someone interested, here you're trying to figure out what you need to do to test something with actual users. Because turns out you're still not worried about all these long-term things. You're not worried about featureless infrastructure. You just had an idea and you have no idea whether this idea is any good or not. You just know one other person for it might maybe kind of work in some situation. And there's a whole bunch of hurdles even getting to this basic stage of testing something with a user. So on the technical side, you can't use like Firebase anymore. You can't use Firebase as your UI anymore. You have to build somewhat of a usable app design. You have to have a database. You have a bunch of stuff. But there's a whole bunch of bureaucratic hurdles as well you need to overcome even to get something, you know, just tested live with an actual human being. So the first thing that we did was we went down and we actually just met with some of our enforcement officers. So this lady, she'd been doing this for I think like 20 years or something. I forget her name unfortunately. And we just went down and we followed her around for like a couple hours and just sort of like really just try to understand like what her life was like and what you know how what her workflow was. And one of the things we realized like pretty quickly was that she was really really good at what she did. So you know those parking coupons with all the holes you poke in them, you might think it's really hard to like calculate and do the mental math because I know I have to spend a bit of time thinking each time. She would like just walk up the car. She would look at it for like less than a second be like and then she move on. And she was really accurate which meant that straight away our initial idea of having like taking a picture and of verifying the license plate number that was just way too slow. Like ignoring everything about like you know accuracy or like the speed of the algorithm or anything like just having to take out your phone and like squat in front of a car was already slower than this woman just like walking by and peering through the windshield. And so straight away we saw and so we managed to solve this problem using the extremely high technology known as a list. So instead of checking your license plate number one by one we just had a list of all the people who had you know paid out using the digital app and we just showed that to the enforcer and so as she walked down the license plate she just need to look at the car and see if the license plate was on the list and if it wasn't she would spend some extra time to verify and all that but this was way way faster than looking at things one by one. And the whole point of this is that like it's not about using like the fancy new technology it's about solving problems in the most efficient way possible and sometimes that means really really simple tech. So despite all this we you know we were pitching this we are trying to address a bunch of hurdles but our real breakthrough happened when the coupon prices went from 50 cents to 60 cents because predictably when you use physical media a bunch of things happened when they changed to 60 cent coupons everyone was rushing to return their 50 cent coupons because they are now useless and people are now rushing to buy 60 cent coupons and they ran out of stock and so predictably a lot of people got really mad and in the midst of all these problems we got a call from we got a call from the agencies and they're like hey you know that thing you've been talking to us about for a few months how quickly can you do it and we were like it will give us two months and they were like okay and that's how we got to phase three which is alpha testing. So alpha testing is about exploration and validation it's about like you had a seed of an idea and you know and you don't know whether that's the best idea you're just trying to like search around the space and find out all the things you don't know you don't know and so we started really simple it was one car park with 10 government workers 10 government officials that's it we we spoke to the enforcement officer for that one car park and told her hey just use our little app to just try this out for this one car park and and that's what and that's where we could start that we grew to like two or three later on and in order to even do with the start with this alpha test you needed to have a prototype driver app take note this was the app that we started testing with and it's really simple you stop components there's no animations no frills you're still not trying to build your final product you are just trying to validate or invalidate your ideas as quickly as possible and you know test and iterate um and one of the things we had to figure out and this is the first of our design dives is how we calculate parking duration so with the traditional coupon you place the coupons and if you have extra time at the end well that's too bad that's just gone the way we do it right now is that you play you say how long you're gonna park for just like the coupon but we refund you the remaining time and the question we often get is why don't you just have a simple start stop mechanic you know you start your start your phone to uh start parking and stop parking because well it turns out that works most of the time except when you forget to stop parking you now owe infinite money and owing infinite money is pretty bad um this can happen for a variety of reasons right like you can you know your phone can run out of battery or the signal could be poor or you could just like forget I mean I built the parking app and I still forget like half the time um and so practically speaking you don't actually charge infinite money you like have some sanity cap like $20 or something and then you have like disclaimers and then you have like a warning and an FAQ saying that you know if you forget the parking will cat charge you but if people still won't read it and then they'll like appeal to you then you have to explain to them but then you have to like you know oh this is your first time I'll forgive you but then this is your third time I'm not sure it's just a whole mess um but we do our block and refund system if you forget to stop parking without having to explain a single thing to anyone everyone intuitively knows what happens well you just pay your initial amount that's it and that's a huge win because by going with a non-obvious design decision we managed to save up that giant chunk of like work and like customer service and feedback that we would have to handle otherwise um similarly we have to do price calculation because price calculation for parking turns out to be not as trivial as it seems because there's the permitted prices but there's also the block prices and so you need to figure out like you know what combination of various prices you need to like you know are the cheapest way of getting from point a to point b in terms of time I'm going to skip over the details a little bit but for those of you who studied algorithms we use basically what's called a beam search algorithm or kind of a beam search algorithm where we treat it as trying to get from time a to time t using the lowest cost possible and we prune like you know we prune parts which don't have very much promise um so the whole story of all here is that don't blame the user you help them make good decisions because it will be very easy to be like upseat you didn't stop your parking session it's your fault and it'll be very easy to say look you chose you didn't choose the cheapest combination it's your fault but if you think about it that doesn't really help anyone right like the user feels shitty you feel shitty you have to argue with them and ultimately people don't use your app and if you think about it because you're the guy who's designing the app you actually have a lot of influence over like what paths and what decisions a user makes and you can't save everyone there will always be people and like who make like really weird decisions despite every single warning in the world but you can at least try to help most of the people using your app make good decisions and that's what you should do so at the end of alpha testing we figured out a bunch of things but the biggest thing that we learned had was we had generally positive reception now this might seem like a small thing but validation is probably the most the biggest thing you can get because after months and months of pitching and testing all of that was to say yep this is a good thing now go build it and so once we had generally positive reception all our bosses all the agencies were like all right now we can fund it we can go and just start building and get this thing out the door which brings us to phase four which is beta testing so beta testing is about focus and stability alpha testing is about divergence beta testing is about convergence it's about taking all those ideas you've explored and like slicing it down to like what you think the final concrete form of your app wants to be and a lot of this is just about sort of prioritizing tasks so this is a basic like you know cost benefit chart and there's a bunch of stuff which you obviously do but there's a lot of stuff which has low benefit take note not no benefit not bad they have some benefit but they are quite complicated to build and things included are like an e-wallet or a user login system both of which do provide some benefits but are these like rabbit holes which you can sink a lot of dev time into which you may not need to so what you need to do here is you need to actively filter and prioritize what you're going to be doing when you're building a final product in the case of especially in the government and in a lot of like big companies when you have a normal tech project you have a phase called gathering requirements right so the project manager will go around to all the stakeholders and all the agencies that everyone involved and they will gather requirements and get all the things that everyone ever wanted into a giant list I think for us it was like 178 features or something like that and they will say now build this and if you were doing this traditional way you would just as a developer being like well okay then let's see what I can do and unsurprisingly when you do this do things this way you end up with an incoherent bloated app that does a lot of things very poorly and that doesn't help anyone so what a lot of software firms do and I guess and we do now is that we prioritize the task so you have p1s which if we don't have you don't launch all the way down to p3s and the whole and one of the big benefits of doing things this way is that it makes very explicit the trade-offs you're making when you add new features onto the list so for example something like multiple payment modes it's really good to have like don't get me wrong it's nice you can have it but is it more important than you know being able to extend your parking session probably not is it more important than being able to like store your parking history well probably not and by making these things explicit you at least have these decisions up front as opposed to like waiting till it's too late and realizing you took a bit off more than you can chew another big benefit of this is that it makes the requirements of gathering stage a lot less high stakes because if you just have something on or off the requirements list then turns out you know everyone fights really hard to get their thing on the requirements because otherwise it'll never get done but by having a priority list you can argue whether it's p2 or p3 or p1 or p2 but roughly speaking people then feel less stressed about like okay it's not going to get none done never maybe we'll get done a little bit later you can have like more civil conversations about what you should or should not be doing first projects really die because they're too small they usually die because they're too big because if you do something if you have an app which does too little but does it very well it's very easy to scale it up and that's never a problem no one's ever had a problem of an app is too good but does too little and can't scale it but when you have but when you have something piece of software that does a lot of things very poorly it is almost impossible to fix generally speaking you just kill it with fire and build a new one one of the design decisions you made along this is that we have no user accounts so user accounts like everything has a sign in nowadays so it might seem like a default to have but if you really start to think about it user accounts have a lot of complexity you need to have a sign in page a password reset page a settings page this is more pages than the actual app has right now and on top of that now you have to handle security because you have logins but when you buy paper coupons you don't need a login so why should you need a login for digital coupons turns out you don't so we didn't and we saved a whole bunch of work that we never had to do now i'm going to skip past the detail on this a little bit and you can come talk to me about this later on the data model one of the things we figured out was that we didn't instead of overwriting our previous parking history and losing some of the record of what happened we created an append only and versioned data model where every time you update every time you add a new parking session you don't delete things you just add new ones and every time you update something instead of rewriting over the over row you add a new version you add a new row with an incremented version number this way we have the we have the history of everything that ever happened in our parking database without having to resort to like secondary like audit tables and you know things like that um similarly we have a data model a data model allows for causes and commitments and so the idea here is that we want to have atomicity atomicity is a way of saying all at once and nothing at all and so we treat one database in this case the parking session as a sort of like backbone of truth of what has or has not happened and because we have to do payments we do what's called a two phase commit where you authorize the charge write the parking session and if the parking session right is successful then you capture the charge um to the third party payment provider and this means that there's never a case where we've taken payments and not and not given a parking history a parking session and vice versa never a case where you've given a parking session not given a parking session ever given a parking session and not taken payment um because if it fails at any point well no problem we boot back up we recover and find the commitments and make sure we follow through on all the commitments written through the core backbone of truth database um so the last part of beta testing is obviously beta testers and the way to think about testers is that they are a scarce resource because testers usually only give feedback once which means that if you open your beta and every like to everyone all at once and everyone tells you that everyone will tell you that it sucks in the exact same way because it's the first time you're testing and you will fix that and now there are no more testers and you can't improve your app any further um so instead of thinking of testers as about like you know inflating your numbers and I've got like 10 000 users or whatever you just you want to use as few testers as possible to get the next piece of feedback you need in order to figure out what you need to fix or do next um yeah so at the end of the beta test the big thing to realize is that there was a whole bunch of stuff that was not implemented but not launch blocking so a lot of all these things were things that we wanted to have but they weren't launch blocking and so we could still move forward to production without them and that's the key point to realize good to have is not must have and making that distinction lets you make progress while being stuck in development hell um which brings us finally to phase five production so production is about polish and contingency planning it's about making sure you don't trip up on anything on the way to launch and a big part of that is about having a good UI so you can see well I guess you can't see on that line uh you go from uh your beta your beta design to our final launch UI which fundamentally had the same like functional components but was a lot simpler to see and so the less the thing about UX design is that the less noticeable the better because if you think about it amazon google and facebook like these are these tech like giants right and even they are like a tiny part of your life which means that your little app that you're solving a much smaller problem is like a miniscule part of people's lives and so people don't want to learn about your like design philosophy or like what your like particular brand identity is they just want your app to do the thing it's meant to do and let them move on with their lives um and a big part of this is by keeping a simple design language so if you look at this like these are sort of the three of the main screens in the app there are probably less than like 10 different elements here there's like the trio of numbers which we use um there's like the the icon and row icon and row there's a button and like some labels that's about it um don't worry it took us a while to get here but because people are only going to be using your app for like less than a minute at a time you have to keep your design language very simple so people can learn this language and understand what your app is trying to say to them in the short amount of time they're going to be interacting with it so finally um no matter how much you test and how much you try you will always have bugs when you go to production um and this is an example of one of those so you have uh the same car parked in the same parking lot starting one minute after the other running concurrently and so this is only something we encountered after we went to production and what happened right here was that normally sometimes sometimes you know the network sucks you lose a signal and so a person will start a parking session and if we and if you lose this if he loses the reply and he tries to do it again we detect that it's a duplicate and we say hey actually you have a duplicate session don't worry but in this case because he tried and the minute ticked over from 31 to 32 between the failure and his retry turns out the new attempt was not detected as a duplicate and so we created a duplicate parallel parking session uh for the person um and that's obviously bad and so we had to sort of augment our item potency protocol in order to handle this check item potency is a very fancy way of saying do things only once even if i asked for it multiple times um yeah so all of this was built with a pretty small team the total parking the sg team was pretty much uh yeah it was kaiwan in palani over there so like three three people at plus one uh p.m slash designer depending on what phase the project it was um and obviously a whole lot of help from the agencies that we work with so in summary uh if you were to take away a few things from this talk it is one do small things well because that like it is very very rarely the case that doing a lot of things very poorly is a better option um two focus on the next concrete step because when you're dealing with technology you almost by definition are doing something new and so there's a lot of things you can't plan for so it's better to start exploring rather than try to over plan for it and finally three forget about blame design for the user because in the end if the user doesn't get what you're doing and they don't benefit then you haven't really done anything um and that's it i will end with a little pitch because my team is hiring and we are at gov tech um so if any of what we talk about today seems interesting to you you can check out our website at open.gov.sg we are in-house product development team um and that's it all right thank you so much