Designing the System Structure and Data Model
Problem Context
While interaction design defines how users engage with a system, the underlying structure determines whether those interactions can be effectively supported. In a community platform where users share work and request feedback, the system must be able to organise and connect information in a meaningful way.
Without a clear structure, feedback can become disconnected from its context, making it difficult to interpret and use.
System Overview
The system is organised around three core elements:
- Users (participants)
- Posts (shared content with a goal)
- Feedback (structured responses)
These elements form the foundation of interaction within the community, and their relationships enable users to share work and receive relevant responses.
Data Structure
Users
Each participant is represented by a minimal identity, allowing the system to associate activity without requiring complex user management.
- user_id
- username
Users can both create posts and provide feedback, reflecting the flexible roles within a community environment.
Posts
A post represents a piece of shared content along with a defined feedback goal.
- post_id
- user_id (author)
- title
- description
- feedback_goal
The feedback goal is essential, as it provides the context needed for interpreting responses.
Feedback
Feedback is structured and linked to both a post and a user.
- feedback_id
- post_id
- user_id (reviewer)
- clarity
- confusion
- suggestion
By separating feedback into predefined fields, the system supports more focused and interpretable responses.
System Relationships
The system follows a simple relational structure:
- One user can create multiple posts
- One post can receive multiple feedback entries
- Each feedback entry is associated with one post and one user
This structure allows the system to retrieve and present feedback in a way that preserves context and supports comparison across responses.
Design Decisions
The decision to structure feedback into specific categories (clarity, confusion, suggestion) directly supports the goal of improving relevance and actionability.
Instead of storing feedback as a single block of text, this model enables the system to organise responses by type, making it easier for users to identify patterns and prioritise improvements.
The model also relies only on minimal user information required to associate posts and feedback, avoiding unnecessary complexity and reducing unnecessary data handling.
Alternative Approaches
An alternative would be to store feedback as unstructured text. While this simplifies the system, it makes it more difficult to organise and interpret responses.
Another approach would involve a more complex schema, such as additional feedback categories or scoring systems. While this could provide deeper analysis, it would increase both implementation complexity and user effort.
The chosen approach prioritises simplicity while still supporting structured interaction.
Trade-offs
The simplified data model is easy to implement and understand, but it limits flexibility. Users must respond within predefined categories, which may not capture all types of feedback.
Additionally, requiring structured input introduces more effort compared to free-form comments, which may reduce participation.
However, these trade-offs are acceptable, as the system prioritises clarity, relevance, and interpretability over unrestricted input.
Conclusion
A simple and well-defined system structure is essential for supporting structured, goal-oriented feedback in a community platform. By organising posts and feedback around clear relationships and minimal data requirements, the system enables consistent, contextual, and actionable interaction.