At this stage, you’ve validated the Business aspect (see previous article Let’s Talk Business) and have been able to calculate a maximum completion timeframe and budget for this new application. Finally, you have at least one person in your company capable of seriously monitoring the project.
Every detail is important #
If you, like me, have already been involved in this type of project, you know that every detail matters. That’s why I strongly emphasize the need to list and detail all your expectations in a single, comprehensive specification document. Without writing these detailed specifications, there’s a risk that your service provider will give you a completely inaccurate quote, or that they will make certain choices for you, with a high probability that these won’t ultimately suit your needs. You’ll then have only two choices: accept their deliverable “as is” or pay again to have it modified. Another example: SaaS providers often offer different subscription plans with varying limitations and features. Simply stating that a SaaS offers feature X or Y isn’t detailed enough. The functionality you absolutely need might be absent from their “Pro” offer at EUR 20 per month but present in their “Enterprise” offer at EUR 200 per user, with a minimum of 50 users. This would naturally exclude that SaaS from your selection shortlist.
Product Requirement Document #
The Product Requirement Document (PRD), which I’ll also call the specification document, is a key document that details your application’s expected functionalities and requirements. Whether you’re hiring a freelance developer or issuing a complex tender, a clear PRD is essential to avoid misunderstandings or gray areas during development. Try to keep it as simple and collaborative as possible, for instance, as a read-only Word document accessible to your developer. For projects using one of the so-called “agile” methodologies, a ticket and task management tool like Jira is a complementary management tool for iterative implementation. However, it doesn’t exempt you as the client from writing a first version of the PRD and then updating it with each iteration. More challenging to master, UML and BPMN diagrams help developers better visualize and understand the workflow and system interactions you expect. Rest assured, they are recommended but not mandatory in a PRD. As mentioned earlier regarding the importance of details, remember that no programming language has an instruction like “it should work like this 95% of the time.” It’s imperative that your specification covers all cases!
Screen mock-ups #
Screen mock-ups are a fantastic tool for visualizing your application’s user interface even before development begins. To some extent, they also clarify its internal workings through the content and functions accessible on its screens. A simple PowerPoint with screenshots, or basic geometric shapes with explanatory text, can already give the developer an idea of the interactions you expect from your application. More advanced tools like Balsamiq allow for the creation of more complete “wireframe” mock-ups by adding structure and some interactivity (jumps between screens, links, dropdowns, etc.). For more sophisticated mock-ups, offering a final view of your application with a “pixel-perfect” design using your brand guidelines, Figma is an excellent option, also offering real-time collaboration.
Multilingual application #
If your application targets an international clientele or regions with different languages, you must list this requirement from the very first version. This goes beyond simple automatic translation with Google Translate or DeepL: You need to consider cultural aspects, date and time formats, and text direction. By the way, a quick tip: If you don’t master one of the languages to be translated yourself, outsource it or refrain! Avoid Google Translate or equivalents if you’re unable to verify the translation quality.
Graphic charter and images #
Your application’s graphic charter (or brand guidelines) is essential for its visual identity and recognition. It defines the colors, fonts, logos, and all the graphic elements that will constitute the aesthetic of your website or mobile application. If you’ve just started your company, you’ll likely hire a graphic designer to create your visual identity, both for your digital media (websites, Facebook page) and physical materials (flyers, business cards). I strongly recommend that you do not rely on your developers to handle this part (everyone has their specialty) but instead provide them with all the images and illustrations they’ll need. Naturally, this requirement is optional if your application will remain for internal use!
Classification of business needs #
Using your specification document as a reference, fill out an Excel spreadsheet with one row per business requirement, in summarized form. Then, categorize each of these rows according to its importance:
- Mandatory: This requirement is essential for the application to be selected by the screening process (if purchasing an existing application) or must be developed (if it’s a custom application).
- Important: This requirement will be a decisive criterion in the selection process or must be developed as a priority.
- Optional: This requirement will be a secondary criterion in the selection process, or its development can be done if there’s budget remaining after the implementation of all “Mandatory” and “Important” requirements. This framework will allow you to make a rational and impartial selection of your future application from market offerings, or to prioritize the development order of each requirement.
Contact #
Feedback is always welcome! Feel free to contact me by email contact(at)candle8.app or on LinkedIn.