So you’re building an app. You’ve thought of all the problems it will solve and how sleek it is going to look while it does. Great! Now it’s time to roll up your sleeves and get to work.
One of our past articles outlined some ways to organize your idea to help you find the right developer. Now we have some more tips that could come in handy after you’ve hired a developer. Anticipating the need for this information will allow you to prep in advance, sound like a pro, and keep the project advancing.
How your application is designed on the “back end” isn’t something that typically gets much attention from the idea makers (which is understandable because it is a bit mysterious). Basically the gist is, the system you are building has to have some way save, access and change data.
Let’s look at a simple example. Say you are building a site that sells pudding pops (because they really do need a comeback). Outside of the obvious things like an interface that clearly shows these are the OG pops and provides a way to purchase them, you’ll need to have a couple of “things” to support this:
1 - A user account
2 - Actual Pudding Pops
For the user-facing interface, you’re typically thinking through the actions that a customer would be taking. We’ve all be customers, so that part comes easy. But now we need to turn our attention to the part of the planning that considers what things are being acted upon. What are all the things? This is not quite as natural to think about. In our pudding pop example, we know that in addition the the product (Thing 1), our potential customers that order from the website will need an account (Thing 2). As the owner, you know you’ll need their name & physical address to deliver it, their email to correspond order progress, and a password for them to access the account. So you can tell the developers you’ll need this info and they’ll turn the details upside down and inside out so they can make the right decision for your application. Here are several questions you can ask yourself about the each identified thing:
-
How will the data get in the application?
-
How will it be updated?
-
Who needs to see it?
-
Where in the interface will it be seen?
-
Who needs access to update it?
When you are thinking about the answers think about the future of your application. You may be be doing a scaled back minimum viable product (MVP) right now, but changes to the data architecture can be costly down the road, so try to give answers that reflect both current and desired future functionality. Let’s go through what these answers might look like for Thing 1 - Pudding Pops.
-
How will the data get in the application? - We will input products and information through the admin interface for the site/store.
-
How will it be updated? We will update it through the site interface. We will not be importing spreadsheets or other external data.
-
Who needs to see it? Anyone using the site (even guests that are not logged in) need to be able to see the products, categories, images, descriptions and prices. The store administrator will see exact inventory numbers and customers will only see a notice when there is not enough inventory to fill their order.
-
Where in the interface will it be seen? Products will be visible on product pages, categories, searches, in cards and orders, past orders, inventory, and user favorites.
-
Who needs access to update it? The store administrator and director of sales will be allowed to add, edit and remove products, but employees will not. The head of marketing will need to be able to update the images and description for products but can not change prices.
Tip: If your development company is not asking these questions, you can bet they are making some assumptions and choosing a course of action without your input. If it is simple it might be fine, but it never hurts to clarify the details.
Thinking through how the “things” in your application work is beneficial as you might have some assumptions that your literal thinking developer does not. Anticipating these needs will ensure the end product matches your expectations as well. One way to envision this is to think through the physical journey of your product (if there is one) as virtual spaces tend to share many of the same touch points as the software (like the warehouse [database], the sales brochure[homepage], the reports for accounting[reporting]).
Having this detailed assessment helps developers make good choices for data storage. Here are some things they are considering:
-
what type of data is getting stored; different data types take up more space than others
-
efficiency
-
security
-
long-term scalability
In addition, it can be beneficial to the design team in making sure they provide designs that cover all of the different interfaces that will need to be built.
For any application to be successful you need it to do the right things, the right way. This should be a collaboration between you (the business expert) and your developer (the tech expert) to make sure the needs are met and the data supporting it is set up correctly. If you can think of something you need the application to do, bring it up. It may seem tedious, but skipping past a need (‘I need to be able to update product pricing’) and assuming it is handled is a good way to end up with a product that doesn’t do what you expected.
In conclusion, the success of your app hinges on the meticulous planning and collaboration between you, the visionary behind the business, and your developers, the technical experts shaping your digital dreams. Beyond the user interface, the backbone of your application —the data architecture— also demands thoughtful consideration. By delving into the specifics of each component, or "thing," you empower your development team to make informed decisions that align with your current objectives and future aspirations. Asking key questions about data input, updates, visibility, interface placement, and access ensures that assumptions are replaced with clarity. Remember, if your development company isn't posing these queries, clarifying details is not just advisable; it's imperative. This collaborative process extends beyond functionality—it guides data storage decisions, aids design teams in creating comprehensive interfaces, and ultimately ensures your application performs as envisioned. So, roll up your sleeves, engage in this fruitful collaboration, and watch as your app transforms from concept to a seamlessly functioning reality.
