Design Activities
Design activities focus on both the technical and visual aspects. Activities tackle either one or the other. These activities will help you figure out what you need to implement and how you will make your software available (deployment).
“Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs
Complete a Tutorial
Section titled “Complete a Tutorial”Gain hands-on experience and enhance your technical skills by completing a tutorial relevant to your project.
- Choose a Tutorial: Select an online tutorial that aligns with your project (e.g., database setup, API development, UI design, web framework).
- Work Through the Steps: Complete the tutorial, following the instructions and applying what you learn.
Write a summary of what you learned and how you will apply it to your project. Outline features, if any, that you learned about and how it will help with specific concerns or features.
Select a Database or Storage Technology
Section titled “Select a Database or Storage Technology”Choose the most suitable database or storage technology for your project based on data requirements, scalability, and use case.
- Assess Requirements: Analyze your project’s data structure, volume, and usage patterns.
- Compare Options: Explore relational (e.g., MySQL, PostgreSQL) vs. non-relational databases (e.g., MongoDB, Cassandra), as well as different ways to store data (offline, online, object stores, etc.).
- Scalability and Performance: Consider factors like read/write speeds, scalability, and how well the database or store handles your expected workload.
- Final Selection: Justify your choice based on how it aligns with the project’s goals.
Provide a report detailing the options considered, pros/cons, and rationale for your final database/storage selection.
Define your Database Schema
Section titled “Define your Database Schema”Design a structured database schema to organize and store your project’s data effectively.
- Identify Entities: List all the key entities (e.g., users, orders, products) relevant to your project.
- Define Relationships: Determine how entities relate to each other (e.g., one-to-many, many-to-many).
- Create Tables and Fields: Design the tables and define attributes (fields) for each entity.
- Normalize Data: Ensure your schema minimizes redundancy through normalization.
- Performance: Index key fields for faster querying and optimize design for scalability.
- Security Measures: Plan data encryption, define access controls, and ensure proper handling of sensitive data (e.g., user passwords).
Submit your database schema diagram with explanations of the relationships, key tables or objects, and fields. Explain how normalization was used, and which performance and security considerations you plan to implement. Optionally, submit a schema configuration file (e.g., SQL query to create the tables).
Evaluate Different Technologies
Section titled “Evaluate Different Technologies”Compare and assess multiple technologies (e.g., languages, frameworks, libraries, …) to choose the best fit for your project’s requirements.
- Identify Key Criteria: Define what you need from the technology (e.g., performance, scalability, ease of use, …).
- Research Options: Explore 2-3 technology solutions and their strengths/weaknesses.
- Compare Performance and Compatibility: Evaluate how well each technology integrates with your existing project and meets performance goals.
- Security and Support: Consider security features and available community support for each option.
Provide a comparison matrix and a justification for the chosen technology.
🔥 Describe your Architecture
Section titled “🔥 Describe your Architecture”Clearly define the overall system architecture of your project, focusing on key components and how they interact.
- Identify Core Components: List and describe major components (e.g., frontend, backend, database, external APIs, functions, data sources, …).
- Define Interactions: Explain how components communicate (e.g., API calls, data flows).
- Consider Scalability: Discuss how the architecture handles future growth.
- Security and Performance: Identify security measures and performance optimization techniques integrated into the architecture.
Submit a diagram of the architecture and a brief explanation of each component and its role in the system.
C4 Model
Section titled “C4 Model”The C4 model is a way of visualizing the architecture of software systems. It’s not a rigid notation but a way to structure diagrams. The name C4 stands for its four core diagram types:
- Context (Level 1): The highest-level view, showing your system as a black box interacting with users and other systems. This diagram is perfect for business stakeholders and non-technical people.
- Containers (Level 2): This level zooms into the system, showing the major deployable units or services that make it up (e.g., web applications, APIs, databases, microservices). It shows how these containers communicate.
- Components (Level 3): Here, you zoom into an individual container to see the major components or modules inside it. This view is typically for developers to understand the internal structure of a service.
- Code (Level 4): The lowest level, which can be represented by UML diagrams (see below), entity-relationship diagrams (ERDs), or similar, showing the implementation details of a component. This level is often considered optional and can be generated by IDE tools.
Unified Modeling Language (UML) Diagrams
Section titled “Unified Modeling Language (UML) Diagrams”UML is a standardized, general-purpose modeling language in software engineering. While it includes many diagram types, a few are particularly useful for architecture:
- Component Diagram: Shows how components are wired together to form larger components or software systems. It’s good for illustrating the modular structure of a system.
- Deployment Diagram: Visualizes the physical deployment of the system, showing how software artifacts (like executables or libraries) are mapped to hardware nodes (like servers or devices).
- Package Diagram: Organizes elements of a system into groups (packages). It’s useful for showing dependencies between different parts of your codebase at a high level.
- Composite Structure Diagram: Shows the internal structure of a classifier (like a class or component) and the collaborations that this structure makes possible.
4+1 Architectural View Model
Section titled “4+1 Architectural View Model”The 4+1 Architectural View Model, developed by Philippe Kruchten, breaks down the system’s description into five concurrent views, each addressing the concerns of different stakeholders.
- Logical View: Focuses on the functionality for the end-user. UML diagrams like Class or State diagrams are often used here.
- Process View: Deals with the dynamic aspects of the system, explaining the system processes and how they communicate. It addresses concurrency and performance.
- Development View: Describes the system from a programmer’s perspective, focusing on software management. It uses Package diagrams to show the organization of modules.
- Physical View: Shows the system from a system engineer’s point of view, focusing on how the software is deployed on hardware. This corresponds to the UML Deployment diagram.
- Scenarios (+1 View): Consists of a few selected use cases or scenarios to illustrate the architecture. These scenarios help validate the design and serve as a consistency check.
Arc42 is a template-based approach for documenting and communicating software architecture. It provides a standardized structure for your documentation, ensuring all important aspects are covered without being overly prescriptive about the notation. It’s more of a framework for your diagrams and explanations than a specific diagramming technique itself. It often incorporates UML or other diagrams within its structure.
High-Fidelity Prototype
Section titled “High-Fidelity Prototype”Develop a high-fidelity prototype to visualize and refine the design of your project, ensuring alignment with user experience and technical requirements.
- Design User Flows: Create a detailed prototype showcasing key user interactions and functionality using tools like Figma or Adobe XD.
- Visual Consistency: Ensure the design adheres to UI/UX principles and branding guidelines.
- Gather Feedback: Share the prototype with stakeholders or users to refine the design based on feedback.
Check this fantastic blog post about a SoundCloud iOS redesign.
Submit the prototype link and a reflection on design choices and feedback incorporated.
Proof-of-Concept
Section titled “Proof-of-Concept”Build a small-scale prototype or demo to test the feasibility of a specific idea, technology, or approach within your project.
- Define Key Assumptions: Identify the core concept or functionality that needs validation.
- Develop the Prototype: Create a minimal version focusing on the critical feature or technology.
- Test Feasibility: Evaluate the proof-of-concept to ensure the technology or idea works as intended.
Submit the proof-of-concept and a brief report on its feasibility, challenges encountered, and potential next steps.
Test Plan
Section titled “Test Plan”Develop a comprehensive test plan to ensure your project’s functionality, performance, and reliability.
- Identify Test Objectives: Define what you need to test (e.g., functionality, usability).
- Create Test Cases: Develop detailed test scenarios for each feature.
- Determine Test Methods: Choose manual or automated testing.
- Set Success Criteria: Define what constitutes a pass/fail result.
Submit a test plan document outlining test cases, methods, and criteria.
Deployment Plan
Section titled “Deployment Plan”Software deployment is all the things that need to happen for a software system to be available for use.
Outline the steps needed to either:
- deploy your project to a production environment or app store,
- build your software and make it available for download.
That means:
- Identify Deployment Environment: Specify where your software will be deployed (e.g., cloud, server) or where artifacts will be stored.
- Create a Deployment Checklist: Include steps like configuration, testing, build, integration, uploads, release, and backups.
- Define Rollback Plan: Plan actions if deployment fails.
Submit a deployment plan detailing environment, steps, and rollback procedures.
Describe your API Reference
Section titled “Describe your API Reference”Develop a comprehensive API reference to document the functions, endpoints, and data structures of your project’s application programming interface (API).
- List API Endpoints: Document each endpoint, including URL paths and methods (GET, POST, etc.).
- Define Inputs/Outputs: Clearly specify the required parameters, data types, and response formats for each endpoint.
- Document Error Handling: Include examples of error messages and how to handle them.
Provide the complete API reference document and a sample request/response for each endpoint.
Apply the Privacy by Design (PbD) Guidelines
Section titled “Apply the Privacy by Design (PbD) Guidelines”Privacy by Design is a systems engineering approach developed by Ann Cavoukian, former Information & Privacy Commissioner of Ontario.
The seven foundational principles are:
- Proactive not reactive; preventive not remedial
- Privacy as the default setting
- Privacy embedded into Design
- Full functionality — positive-sum, not zero-sum
- End-to-end security — full lifecycle protection
- Visibility and transparency — keep it open
- Respect for user privacy — keep it user-centric
Read the principles in detail, then write a report that explains how your software implements each one, or what needs to be done to get there.
UI Design Guidelines
Section titled “UI Design Guidelines”Select an appropriate set of user interface guidelines and apply them. There are user interface guidelines published by free/open-source organizations, corporations, and even government. Here are some examples:
- Microsoft’s Fluent 2 Design System
- Google’s Material 3 Design System
- Adobe’s Spectrum Design System
- Firefox’s Acorn Design System
- Atlassian’s Design Language
- KDE Human Interface Guidelines
- GNOME Human Interface Guidelines
- Apple Human Interface Guidelines
- Digital.gov’s Usability
Feel free to come up with another design system or your own exhaustive one.
Submit your updated UI wireframes or a demo of your updated software with a summary of what changed and why.
Apply the GenderMag Method
Section titled “Apply the GenderMag Method”The GenderMag Method enables software practitioners (e.g., developers, managers, UX professionals) to find gender-inclusivity “bugs” in their software, and then fix the bugs they find.
Apply the method and write a summary of your findings and what you will change in your software.
Peer Technical Design Review
Section titled “Peer Technical Design Review”In this activity, find two other teams to run a technical design review, either on Zoom or in person.
Your team will receive reviews from two other teams and will review these two teams.
As the reviewing team, your job is to think critically about the other team’s design:
- Does the design report address the questions below?
- Is the design fit for purpose? Does it meet the specification?
- Is the design fit for the future? Can it grow modularly?
- Does the code implement the design? (look at the code!)
- Is the design solving the right problem?
- Are there design alternatives that should be considered?
- Are there coding issues that should be addressed?
Submit your report (see below) and your consolidated reviews (from each member of the team). Share your review with the corresponding team. This activity can either be individual (one person from each team) or team (everyone on the team reviews both other teams).
Your report should be a one page diagram and one page of text covering the following three issues:
Explanation of the Design
Section titled “Explanation of the Design”This exercise is focused on the internal design and architecture of the software — not the user experience.
- What are the components?
- What libraries and tools are used?
- How are they arranged?
- Any noteworthy uses of architectural styles or design patterns?
- etc.
Fitness for Purpose
Section titled “Fitness for Purpose”A rationale for why this design meets the requirements/specification.
- Why is this design better than reasonable alternatives?
- If the project is in a known domain with a known solution strategy, is it following normal design conventions?
- If the project is in a novel domain or has a novel solution strategy, why is the proposed design a good match?
Fitness for Future
Section titled “Fitness for Future”- What are the anticipated kinds of change, growth, or variability in the domain?
- Does the design facilitate managing that change in a modular fashion?
- What are core assumptions that cannot be changed?
Read a Book on Approaches to Software Design
Section titled “Read a Book on Approaches to Software Design”Take a look at a book about software design, and discuss in the context of your project. One good approach is that each team member skims several chapters, so that collectively you have examined the entire book. The books listed here are a starting point; you might find other interesting books worth reading.
Submit a write-up of what you learned and how you will apply it to your project.
- Clean Architecture by Robert C. Martin
- Release It!: Design and Deploy Production-Ready Software by Michael T. Nygard
- A Philosophy of Software Design by John Ousterhout
- Software Design Decoded: 66 Ways Experts Think by Marian Petre and André van der Hoek
- Software Designers in Action: A Human-Centric Look at Design Work by Marian Petre and André van der Hoek
- Designing Secure Software: A Guide for Developers by Loren Kohnfelder
Create Good Survey or Interview Questions
Section titled “Create Good Survey or Interview Questions”If you are collecting data through surveys or interviews, it’s very important to have clear, unbiased, valuable, and not leading questions, i.e., good questions. You’ll also have to consider what type of data (qualitative, quantitative) you’re collecting, their purpose, and how you are going to analyze the answers.
For this activity, explain what medium you will use to collect the answers, write your survey or interview questions, the expected types of answers for each, and how you will use them for analysis and answering your research question(s).
Planning for Maintenance and Long-Term Support
Section titled “Planning for Maintenance and Long-Term Support”Identify key factors for maintaining and supporting the system post-deployment to ensure long-term sustainability.
Instructions:
- Define Maintenance Tasks: List regular maintenance tasks (e.g., backups, updates, bug fixes).
- Plan for Scalability: Outline strategies for scaling the system as usage grows.
- Support Structure: Identify the team or resources responsible for providing user support and resolving issues.
- Create Documentation: Develop a plan for user manuals, FAQs, and support guides.
Provide a detailed plan addressing maintenance, scalability, and user support.
Optimizing System Performance
Section titled “Optimizing System Performance”Identify and address factors that influence system performance to ensure optimal operation under different loads.
- Define Performance Metrics: Identify key metrics like response time, throughput, and latency.
- Plan for Load Handling: Evaluate how the system will handle different levels of traffic (e.g., stress testing, load balancing).
- Optimize Code and Queries: Identify areas for improving efficiency (e.g., database indexing, caching).
- Monitoring and Scaling: Plan for performance monitoring tools and strategies for scaling.
Provide a performance plan with identified bottlenecks and optimization strategies.
Designing for System Security
Section titled “Designing for System Security”Ensure the system is designed with robust security measures to protect data and user privacy.
- Identify Vulnerabilities: List potential security risks (e.g., data breaches, unauthorized access).
- Implement Best Practices: Plan for security measures such as encryption, authentication, and role-based access control.
- Secure Data: Outline how sensitive data will be protected both in transit and at rest.
- Compliance and Monitoring: Ensure the system meets security standards (e.g., GDPR, HIPAA) and establish regular monitoring for threats.
Submit a security plan that details risks, countermeasures, and compliance strategies.
MDA Framework
Section titled “MDA Framework”Use the MDA (Mechanics, Dynamics, Aesthetics) framework to analyze and structure your game before development begins. This activity helps your team clarify the intended player experience, define core mechanics, and anticipate how game dynamics will emerge. Complete this activity to align on design goals and make informed decisions early in the process. You can split different parts of the MDA framework among team members.
Fun Hypotheses
Section titled “Fun Hypotheses”Identify and articulate your team’s hypotheses about what will make your game fun and engaging. This activity helps you focus design efforts on the elements most likely to delight players and provides a basis for testing and iteration throughout development.
Core Loop Analysis
Section titled “Core Loop Analysis”Identify and refine the fundamental repeatable actions that drive engagement and progression in your game. This activity helps you ensure your game provides meaningful and satisfying interactions. Use core loop analysis to iterate on your design and improve player retention and enjoyment.
Player Journey
Section titled “Player Journey”Map out the player’s journey from the First Time User Experience (FTUE) through the mid-game. This activity helps your team visualize onboarding, learning curves, and progression, ensuring that players are supported and engaged as they move deeper into the game. Use this to identify potential drop-off points and opportunities to enhance player satisfaction.