1 of 31

Oasis Accelerator Series

BS1 - Technical Design Docs

2 of 31

Agenda

Team assignments 👥.

What is a design doc?.

When should I write one?.

How to write a design doc.

3 of 31

Team Assignments 👥

4 of 31

.

NUHire

Project Lead

Aarav Raina

Developers

Abhinav Gonthina

Prajwala Immareddy

Dylan Chen

Satvik Singh

Henry Abrahamsen

​

Gahan Patel

Aryan Gupta

Shiven Ajwaliya

Audrey Ng

Shlok Patel

5 of 31

.

Lost & Hound

Project Lead

Paarth Trehan

Developers

Ryan Sinha

Benjamin Hailu

Liam Pulsifer

Nahom Hailemelekot

Shamar Aitcheson

​

​

​

​

​

​

​

​

Naman Patel

Dreshta Boghra

Abhinav Tavildar

Derek Akalin

Shray Mulle

6 of 31

.

Rate My Husky

Project Lead

Malcolm Tavaria

​

Angela You

Isabella He

Aarav Gandbhir

Callum Johnson

Abrahim Elnaggar

Developers

Benjamin Lee

Cory Pierson

Nicholas Vocatura

Rayan Rane

7 of 31

.

Backyard

Project Lead

Manan Gangwani

Developers

Connor Friedman

Milo Bell

Ryan Sinha

Ryan Marshall

Benjamin Hailu

​

​

Seifer Mathias

Yash Maheshwari

Andy Nguyen

Zahi Ladkhan

​

8 of 31

.

Join Linear!

9 of 31

What is a design doc?

10 of 31

.

A design doc…

  • Has a written overview of an engineering solution or feature
  • Explains the what, how, and why behind the approach
  • Is shared with the team to get feedback

11 of 31

When should I write one?

12 of 31

.

You should write a design doc when…

  • Building something complex
  • Multiple approaches exist
  • The work affects other teams
  • There’s a high cost of getting it wrong

13 of 31

How to write a design doc

14 of 31

.

Metadata & Header

  • Title: clear, descriptive name for the proposal
  • One-sentence overview
  • Authors: owner(s) of the design doc
  • Reviewers: people you’re requesting feedback from
  • Status (e.g. Draft, In Review, Approved)

15 of 31

.

Metadata & Header

  • Title: Live Dining Hall Wait Times
  • One-sentence overview: Show students real-time wait times for NEU dining halls.
  • Authors: John Doe
  • Reviewers: Jane Doe
  • Status: In Review

Example

16 of 31

.

Overview

  • What problem are you solving?
  • Why does it matter?
  • Background context that might be needed to understand the problem

17 of 31

.

Overview

Students waste time walking to Steast/IV only to find long lines at peak hours. Between classes, students have tight windows, so long lines = skipping meals or being late.

​

The dining website currently shows dining hall hours and menus, but nothing about how busy they are at a certain time.

Example

18 of 31

.

Goals & Non-goals

Goals

  • What the proposal will achieve

Non-goals

  • What the proposal will not address to prevent going out-of-scope

19 of 31

.

Goals & Non-goals

Goals

  • Show a live busyness level (Low/Medium/High) for each dining hall
  • Help students pick a less crowded option nearby

Non-goals

  • Predicting future wait times
  • Covering non-dining-hall spots (Starbucks, food trucks, etc.)

Example

20 of 31

.

Proposal

  • Describe your solution and how it works
  • Include diagrams or flows where helpful

21 of 31

.

Proposal

Add a "Wait Times" section to the dining page. Each hall shows a color-coded status (Low, Medium, High) based on swipe-in data from the Husky card readers. The status refreshes every few minutes so students can check before walking over.

Example

22 of 31

.

Alternatives considered

  • Other design options you considered
  • Why you went for this design as opposed to others
  • Pros/cons

23 of 31

.

Alternatives considered

Manual student check-ins

  • Pros: Easy, quick to implement
  • Cons: Unreliable, easy to produce inaccurate data

​

Camera-based headcounts

  • Pros: Could be more accurate, extensible to other buildings
  • Cons: Privacy concerns, expensive to install

Example

24 of 31

.

Milestones & Rollout plan

  • Break down of execution
  • Expected delivery phases

25 of 31

.

Milestones & Rollout plan

Milestone 1

  • Pull swipe-in data from card reader system

​

Milestone 2

  • Build wait-time display in the app

​

Milestone 3

  • Pilot with Steast, then expand to all dining halls

Example

26 of 31

.

Concerns & Risks

  • Call out what could go wrong or where you're unsure
  • Known trade-offs and how you'd address them

27 of 31

.

Concerns & Risks

  • Swipe data may lag behind actual crowd size → refresh frequently and label as an estimate
  • Students leaving isn't tracked by swipes → use average meal duration to estimate current count

Example

28 of 31

Questions?

29 of 31

Project Leads, please now create and assign a ticket that involves making a design doc for a new feature.

Let’s put this into practice 🚀

30 of 31

.

Template

  1. Visit this link: https://tinyurl.com/linear-documents
  2. Click under YOUR project to find the design doc template
  3. At the top, click on the three dots and duplicate it

​

Please do this every time you make a new design doc!

31 of 31

Build time 🛠️