Difference between High-Level Design and Low-Level Design

Let's start from the basis.

The Software Development Life Cycle (SDLC) is a collection of steps followed by a team of software developers to create and maintain software. Actually, we do it every time with every client when giving birth to a new project. 

There are some phases like planning, requirements estimation, analysis, design, execution, testing, etc. Each stage is also divided into tasks with its results and objectives.

Let's go through the life cycle. Imagine we need to create a social media web application for creators where they can share their works.

1. Planning​

Here the project leaders think of the terms of the project. They calculate labor, and material costs for our social media, create the project's teams and set target goals.

2. Requirements

We came to the part of planning where we determine what social media is actually supposed to do and its requirements. For example, our application would require the opportunity to connect with friends, share photos, like, and comment. 

3. Design and Prototyping

During the Design phase, the team creates a way our social media will work. Here are some aspects of the design:

• Architecture – clarifying programming language, industry practices, and general design. 
• User Interface – specifying the ways our social media users interact with the app and how the software responds to their actions.
• Platforms – determining the platforms on which the app will run. For example, Apple, Android, Windows, Linux, or even gaming consoles.

At this stage, high-level design for web application is also done. One more part of the design phase is prototyping. A prototype is the earliest version of the app. It's a fast way to demonstrate a basic idea of how the application looks and works. 

Please, remember this stage. We'll talk about it more later. 

4. Software Development

Our developers' favorite part - implementing ideas. Time to brush up on skills and work as a team. After everything's done, they find and fix errors. 

5. Testing

What if you can't send likes on our social media? It's a phase to fix it by testing, testing, and then testing one more time. It's critical to test an application before launching it. Nowadays, much of the testing can be automated, like security tests.

6. Deployment

Finally! The application is available to users. To stay easy, deployment is downloading an application on a smartphone. For our social media, it will be downloading on the web. 

7. Operations and Maintenance

Congrats, we're almost done. The application is ready after using in the field. The Operation and Maintenance phase is still important, as we turn into bug detectives to discover problems that were missed during testing. So.. we start to plan a celebration call.

Ok, we figured out the whole process, and let's deep dive into the particular one - Design.

What is System Design?

System design is the process of designing any software application (thanks, cap). It's called "design" but actually is more about architecture. We're building a new project's flow.

When a company comes to this stage, it keeps in mind some essential questions:

• What features application will have?
• How many customers will use it?
• How many requests will come to the app during the period?
• How much do we want to scale our application, and how many costs do we have for that?

And we're coming to the sweetest part - design levels. There are two kinds of design:

• High-level design (HLD)
• Low-level design (LLD)

What is high-level design in software engineering?

High-level design is done by a solution architect to specify the general design of a system or application. Purpose? To transform the requirements of a client to a high-level solution.

It's a no-code stage which is rather about technical documentation and diagrams. You'll see it in a high-level architecture design example. If there are integration issues with other systems, they are also addressed in the high-level design. 

Non-technical people can understand the architecture and design of the final solution using HLD.

In high-level design, the designer only focuses on the various models, like:

• Decision Tables

You want a cookie but don't want to go out. What options do you have? Ask a friend and order delivery. If you write it in the table format, it will be called a decision table. 

In development, we solve different types of tasks but in a similar way. 

The design table can look like this. 

• Decision Trees

A Decision Tree is a readable graphic of the processing logic. It includes a choice tree representing conditions and, therefore the leaf nodes representing the actions to be performed looking at the result of testing the condition. 

For example, it can be done this way. 

• Flow Diagrams

A Data Flow Diagram (DFD) is a classic visual graphic to show the information flows in a system. An excellent and clear DFD can graphically tell you the exact amount of the system requirement. 

Let's flow in data flow example of the hotel room system. 

• Flow Charts

A flowchart is also a friend of a client. It graphically presents an algorithm. Coders often use it as a program-planning tool to fix the problem.

A piece of advice: take a look at the example to make sure you understand this point.

• Data Dictionary

A data dictionary represents the database's metadata. Such files or set of files hold records about other objects in the database. For example, data ownership, data relationships to other objects, and others.

The example will help you understand the data dictionary. 

The high‐level design includes such things as decisions about: 

• what platform to use (desktop, laptop, tablet, or phone)
• what data design to use (such as direct access, 2‐tier, or 3‐tier)
• interfaces with other systems (such as external purchasing systems).

To cut it short, HLD generally includes product flows, and ways modules interact with each other. If you need to answer what high-level design is quickly, say that it shows the general flow with no specific features. 

Imagine you're writing your life plan. From 0 to 7 you're just a child, from 7 to 18 you study at school, from 18 to 24 you're at the university. It's a plan without any specifications. You just see the general flow. Your specified target goals, tasks, and exact ways to enter school and university are about low-level design.

So in order to describe a general view of the overall solution, high-level design should include two main components:

1. Functionalities and attributes of components
2. Interactions and relations between various components.

Pay attention, dear. Here we don't think about languages like .NET, Java, etc., and specific things. The designer's task is also to assign responsibilities to the components made and define their interaction.

Look at this software high-level design example. It's done for an application to store, share and find media for media production use between people from different brands wherever they're located. Target audience - individual creators, small companies around the world within photo, film, and music production, and people considering photo & video as hobbies.

What is low-level design in software engineering?

Low-level design is more about diving into details. You take the parts of high-level design and start going into specifying how they would be composed and coded. 

Why is it "low"? It is only in comparison with the high-level design (HLD), which we talked about higher. It is named this way because low-level design describes individual structural units of the system and not the system itself as a whole.

To be simple, high-level design is responsible for the overall plan of the system, and low-level - for its particular components.

To be even more simple: low-level design is a detailed description of all components, configurations, and processes of the software or app previously approved in high-level design. LLD is a practical refinement of HLD.

Why and when do we need it?

When is such a detailed description of the configuration and all the mechanisms of the future system needed? As a rule, the creation of an LLD becomes a final stage of design work, followed by implementation and testing.

A well-written LLD noticeably speeds up and simplifies the process of launching any IT system. With a detailed description, specialists clearly see the project's requirements and understand what they need to do. Often, if there is no such description, the launch and operation of the infrastructure are complicated by various incidents.

As in the case of HLD, there is no clear set of rules regarding the document's structure - it is prescribed for a specific project. But there is an approximate LLD algorithm that most developers use:

• description of schemes for placement and connection of equipment;
• description of methods for installing software modules;
• detailing the operating modes of individual components of the system.

As an example, take a look at this low-level design. Here we see the design of registration, login, and payment. These points are part of the high-level design, but here they are specified.

Why Not Go Straight to an LLD?

The low-level design takes really great design effort and typically involves a much wider audience of technical staff (developers, testers, DevOps engineers).

Is it necessary to dedicate so much effort before the general plan is not approved? We think you know the answer. The project's scope has not yet been signed off, and the stakeholders have not yet said how much they like your ideas.

The HLD describes the big picture, while the LLD focuses on details in the technical and implementation sphere.

One more time: what's the difference?

We'll go through the biggest differences step by step.

• High-level design is the overall system design. It shows us the general design when low-level design — is a detail-level process.
• High-level design's abbreviation HLD, low-level design's — LLD.
• High-level means macro-rank, while low-level — micro one. HLD overall description/architecture of the application. It is a detailed description of each and every module.
• High-level design doesn't mean deep-diving into exact details of the functional logic of the module, while low-level one does. Instead, it expresses the brief functionality of each module. 
• HLD is solution architect work when its low-level brother is done by designers and developers.
• High-level design collects the design team, review team, and client team. Low-level design participants bring together the design team, operation team, and coders.
• The first thing created is high-level design. Only after this step is low-level design done.

Don't mess up

There are also similar terms like high-level language and low-level language that can confuse you. Let's figure it out.

A high-level language is much easier to understand as it's user-oriented. It has been done to make it upfront for a developer to transform an algorithm into program code.

A low-level language is better understood by machines. Low-level programs are expressed in the machine operations that carry out a task. 

Why is a high-level language used in program development?

To be short, this way, the coder can focus on programming the logic of the application instead of wasting time on the detailed implementation of each and every high-level language function for every little task that is required.

Ok, let's sum up

Congrats! Now you understand the great difference between high-level and low-level designs.

If you are asked about it, you'll say that the high-level design specifies the complete landscape of the particular software product or application. On the other hand, the low-level design specifies each module and makes the in-detail report.

The members of the design team, client team, and review teams take part in the high-level designing during Software Development Life Cycle's design phase. At this time, the design team and operation teams works on the low-level design.

Each design level is a key to turning ideas into tech solutions and creating qualitative products. 

Great! The long-read is almost over

You are one step forward in becoming real tech experts. Remember your dev-buddies from CGS-team are always ready to help not only to understand but to implement such it-staff. 

If you're thinking about creating cool tech projects, you know where you can find high-level software programmers.

CGS-team — are real fans of their work, who stand for qualitative results and realizing client's goals. Some facts about us:

• We don't like bureaucracy and paperwork. Instead, we appreciate quality and friends-like communication.
  
• Each member of the team takes responsibility for the work done. That's why it's always on time and well-done.