But why do we need to design software?
Imagine that you’re an architect. You might have a vision of the house — a photo from Pinterest or a verbal description like “a wooden house with blue walls, three rooms, a chimney, and a pool in the backyard.” But you don’t give these references to construction workers. Each building project starts with a detailed technical drawing of a future house — even if it’s just a barn.
Software development is like building a house. A technical drawing is a way to not only make the project requirements as detailed as possible but also to “translate” your vision to the builders’ “language.” It works the same way in mobile app development. The design stage is essentially to create a “technical drawing” for your future app. It’s important because your development team can’t start coding without a plan — just like construction workers can’t build a house with shovels and a photo from Pinterest.
Wait a minute, isn’t it just about choosing button shapes?
When you’re building a house, you care about the “dweller experience” — or you’ll get this:
Interior design is a part of this experience. But you can’t choose the furniture for the bedroom if you don’t know the size of the room. And UI designers can’t draw all the screens for all the possible scenarios if they don’t understand the app logic. It doesn’t mean that UI design is not important. But you can’t build an interface without knowing the system’s structure and interaction points with the intended user. So yes, choosing button shapes is a part of mobile app design. But this stage of mobile app development is more than drawing screens in Figma — it’s a “technical drawing” for the entire app.
I’m a startupper, why should I know how to design software?
You don’t have to know all the intricacies of this process — design is a job for software architects. However, having a general idea of how software works will improve communication with the development team. If you’re at least a little tech-savvy, you can refine your app idea and explain what you want from your team speaking their language. At the same time, you still think of the future product from the business point of view — and you can provide this outlook to your developers.
Even better, if you know a thing or two about mobile app design, you can improve time management. This knowledge allows you to think of your future app more realistically so you won’t ask your team to train a neural network in two months.
What we’re about to discuss in this article might seem a little difficult for people with no background in coding. But you don’t have to dig deeply into this subject — if you’re a startupper, getting the general gist is enough.
Fine, what is software design?
If you’re interested in the UI part of mobile app design, you can read the article about how our team established the design process that works best both for us and our clients. We’ll tackle interfaces here but it’s not the main focus.
Software design is the transformation of user requirements into detailed instructions for developers. It includes detailed descriptions of architecture, data structure, algorithms, and user flow. Despite its focus on the technical aspect, designing a mobile app is still a creative process — at this stage of mobile app development you:
- come up with a system that solves users’ problems;
- figure out the best way to make this system work.
So, how do you design software?
Let’s say, you’re working on a meditation app MVP with several basic features. In the future app, users will create accounts, choose guided meditation files from a library classified by audio length and purpose, and pay for a subscription service to access the full archive. You can’t go straight to development right now — you need to design the software first.
Software design consists of two tasks. Firstly, you figure out how your future app should work as an information system — its basic components, data structure, storage, and exchange, basic entities, and other design patterns. Then, you describe the system using UML diagrams.
UML in software design
UML stands for Universal Modeling Language. It’s a graphic language for modeling any information system — how it works both for users and developers. In software design, UML diagrams play the role of a bridge between your app idea and the clean code that will make it work. Think of UML as an interpreter. For you, it’s the way to describe your app idea to your development team. And for developers, it’s the way to figure out how exactly they can bring your idea to life. Even better, UML is an ISO standard which means that you can use it with international development teams.
There are 14 types of UML diagrams — some of them describe the system itself, others describe user behavior during interaction with this system. But each diagram shows:
- things — elements of the system, for example, a user or a server;
- properties — characteristics of things, for example, a user has a name and an email;
- relationships — how things are connected to each other.
Let’s take a closer look at 4 types of UML diagrams — two behavioral and two structural. We chose these types of diagrams for two reasons:
- they describe the most basic and important software design patterns;
- you can’t avoid them when you design software, but other types are optional.
Component diagrams
Component diagrams are a high-order model of an information system. They break down this system into components — modules that are responsible for one clear function within the app. Component diagrams don’t go into too much detail — but they allow you to visualize the physical structure of the future app.
This is the component diagram for our meditation app.
It shows how meditations are stored in the app and how the content library interacts with other parts like a backend server. As you can see, the app architecture consists of 7 modules that perform one clear function. These modules communicate with each other via interfaces, which is their interaction “language.”
The “socket” symbol means that this component requires input, and the “ball” symbol means that this component provides output. But sometimes, components don’t know which data they will receive or give. These interactions are marked with “ports” which are depicted as little squares on the edge of a component symbol.
This diagram is a simplified model — for example, it doesn’t include user accounts as a component. But it’s representative enough and it shows the basic app architecture.
Class diagrams
You are probably reading this article while sitting on a couch. But it’s not the only couch in the world — a lot of furniture pieces fall under the definition of the word “couch.” In this case, the couch you’re sitting on is an object, and the word “couch” is a class.
In software, similar data pieces are categorized into classes. For example, all users have unique nicknames but give the same personal information in the registration form: email, login, password, etc. “User” is a class — a group of similar objects with similar information about them. Class diagrams show which classes exist in your app, their properties, and the relationships between them. When you design software, you can’t ignore the question of data — and these diagrams describe all the data types your future information system will require to function.
For example, here’s the class diagram for our meditation app.
As you can see, our app has two subtypes of users. Contributors add their own guided meditation recordings to the app library — they create new objects in the “meditation” class. Listeners can only listen to uploaded files from the library and buy or cancel subscriptions. Meditations have user ratings and contributors who created and uploaded them. Apart from standard metadata, meditations are also classified by purpose — like anxiety, productivity, or better sleep. There’s one audio file for each meditation. It’s a “blob,” or a Binary Large Object, which means that audio recordings are stored as binary datasets.
Keep in mind that it’s a baseline diagram. You can add more elements — like content moderators as a user subtype.
Use case diagrams
Unlike the two previous diagrams, a use case diagram shows the expected user behavior, not the app structure. It represents possible goals users can achieve while interacting with the system — but not in detail. They don’t show all the connections between users, use cases, and the system. But they still provide the intended user’s point of view.
Use case diagrams consist of three basic elements:
- Actors — people, groups of people, or institutions that interact with the system. For example, our meditation app project has four actors: subscribed users, non-subscribed users, administrators, and contributors — users who create and upload guided meditations.
- Use cases — automated or manual system functions, the reason why actors interact with the system in the first place. Some of our meditation app’s use cases are “login” or “play meditation.”
- System — the app that fulfills use cases.
Let’s go back to our example — this is a possible use case diagram for our meditation app.
This diagram shows two user roles — listener and contributor. One important detail in this scheme is that contributor accounts share use cases with listener accounts. Another shtick of our diagram is optional use cases. Extend relationships show that the child use case is a possible scenario that is available but is not necessarily followed, for example, listeners can rate meditation recordings but they don’t have to do it. Finally, the “search by length” and “search by purpose” use cases are more specific versions of the “search for meditations” use case.
The number of use cases, actors, and the complexity of connections between them depend on the app functionality. One possible extension of this scheme is adding a content moderator as an actor.
Activity diagrams
Activity diagrams, like use case diagrams, describe user behavior during interaction with the system. But they are more specific — they show the order of actions for one goal. For example, to sign up for the app, you enter your email, create a password, receive a confirmation letter, and click the link in the letter. Activity diagrams are vital when you design software because:
- they are essential for UI since workflows affect the app screen order,
- they decompose complex use cases into simpler steps which allows you to clarify and improve certain processes,
- they visualize the algorithm logic.
This is an activity diagram for our meditation app.
The questionnaire branch is optional — but if your app had this feature, that’s where it would be in the user flow. Again, like all the rest of the examples, it’s a simplified version — you can make it as complex as you want. For example, you can add the “save meditation” step before the post-condition if you decide to add the bookmark feature.
But what happens next?
Software design is a part of the Software Development Life Cycle,or SDLC. It consists of 7 stages:
- Planning
- Analysis
- Design
- Development
- Testing and integration
- Maintenance
But once you modeled the whole system and gave the task to your development team, it doesn’t mean you’re done with the design stage. You will keep coming back to it for different reasons — to resolve issues you recognized during testing or to specify the task for coders during development. And if you’re working on an MVP, you will refine your design to provide a better user experience.
Hiring a development team for MVP is expensive and time-consuming. If you have no background in computer science but want to design software by yourself from scratch, you’ll spend more time resolving issues in further development stages. The solution is to outsource the MVP development — and Purrweb is here to help. Our team will nurture your project at all SDLC stages. And we love to design software and care about efficiency and user experience — even if it’s just an MVP.
Have an app idea? We’ll be happy to work with you — feel free to tell us about it in the contact form below.
