In this lesson, you'll learn how to identify user needs using user-centered design principles, which put the user at the center of everything. You'll also plan your database schema, assign team roles, discuss ethical considerations, and create an initial plan document.

This lesson is designed to build your skills in creating an effective interactive information system. It should take about 120-180 minutes over several sessions, allowing you time to think deeply and collaborate with your team.

Work with your team to assign roles for this planning phase. This builds on the team formation from the overview lesson.

Roles could include:

• Researcher (gathers user needs)
• Designer (sketches schema)
• Ethicist (leads discussions)
• Documenter (compiles the plan)

Discuss strengths: If someone excelled in the Databases unit, assign them schema planning.

User-centered design focuses on putting the user at the heart of the development process. This means identifying who your users are, what problems they face, and how your system can solve them effectively.

Key principles include:

• empathy (understanding user perspectives)
• iteration (refining based on feedback)
• usability (making the system intuitive)

For example, in your interactive system, consider users like students needing to search a library database – design for ease of use, not just functionality.

The user-centered design process is a cycle that includes the following stages:

1. Research Users (gathering information about who your users are and their behaviours)
2. Define Needs (analysing the research to pinpoint specific user requirements)
3. Ideate Solutions (brainstorming creative ideas to address those needs)
4. Prototype (building simple models of your ideas)
5. Test (evaluating the prototypes with users and gathering feedback)

You can use this cycle in your project by starting with user research, moving through each stage, and then looping back to research or any other stage as needed to refine your design. Abstraction comes in here by simplifying complex user data into manageable models during the definition and ideation stages.

Now, let's define the needs for your interactive information system. This step is crucial for abstraction – you're representing real-world data in a simplified way. By focusing on what users truly require, you'll ensure your database is efficient and relevant, avoiding unnecessary complexity.

1. List your users (e.g., students, teachers, or administrators) and their goals (e.g., students might want to add or view grades, while teachers could need to update records or generate reports). Think about different user groups and what they aim to achieve with the system.
2. Identify requirements: Functional (e.g., the ability to search data, add new entries, or generate summaries) and non-functional (e.g., the system should load quickly, be secure, or work on mobile devices). Consider how these requirements impact the data you'll store.
3. Use abstraction to categorise data – think of entities like 'User' or 'Item' and their attributes (e.g., a 'User' entity might have attributes such as Name, Email, and Role). This simplifies real-world information into structured categories, focusing only on essential details.

For instance, if building a library system, a student user might need to search for books by title or author, so you'd abstract book data into attributes like Title, Author, ISBN, and Availability.

Here is an example table for a library system :

With user needs defined, it's time to plan your database schema. A database schema is like a blueprint for how your data will be structured and organised. This step involves abstraction: you're modelling real-world data into simplified tables, fields, and relationships, focusing only on the essential details to make your system efficient and effective.

Planning the schema helps ensure that your interactive information system can store, retrieve, and manage data in a way that meets user needs without unnecessary complexity. Let's break it down step by step.

1. Identify entities: Entities are the main objects or concepts in your system, such as 'Books', 'Users', or 'Loans' in a library example. For each entity, list its attributes – these are the specific pieces of data, like Title and Author for a Book. Think about what data is truly needed based on the user requirements you defined earlier.
2. Define attributes and keys: Each attribute should have a data type (e.g., Text for names, Integer for IDs, Date for deadlines). Assign a primary key to each entity – this is a unique identifier, like an ID field, to distinguish each record. You may also need foreign keys, which link to primary keys in other tables to show relationships.
3. Define relationships: Relationships show how entities connect. Common types include:
   • One-to-one: Each record in one table links to exactly one in another (e.g., a user has one profile).
   • One-to-many: One record links to multiple others (e.g., one user can have many loans).
   • Many-to-many: Multiple records link to multiple others (e.g., students enrolled in multiple courses, requiring a junction table to manage the links).
4. Sketch an Entity-Relationship Diagram (ERD): This is a visual map using boxes for entities (with attributes listed inside), relationships, and lines to connect them. If you can't draw it digitally, use paper – the goal is to visualise how data flows and connects.

Here's an example schema for a simple school library system. We'll represent it textually using tables for clarity. Imagine this as a basic ERD: entities as tables, with relationships described below.

Example Entity: Books

Example Entity: Users

Example Entity: Loans (Junction Table for Many-to-Many Relationship)

Relationships in this ERD Example:

• One-to-Many: One User can have many Loans (via UserID foreign key in Loans).
• One-to-Many: One Book can be involved in many Loans (via BookID foreign key in Loans).
• This setup abstracts real-world borrowing into structured data, allowing queries like 'Which books is this student borrowing?'