What I Learned from My First System Design Project

Introduction

Hi, I’m Adjoa — an engineer at Tokyo ICT.

Recently, I had the opportunity to take part in the system outline design phase for the first time in a large-scale project. In this post, I’d like to share what I learned from that experience.

If you’re curious about what engineers actually do in system development, I hope this gives you a clearer picture.

1. Project Overview

The project was about renewing a credit card business system. The requirements definition phase had already been completed when our company joined.

Our team took over during the outline design phase, and I was assigned as one of the design engineers.

2. What Is “Outline Design”?

In system development, the outline design phase is where you take the requirements defined earlier and translate them into a concrete system structure.

The main purpose of the outline design document is to make sure both the client and the development team share the same understanding of how the system will work — before moving on to detailed design and implementation.

Once the client approves the outline design document, the project proceeds to the next step: basic design.

3. What I Worked on in the Outline Design Document

In this project, each engineer was responsible for several functions. I was assigned five of them. My work mainly consisted of writing the outline design documents for those functions.

Here’s what they included:

(1) Function Overview

Since we created one document per function, I started each one by describing who uses it, when, in what context, and how.

(2) Screen Transition Diagrams

These diagrams show how users move from one screen to another — for example, which screen opens when a certain button is clicked.
I also listed the APIs, database tables, and external interfaces used in each transition.

(3) Business Rules

In this context, business rules define conditional behaviors — such as showing or hiding buttons depending on user type. For instance: “Display the ‘Edit’ button for Gold members, but hide it for Standard members.” I identified all such conditions and made the branching logic as clear as possible.

(4) Screen Layouts and Field Descriptions

For each function, I created mock screen layouts and explained the purpose and data source of every field.
Example:

• Member Name: Displayed from Member Table.name
• Edit Button: Navigates to the “Edit Confirmation” screen

(Note: The items above were part of our project’s design template, but not necessarily required in every project.)

4. Challenges I Faced

At first, I thought my job was to “design exactly as written in the requirements.” So I confidently submitted my first design document — only to be hit by a wave of review feedback.

The main reason? Requirements documents don’t always consider long-term maintenance or implementation complexity. If you simply follow them word for word, you might end up with something too complicated or inefficient to maintain.

That’s when I realized: the real purpose of the outline design phase is to bridge the gap between requirements and reality — to make the system practical and sustainable.

I also received questions like:

“How exactly will this branching logic work?”
“How do you pass the data between screens?”

Each question forced me to pause and think.
“Maybe I need to use session IDs?”
“I should review how React handles this…”
“I really don’t know enough yet.”

It was humbling — and incredibly educational.

5. What I Focused On

Since I felt my technical knowledge was still limited, I decided that at least the quality of my documentation had to be top-notch.

Here are a few things I made sure to do:

• Ensured consistent terminology across the whole team
  (e.g., unified terms like “User” vs. “Member”)
• Kept diagrams perfectly aligned and evenly spaced — fixing them immediately rather than later
• Used our in-house AI tool to check for typos before each review
• Double-checked everything using the team’s official checklist

I repeated these checks even after finishing all five documents, to make sure everything met our quality standards.

6. What I Learned

Through this experience, I realized that design isn’t just about writing what’s in the requirements — it’s about thinking ahead to how the system will actually be implemented, operated, and maintained.

I also discovered that system design requires a surprisingly broad range of knowledge — from programming languages and databases to networks and security.

Most of all, I came to appreciate how deep and fascinating the “design” phase of software development really is.

If you’re considering joining Tokyo ICT as an intern or new engineer, I hope this story gives you a glimpse into what we do — and how much you can grow through real project experience.