You can easily plan your backoffice by utilizing your service's data structure and relationships. While data structures may appear complex, you can intuitively grasp it once you identify certain patterns.
In this article, This article presents examples and planning scenarios to help you understand data structures and relationships without development knowledge.
Databases and Data Relationships
If you operate a web service or app, you're storing your service's data somewhere. Relational database servers are typically used for data storage.
Data is stored in a tabular structure, as shown in the example above. In databases, these are called "tables". One of the main characteristics of relational databases is that they handle data by defining table structures and establishing relationships between tables.
When you plan your backoffice with this in mind, you can easily complete the planning by directly reflecting the data structure in your backoffice.
Household Goods Sales Service
Let's use an example of a service selling household items like shampoo, soap, and toothbrushes. What customer requests would need to be handled in this service's backoffice?
They would likely involve purchased household items, like "I want to cancel yesterday's payment" or "I want to reorder the soap I ordered today - is it still in stock?" Therefore, the backoffice needs to be able to check order information, product inventory, order volumes, and respond to customers.
In this situation, the data structures we need to understand are customer information and detailed records of household goods purchases. Let's examine how this data might be organized.
Understanding Data Division
Just as we use multiple sheets and lookup functions in spreadsheets when data becomes complex, databases also separate data for efficient storage.
For example, if customer Kim Hops orders 1 shampoo and 2 soaps on January 1, 2024, instead of storing it like a receipt, the data is normalized as follows:
- Customer Information: Customer's name is Kim Hops. This customer is Customer No. 1.
- Product Information: Products include shampoo and soap, with 10 units each in stock. Shampoo is Product No. 2, and soap is No. 3.
- Order Information: Customer No. 1 ordered 1 unit of Product No. 2 and 2 units of Product No. 3 on January 1, 2024.
While the data division method might seem complex, understanding just three keywords - customer information, household goods information, and order information - is sufficient.
Finding Data Relationships
When defining relationships between data stored in tables, they're categorized as one-to-one, one-to-many, or many-to-many relationships. However, these technical terms can be challenging. For backoffice planning, it's sufficient to understand whether one piece of reference data can be connected to multiple other pieces of data.
Customers and Orders: In our service, one customer can place multiple orders. Due to this relationship between customers and orders, we create a customer detail page and display order history in a table format. In the backoffice, we can structure this with a form showing detailed information connected to one piece of data, and tables showing multiple pieces of data.
Orders and Products: Multiple products can be ordered simultaneously in one order. If stock is available, products like soap can be ordered multiple times. Products are displayed in table format on the order detail page.
Products can also be shown in table format on the product detail page. However, order history for items like soap might be too extensive for table display. Usually, for time-related data like orders, we create UIs that show trends, such as visualizing daily order volumes or comparing order volumes against the previous month.
Customers and Products: Customers and products are connected through orders. In such relationships, instead of directly handling product data on the customer detail page, we create UIs that show trends like purchase quantities and product preferences.
Conclusion
We've introduced methods for identifying data structures and relationships using a household goods sales service example. In Part 2, we'll explore how to plan a backoffice based on this foundation.
If you're planning a backoffice and wondering about data structures, feel free to contact me.
From information architecture to screen layout, we'd love to discuss any admin-related concerns you have.
Please schedule a time through this link.