Explaining App Idea to Software Engineers

How do you explain your idea to another person? It is natural to share your thoughts, plans and ideas with close friends, but talking to strangers may feel awkward. If your friend does not quite understand your idea, it is no big deal. But if the experts you hired to implement your idea misunderstand your requirements, you are at loss.

When someone wants to build an app, they need to explain their idea clearly to the engineering team. Communicating requirements is not easy. It takes effort to come to a shared understanding, as everyone sees things a little bit differently. What information do the engineers need? How to ensure that the app owner and the team are on the same page?

App Features and the Big Picture

The purpose of any app is to help some people solve their problem. For example, an app with learning games helps kids to get acquainted with numbers and letters, and parents to take care of their children's education.

In order for the engineering team to capture the app idea, they need to understand what problem the app is trying to solve. It may be just one simple phrase, like "to help kids learn letters", but the team will need to refer to it later.

Most of the time you will talk about the features of your app. Especially about the unique features you have come up with that will make you outperform similar apps. While you will tell the engineers lots of details about how you envision the feature, you may forget to mention the reason you want to add it, what problem it's meant to solve.

Before discussing feature details - screens, buttons, animations, user interaction, the engineers need to understand why this feature is needed. If its purpose is unclear, the technical details may be easily misunderstood. When the project owner dives deep into the details, it becomes increasingly harder to get back to the initial goal, to the overall idea of the app. That's why it is useful to begin describing any app feature starting from the big picture and answer the question "why" to yourself. So you can better understand your own intention.

If the software engineers working on the app understand the overall idea, they do not need technical details to make it work. It is enough to know the goal. For example, if the function is, "For every correct and incorrect answer, a sound should be played." If the team remembers that the ultimate goal is to help children learn, then it is obvious that the "wrong" sound should be something unpleasant like "Boo!" and the "right" sound should be something nice like "Yay!".

When the customer explains their idea of the feature, they focus on their suggested solution (what to do?) rather than the problem to be solved (why to do it?). And the engineers have to focus on the problem, so they may come up with other possible solutions. They know the app and the technology, so they may see options to get to the goal with less effort and with better results. Knowing the big picture helps engineers to instantly grasp what is an essential part of the new feature and what is not.

Stating the Obvious

It is very difficult to articulate the "obvious" and "self-evident" parts.

If this is your app idea, you've probably been thinking about it for a long time, and many of the thoughts and related facts have become your "second nature" so you don't even realize them anymore.

On top of that, you probably know a lot about the industry you're building your app for. And people who know a lot about something often have a hard time talking to less experienced people as for many things they assume that "everybody knows that".

Certain facts may be well known within the industry, but be completely unknown to the outsiders. It may never occur to you to tell the team about these "obvious facts". And only after extended discussion with the team an "aha moment" comes, and you finally realize that the team is missing this crucial piece of information to put the puzzle together, and after you tell them, they finally get it.

The "rule of thumb" is to talk about everything even remotely related to the app idea, so that you may stumble by chance on a certain fact which the team was totally oblivious to. Sometimes, when talking to the team, the project owner tries to "stick to the point" and not digress to "irrelevant things". Sometimes questions asked by the engineers feel remote and irrelevant to the task at hand. However, the context is still very important. So, to be on the safe side, we should capture more context first and then sort it later to see what is relevant and what is not. Missing some relevant points may lead to a costly misunderstanding.

You may have an assumption about the app. You take it for granted, so you never mention it explicitly. And what if the engineers do not share the same assumption? Then you’re up to a nasty surprise along the road.

For example, the owner of an app for the factory workers may be used to the fact that there is no wifi and no mobile network at the factory location, so the app needs to be able to work offline. But the software engineers living in the "always connected" world may not have the same assumption.

Finding Common Language

When the project owner does not have technical background, they may fear that their lack of technical expertise will be a problem in communication with the team. They worry about talking to software engineers, asking themselves "How can I explain my idea to them?" After all, software engineers are notorious for using cryptic phrases and a non-engineer cannot understand a word, so they feel inadequate and become frustrated. Naturally, they are afraid to be misunderstood or worse, not being understood at all.

To build a shared understanding, both the customer and the engineers have to speak the same common language.

Every normal human (including software engineers) can speak ordinary human language. So there is no need for the customer (project owner) to learn technical jargon. That's why our engineers talk to the customer in plain English, avoiding using any technical jargon. Any app idea can be explained in simple words. In fact, the idea will only be properly understood once it is explained in simple terms.

When you discuss your app and engineers start using lots of technical terms, please speak up:

• Interrupt the engineer if necessary (assuming he is talking to you and not to some other engineer),
• Inform them that you did not understand what they were trying to say,
• Explain that there is no communication happening at the moment,
• Politely ask them to simplify their message without technical jargon.

Refuse to be bullied and frustrated by the technical jargon, demand proper communication from software engineers working on your project.

Experienced software engineers know the importance of speaking in simple terms and make a conscious effort to explain their thoughts in plain language. Sometimes they may slip up and blurt out some cryptic jargon word. And they will be thankful to you if you point it out to them, so they can correct themselves and explain their idea in simple words. After all, they want to be understood by you.

While working with engineers on their app, the project owner naturally learns about the underlying technology. But the app users are still regular uninitiated people. And the team relies on the customer's ability to represent them, to speak for them.

Working Towards Shared Goal

Writing quality code requires a software engineer's full attention. When they work on a project adding app features week-by-week they have to focus on minute details of the code and technology. As a negative side effect engineers may forget about the overall project goal, and get lost in an ocean of features. It is necessary to remind the team every now and then about the big picture, the final destination of the journey, the ultimate goal of the project.

Both the customer and the team want the project to be successful. And what outcome will be considered a success? The customer usually has a best case scenario in mind, but they may not be ready to describe it in any detail. What amount of users is expected if the app is successful? What is the total number of user accounts? How many sessions occur daily? What amount of sales in the app is expected per day/month/year?

Over the course of development, the app idea may transform slightly or even dramatically. Getting everyone on the same page once again is crucial to maintain focused team effort, to make sure everybody is working towards a shared goal.