Once you’ve decided to build a website or mobile app, either as an entrepreneur or business enterprise, there are some key steps you need to take very early on. While it’s convenient to think a developer can throw out an accurate price estimate after a phone conversation, maybe even a short meeting, the truth is that an estimate you can actually ‘bank on’ comes only after a detailed discovery scope.
It’s important to first mention that a successful developer usually views a new client as a long term partner, not a ‘one-and-done’ project. If you are working with a developer that views working with you as a partnership, then you can be sure that the more time and effort spent in the discovery and estimation process, the more focused and lean your final cost, and final product!
An experienced developer knows that almost every client can save a ton of money by narrowing down the key features required to launch version 1.0 of the software. This not only saves in development costs, but it allows the product owner to focus on successfully demonstrating core features to users, while facilitating the users’ feedback to determine the best enhancements to spend money on in version 2.0 of the software. Additionally, experienced developers know that if you don’t save a healthy amount of your budget to obtain and support users to your platform after the initial launch, then your software is likely to fail. This obviously doesn’t work well for a long term developer/client partnership!
To arrive at an estimate which you can rely on, it’s helpful to view the process within three main areas:
- Define the software users’ needs.
- Define the process to complete the project.
- Define the metrics by which the project will be judged a success.
In this blogpost, we will focus on the first area — Define the user needs
What problem do you solve?
When discussing the concept of your project with your developer, including all the features and functionality of the software, make sure you start by defining the problem you are solving for a user. E.g., the way it’s currently done looks like X. With our new digital platform, the process will look more like Y. In that process, be prepared to literally explain every step you envision a user taking from the moment they’ve logged into your software, to the time they have completed a session and logged out. Don’t worry if you might be missing something, as there will undoubtedly be plenty of refinements to the user experience as you iterate with the developer’s creative team about your concept.
A day in the life of your user(s)
In order to ensure that you are covering all the needs of your user base, you may want to start by creating what developers call ‘personas’. A persona defines an archetypical user of a particular software system. It’s a detailed example of a fictitious person who would use your software. It’s usually a two to three paragraph write up describing one of your user types, where there may be a handful of different user types (and thus a handful of different personas which you need to define).
When you write a persona, you start by creating their name, then their socio-economic and family background, their daily routine, their primary needs and desires… all within the context of how your software might touch one small aspect of that routine, and improve their experience. You may refer to these personas by name throughout the entire project so that you better guide your developer’s decisions about functionality and design.
With personas, now the entire design and development team can be on the same page with you, and the product managers of your software, when discussing how each feature in your software directly affects each of your primary users.
Prioritize features and functionality
Rank all of the possible features that users of your software might have. Start with those that the user would need most in order to solve their problem, to those that would be ‘nice-to-haves’. Some features will make version 1.0, while others may fall into later versions of the software. A good developer usually has no problem telling you the features that you DON’T need in version 1.0. Yes, that’s less money in their pocket initially, but again, it all comes down to making sure you have remaining capital to market and support your software after launch. This translates to a successful product and long-term partnership with your developer.
Roadmap it
Don’t be embarrassed to explain your features by demonstrating them with crude, even ‘back of the napkin’-type sketches. Your developer’s UX/UI designer will be thankful for every bread crumb that you can give them so they may design something that successfully translates your vision to the screen. Your developer may even convert your sketches into an abbreviated set of storyboards and wireframes before even calculating your initial project cost estimate. This will help to eliminate any misunderstandings about what you can expect in your final product. Of course, if you decide to pull the trigger on your project after the discovery scope and final estimate, then the developer will start by completing a highly detailed set of wireframes that will inform the final designs, and the code behind them.
Utilize competition
During your discovery scope, be sure and mention any other websites or mobile apps that provide some of the same features you want to provide to your users. This can really help your developer hone in on what’s currently available that works, and what doesn’t work, for solving the same or a similar problem that your software seeks to improve. Most developers take these live examples and use them to refine their search for even more examples of user experiences, or to create new user experiences to further improve your software.
Summary
Defining user needs can be the most time-consuming portion of your project. However, thoroughly tackling this stage will help create a finished product that becomes something your users feel like they can’t live without! And before you ever spend a dime to code your software, you’ve narrowed it down to only those features that your users need, which of course can save you a lot of money in development costs!
In the next blogpost, I’ll discuss how your development team can take your completed user requirements and convert them into a detailed estimate and timeline that you can understand, and rely on!