Here are the five key steps again that will get you closer to the successful delivery of your application:
It can be extremely difficult to predict how your software is going to be used. No matter how much planning goes into the design, your ideas may be different to the expectations of your users or too complicated for them to grasp quickly. Innovation is tough to get right the first time, so you need to be flexible.
This can be a very difficult thing for an entrepreneur to come to terms with, but a key part of the planning, design and development process is to anticipate how the app will evolve and change. If the core software is designed modularly, then it should withstand the necessary demands of evolution.
In the development of our document management app, OurDisk, we actually went back to the drawing board and built V2.0 completely from scratch. Version 1 served its purpose and provided a market understanding and technical base that allowed us to successfully build the app exactly how our users wanted it – smarter, faster and cleaner and infinitely more flexible for future updates.
Plan the release of your application around a ‘core’ that you can get to market quickly to test the idea, then bolt on functional elements as your users demand.
Start with a basic V1.0 and build on it. The bells and whistles can always come later. Remember that the more functional elements you build into your first release, the longer it will take to code, the more bugs it will have, and the more risk you will carry.
I once witnessed a project (not one of ours) where the owner was so obsessed with adding superfluous features that it never even made it to market.
In our experience, factor at least 15-40% of your budget toward modifications that will need to be made after initial market testing and user feedback. No-one gets it right the first time. Some changes may be small, but others will be complex.
For example, a client was convinced that advertising positions on their high-traffic website would sell easily using an auction model for the best ad positions. Significant funds were used to develop the system for global delivery and 3 months after launch the sales team changed their approach and decided to move to fixed price and bundled packages.
Needless to say that this was an enormous change in functionality and proved extremely costly. In hindsight, keeping the sales process offline until the project had found its feet would have saved thousands of dollars.
You can never predict the buying behaviour of your customers, so test the market as simply as possible and then grow. Use the K.I.S.S principle. If it’s not vital in the first release, leave it out.
Developers often get a bad rap for time overruns on web development projects and with over 10 years in the business, we have seen our fair share of deadline delays. The last 10% is often the hardest part to complete as test users provide feedback and your ideas and creative juices run wild.
Our advice is to work closely with your development team. Communicate often and make sure you stick to the specification. Adding additional functionality towards the end of a project is usually the main cause of overruns because towards the end of the project the code is at its most complex, small changes can have a large flow-on effect and testing cycles take longer.
Set short-term (14 day) manageable timelines with achievable goals in negotiation with your developers.
Most applications are built around one very good idea that potentially solves a market need, the challenge is strategically inserting your app into that market as quickly as possible and then building on that single idea with useful features that your market love.
In the initial scope and design phase, structure the app design around getting the ‘absolute core’ concept bedded down and construct a list of possible features that are ‘predictable’ market requests that would be great to have if budget permits. Also, factor in a budget for unknown features that your market will identify for you after your first release.
In our experience, your ‘early adopters’ will have a variety of feature requests and desires and attempt to lead you down a path that suits their needs. This is a blessing and a curse, so proceed with caution. Feature requests should have an overwhelming demand before considering them for inclusion.
Features that you anticipated your users will love, may never get used and vice versa. Just because one client requests a feature, doesn’t mean your other clients want it.
Listen to your Users
Users love being involved in the app development process, factoring in flexibility builds a strong supporter base and community.
Some key points:
Jason Hawkins is a senior application strategist, information architect and director at KND. His knowledge is based on years of industry experience in taking online application ideas to reality across a broad range of industries.
KND are web and digital professionals with over 10 years in the business. We specialise in web, cloud and mobile apps, eMarketing and SEO strategy, servers, hosting and design. We work closely with our clients to achieve successful outcomes. Call us today (+61 7 3367 0600) or email (firstname.lastname@example.org) to discuss your next project.Posted by Jason Hawkins on 8 February 2012