Here at Delib we are pretty happy that our products help make it easier for government to engage with citizens in decision making. We work hard to make these apps as good as they can be. Every once in a while we get suggestions from our customers on how we can make things even better.
Do you actually do anything with these suggestions?
The resounding answer to this is yes! When your account manager thanks you for the feedback it’s not just lip service. Your suggestion is included in our product forum where the account managers, developers and MD discuss how we can improve our apps. Product features we can crack on with are then considered for inclusion in upcoming releases.
Why can’t you quickly make changes to the apps if it is obviously a good idea?
Making changes to the apps isn’t something we do on the fly as any change will affect all our users. We investigate, test and discuss suggestions to make sure that an idea which makes a lot of sense on the surface works well in practice. We also look at the change from a customer perspective to make sure it improves user experience.
How long do suggestions take to develop?
We have a nicely structured calendar of two and four week development cycles, plus a bunch of feature-focused product updates each year.
There is no golden rule on how long developments take as each one is different. Development timeframes are entirely dependent on what the change is and making sure that the change works as well as we need it to. The questions we ask ourselves are: Is this good enough? Will this make everyone happy? Is it clear how it works? If the answer to all of these is ‘yes’ then, provided all else is good, we will ship it out.
We work on all three of our applications, so development cycles are also shared between the products – we may be focusing on Citizen Space one month and Dialogue App or Budget Simulator the next.
How do you prioritise these improvements?
The first priority is fixing bugs. No software is free of defects and we want to keep ours as healthy as possible. The second one on the list is fixing issues that aren’t bugs but will improve usability for customers. This helps to minimise support requests and let you guys, our lovely customers, get on with using the apps! The third priority is scheduled items that are customer co-funded. The final developments we look at are improvements we want to invest in to make the product better.
What we call ‘housekeeping’ or upgrading the internal aspects of the software is kept separate to developing new features. The reason for this is the two are quite different beasts and need to be focused on independently.
What are some examples of developments?
Developments can include:
- improving the technical architecture of the system (for example, to improve performance)
- improving user experience / usability of existing features
- making more of the application’s behaviour customisable by admin users
- features which add new capabilities to Citizen Space
Sometimes we have to make changes to the underlying infrastructure around our apps and this kind of work also gets built into our development process – a recent example of this was moving Citizen Space sites to a new hosting environment.
How we release new features
To release a new feature we run a formal QA process internally which tests for things like data integrity, cross-browser compatibility and accessibility. We test improvements and new features with our account managers and other staff to make sure we are considering the change from a customer perspective.
While this means that the total time to get features into the hands of customers can occasionally be quite long, it ensures that the quality is high, and we don’t drop nasty surprises on our users.
Who are these people that are beavering away behind the scenes?
We have a team of four developers – Alan, Richard, Tom and Jess (who is currently on maternity leave). They built our applications from scratch and if you ever want to be surprised about how much one person can know, come to our offices and chat to our devs.
We have two QA specialists – Hamish and Stan, who thoroughly check every angle of the development work being done, notice and care about the small things and keep us on the straight and narrow.
Our developer and QA teams also work on the other necessary technical aspects of our business, such as responding to some of the trickier support queries, doing day to day work for customers and all of the system administration and security work that comes as part and parcel of being a software company.
We hope that explains how we do things here and why, and if you’ve ever any questions you can find us on email@example.com or by going straight to your account manager.