Design Activities

Design activities cover the technical and the visual side of your project, one or the other per activity. They help you figure out what to implement and how you’ll make your software available (deployment).

The technical design activities on this page are direct preparation for writing an RFC: architecture descriptions, technology evaluations, and design reviews are exactly the reasoning an RFC asks you to write down and defend.

“Design is not just what it looks like and feels like. Design is how it works.” (Steve Jobs)

Technical Design guideC4, UML, 4+1, and arc42 explained, plus what a design document is for. Read it before Describe your Architecture.

Complete a Tutorial

Individual Activity

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’ll apply it to your project. Outline features, if any, that you learned about and how it will help with specific concerns or features.

A good output is a summary of what you learned and the specific features or concerns in your project it applies to.

Select a Database or Storage Technology

Individual Activity

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.

A good output details the options considered, pros/cons, and the rationale for your final database/storage selection.

Define your Database Schema

Individual Activity

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).

A good output is 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. A schema configuration file (e.g., SQL query to create the tables) is a plus.

Evaluate Different Technologies

Individual Activity Recommended

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.

A good output is a comparison matrix and a justification for the chosen technology; this maps directly onto the alternatives section of an RFC.

Describe your Architecture

Individual Activity Team Activity Recommended

Draw the system your team is about to build, at the level of zoom your project partner can follow, and write one paragraph per box. One to two hours as a team, once at the start, then updated when the architecture changes.

Pick a notation: a C4 context plus container diagram fits most projects; use 4+1 views only if your readers have distinct concerns. The Technical Design guide explains the options.
Identify core components: list the major pieces (frontend, backend, database, external APIs, pipeline stages, data sources, firmware modules).
Define interactions: show how components communicate (API calls, queues, file formats, data flows) and name the protocol on each edge.
Mark the risky parts: which component is new to the team, which integration is unproven, and what you’ll spike first.
State scalability, security, and performance assumptions: one line each, or “not a concern for this project” with the reason.

Optionally, run this a second time with an AI agent and set the two outputs side by side, noting where they differ, because the comparison shows what the tool changed; either version can be the one you keep.

Keep the diagram in your repository docs; it anchors the design section of an RFC.

A good output is a diagram of the architecture and a brief explanation of each component and its role in the system.

High-Fidelity Prototype

Individual Activity

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 Penpot (open source, free).
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.

Read this blog post about a SoundCloud iOS redesign.

A good output is the prototype link and a reflection on design choices and feedback incorporated.

Proof-of-Concept

Individual Activity Recommended

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.

A good output is the proof-of-concept itself and a brief write-up on its feasibility, challenges encountered, and potential next steps.

Test Plan

Individual Activity Team Activity Workshop

Write a test plan for the paths that must work before anyone relies on the project, not for every feature. About an hour and a half as a team.

Identify Test Objectives: List the paths that must work (signing in, saving data, a payment, or the pipeline that produces your reported numbers) and what you need to test on each (e.g., functionality, usability).
Create Test Cases: Write the test scenarios for each of those paths.
Determine Test Methods: Choose manual or automated testing.
Set Success Criteria: Define what constitutes a pass/fail result.

A good output is a test plan covering the paths that must work, with their test cases, methods, and pass criteria.

Deployment Plan

Individual Activity Recommended

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.

The DevOps guide covers the deployment checklist and rollbacks; the Shipping guide has the lead times your deployment path involves.

A good output is a deployment plan detailing environment, steps, and rollback procedures.

Describe your API Reference

Individual Activity Recommended

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.

A good output is the complete API reference document and a sample request/response for each endpoint, living alongside the code in your repository.

Apply the Privacy by Design (PbD) Guidelines

Individual Activity Recommended

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.

A good output is your project assessed against the seven principles, naming which already hold, which you’ll implement, and which don’t apply and why.

UI Design Guidelines

Individual Activity

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:

Feel free to come up with another design system or your own exhaustive one.

A good output is your updated UI wireframes or a demo of your updated software with a summary of what changed and why.

Apply the GenderMag Method

Individual Activity

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’ll change in your software.

A good output is a list of the inclusivity bugs you found and what you’ll change in the software because of them.

Peer Technical Design Review

Team Activity Workshop

Put your technical design in front of another team and review theirs in return, in one sitting; the presentations guide covers what a design review is for. About 75 minutes for two or three teams in one room or on one call.

Draw your design on one page: 20 minutes, starting from your design document if you have one. The components, how they connect, what they are built with, and the one design decision your team is least sure of. Cover the three issues below at the depth one page allows.
Present: 5 minutes per team. Walk the others through your page. Answer their questions; don’t defend the design yet.
Review: 20 minutes, every team at once. Work through the questions below on the other team’s page, or with three teams on the next team’s page, write each finding in one sentence, and hand the findings over.
Decide: 20 minutes. Mark each finding you received accepted or declined, with a one-line reason, and name the change you will make first.

As a reviewer, question the other team’s design:

Is the design fit for purpose? Does it do what the project needs?
Is the design fit for the future? Can it grow modularly?
Is the design solving the right problem?
What alternatives should the team consider, and would one of them make the least-sure decision easier?
What would you change first?

Giving and receiving this kind of review is rehearsal for a formal RFC review round.

Your one-page design covers these three issues:

Explanation of the Design

This exercise covers 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

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

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?

A good output is your one-page design, the findings the other team gave you, and each finding marked accepted or declined with a reason.

Read a Book on Approaches to Software Design

Individual Activity Team Activity

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’ve examined the entire book. The books listed here are a starting point; you might find other interesting books worth reading.

Write up what you learned and how you’ll 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

A good output is a written summary of what the team learned and the specific design decisions in your project it will change.

Create Good Survey or Interview Questions

Individual Activity

If you’re collecting data through surveys or interviews, write clear, unbiased, non-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’re going to analyze the answers.

For this activity, explain what medium you’ll use to collect the answers, write your survey or interview questions, the expected types of answers for each, and how you’ll use them for analysis and answering your research question(s).

A good output is your question set, with the data type and purpose of each question, and a note on how you removed leading or biased phrasing.

Planning for Maintenance and Long-Term Support

Individual Activity Recommended

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.

A good output is a detailed plan addressing maintenance, scalability, and user support; it becomes raw material for the handoff package you leave the next maintainer.

Optimizing System Performance

Individual Activity

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.

A good output is a performance plan with identified bottlenecks and optimization strategies.

Designing for System Security

Individual Activity

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.

A good output is a security plan that details risks, countermeasures, and compliance strategies.

Designing for Accessibility

Team Activity Recommended

Review one screen or output of your system against accessibility basics before it’s built, while a fix is a design change rather than a rebuild.

Contrast and color: text meets WCAG 2.2 AA contrast ratios, and no information is carried by color alone (a red border meaning “error” is invisible to some users; a red border plus the word “error” isn’t).
Target size and spacing: interactive elements are large enough and far enough apart to hit reliably, including on a phone and for users with motor impairments.
Focus states: every interactive element shows clearly when it has keyboard focus, and the tab order follows the visual order.
Semantics before ARIA: a real <button> is accessible by default; a <div> with a click handler and four ARIA attributes usually isn’t. Reach for the correct element first.
Labels: every input has a programmatically associated label, not just placeholder text.

Then check your work with the manual accessibility pass: keyboard only, screen reader, 200% zoom. To automate the mechanical parts, see Wire an Accessibility Audit Into CI.

If your project has no user interface, the equivalent targets are your error messages, output formats, and documentation.

A good output is a marked-up screenshot or a short list of specific fixes, each tied to the guideline it addresses.

Reproduce Your Baseline

Team Activity Recommended

Get the number you intend to beat running on your own machine, before you try to beat it. Budget about a week of calendar time.

Pick the specific published result: paper, table, row, number.
Get the authors’ code running if it exists. Expect broken dependencies, missing data, and undocumented preprocessing.
Run it on the data it was published on, and compare your number to theirs.
Write down the gap and why it exists: different hardware, a different data version, a preprocessing step the paper never mentioned, or a genuine failure to reproduce.
If you can’t reproduce it, say so explicitly and choose a baseline you can, since you can’t claim to beat a number you couldn’t reproduce.

A good output is your reproduced number next to the published one, with a written explanation of any gap, committed to the repository.

Make Your Artifact Reproducible

Team Activity Recommended

Get your project to the state where a stranger runs one command and gets your numbers. Half a day.

Pin your dependencies: a lock file or a container image, not a list of package names.
Version or precisely reference your data, including which split and which preprocessing.
Seed every run, and record the seeds.
Write the one command that goes from clean checkout to result table, and put it in the README.
Test it literally: have a teammate who didn’t build it, or your partner’s graduate student, run it fresh on a different machine and check that the numbers match.

A good output is a repository tag plus a README command that a teammate ran on a different machine and got your result table from.

MDA Framework

Individual Activity Team Activity

For game projects. Write down the intended player experience, the mechanics that produce it, and the dynamics you expect to emerge, using the MDA (Mechanics, Dynamics, Aesthetics) framework, before development begins. Doing it early is what lets the team argue about design goals instead of about code. Split the three parts among team members.

A good output is your mechanics, dynamics, and aesthetics written out, with the intended player experience stated first and the mechanics justified against it.

Fun Hypotheses

Individual Activity Team Activity

For game projects. Write down your team’s hypotheses about what will make the game fun, each as a claim a playtest can confirm or refute. They’re what you test first and what you cut when a playtest says otherwise.

A good output is a written list of your fun hypotheses, each with how you plan to test it in playtesting.

Core Loop Analysis

Individual Activity Team Activity

For game projects. Name the repeatable actions that drive engagement and progression, the core loop, and check that each step gives the player a meaningful action and a reward. A loop that reads flat on paper plays flat, so fix it here before building content around it.

A good output is a description of the core loop naming each step’s player action and reward, plus what you changed after analyzing it.

Player Journey

Individual Activity Team Activity

For game projects. Map the player’s journey from the First Time User Experience (FTUE) through the mid-game: onboarding, learning curve, progression. The map exists to find the points where players drop off and to propose a fix for each before a playtest confirms it.

A good output is a mapped journey from first-time experience through mid-game, with likely drop-off points marked and one fix proposed for each.