Planning an Application

As developers we like to build things, to get our hands dirty. Writing code, debugging, testing, deploying are all part and parcel of our process. But in our rush to construct we can forget the benefit of seeing the forest through the trees before hacking away at the branches. The investment we make in planning will help create a clear path that ultimately minimizes the number of wrong turns we make while building our apps, and if we should stray off course, provides a solid framework to get back on track.

Let’s look at steps we can take to help focus the planning stages of our coding projects.

FUNCTION — The big picture

The most fundamental question that we need to answer is why? Why are we going to spend all of this time putting together this beast. This is the story. If the answer is purely for the sake of learning a new technology, a pedantic exercise as it were, then overall function is not as important as the actual coding. However, if we hope that others will use and get some benefit from our work, we need to spend some time answering some important questions that will drive the overall design.

What’s the purpose of the application?

What is the intent of the app? What will this app do? Seems simple, but putting the purpose of the application into words will help to clarify the intent. Will the app be used to sell something? Will it connect people to services, to each other? Will it serve to benefit the needs of under represented members of society?

It may be that the app has falls into several of these categories, but there should be a main focus.

Who is the audience?

Audience is important. Is there a particular demographic subset that is being targeted with the app. This is important not only because it can drive esthetic choices, but also can help to understand what technology may be used to interact with the app. An extreme example — I lived in Myanmar for a few years at a time when the government had just loosened their grip on the internet, opening service to private ISPs. Within a few years the country went from very low internet access to a situation where everyone had access to cheap data on inexpensive mobile phones. A web site that was designed to be viewed on a desktop, or even tablet, was useless if you wanted to reach a large audience. Intended audience can drive decisions about the importance of format and responsiveness.

Does the app need to have different levels of access privileges?

Is the application completely open? Is there a need for authentication to provide a more personal experience and/or to provide some privacy? What level of privacy is required can be driven by the level personal information that is intended to be shared. For example, private healthcare information needs to have security that conforms to very strict HIPAA compliance.

Is there a need for a separate admin section? If so, how will the functionality differ from a the needs of a user?

What features will be required?

This is where we should begin to list what functionality we want to offer. The features will drive what information we need from users as input, or from external API requests. These decisions will help map out what our data looks like and will what type of data structure will work best (SQL, noSQL, GraphQL, etc).

If the app’s function relies on user input other than text — photos, videos, graphics — how users will interact with the app changes. An app that requires users to submit photos needs to work well on a phone since most people take photos with their phones and won’t care to transfer their photos to a desktop or tablet.

DESIGN — UI/UX, the look and feel

Here’s where we start to make more concrete decisions about the look of the app.

1. Basic layout — single scrolling page, menu linked pages, dashboard, header, footer
2. Design themes — color pallet, font
3. Responsiveness — how will the look change on different screens
4. Accessibility- making sure everyone can use the app
5. Frameworks — Bootstrap, Material, Semantic UI

This is the point where it’s important to draw out some wireframes/mockups of ALL content, either with pen and paper or one of the many online services like Figma or Mockflow.

When making wireframes, it’s important to think about how sections with dynamic content will adapt to more content. Also make sure to sketch out how the app will look on a phone or tablet.

TECHNOLOGY

Now that we have a clear idea of what the app will do and how it will look we can decide what languages/frameworks will work best. There are probably a number of equally suitable solutions and it may come down to what platform you are most comfortable working with. Some considerations:

1. Ease of use
2. Scalability
3. Future support

This is also a good time to make some definite decisions about what the data structure will look like. Tables and associations for a SQL database and collection/document structure for a noSQL database. How will the data be organized in the frontend session?

CONCLUSION

As we complete the planning process, the conclusion becomes the beginning. We’ve already made many decisions before ever opening our IDE. Armed with a clear vision of our app’s function, audience, and features, in addition to having mapped out its structure, we have armed ourself with the foundation necessary for moving forward confidently. Time well spent.