IS211 Requirements, Personas, and Scenarios
Observation and Insights from Urban Planning
The Design Thinking process transitions from the Empathy phase (observing, engaging, and immersing) to the Define phase.
The Define phase synthesizes empathy findings to
1. extract core insights
2. generating key artifacts such as personas and scenarios
3. Establish a clear Point of View (POV)
e.g. Urban planning observations from the Old City of Boston (adjacent to Faniel Hall) illustrate how user behavior informs environmental design:
Ancient market buildings were transformed into an urban marketplace.
Features highly specialized shops covering various food types.
Characterized by high crowd density, informal seating behaviors (notably on steps), and energy-efficient operations.
Structures feature garage-type windows that roll back during favorable weather, opening public spaces to the outdoors.
Patrons eat outdoors consistently, even in freezing weather conditions.
Contrasts directly with self-contained megastructures by fully integrating downtown streets directly through the market space.
Key urban planning insight: Informal physical features such as steps and elevated edges solve the problem of underutilized public areas by providing natural congregation points.
Smart Planning and Point of View: HDB Case Study
Data collection from empathy and observation enables the definition of an actionable Point of View (POV). (what that mean? whats a POV? It just means the direction you will take your project that aligns with the user’s needs after you’ve done data collection)
The Housing & Development Board (HDB) framework incorporates smart design across four primary areas:
Smart Planning
Smart Environment
Smart Estate Services
Smart Living
Smart Planning Methodologies:
Data aggregation involves compiling comprehensive structural data regarding town layouts, building dimensions, road networks, parks, energy usage, and waste generation.
Data is modeled to construct a three-dimensional digital map of Singapore.
Computer fluid dynamics simulate tropical wind flows through urban sectors (addressing tropical climate needs, distinct from temperate climates like Chicago).
Simulation color coding map:
Yellow and Orange: High-velocity, optimal wind flow.
Blue: Low-velocity, stagnant air movement.
Application in Pongo Ecotown: Initial wind simulations prompted realignments of building placements and park relocations, increasing orange and red zones to enhance natural cooling and air quality.
Multi-scalar simulation capabilities: Simulations operate at the town level, precinct level, and individual building level.
Application in Pongo Northshore precinct:
Design adjustments included shifting structural footprints and cutting structural voids/holes through building masses.
Targeted natural ventilation enhancements specifically in neighborhood centers to optimize thermal comfort and minimize air conditioning reliance.
Solar shadow analysis simulates shadow trajectories from morning through evening:
Informs placement of public parks, outdoor dining, plazas, playgrounds, and child care centers within shade zones so children can remain outdoors continuously.
Smart Environment and Estate Services:
Integration of estate sustainability initiatives: Expanded cycling networks, rooftop solar photovoltaics, and rainwater harvesting infrastructure.
Sensory network deployment: Solar panels across hundreds of HDB blocks are outfitted with IoT sensors monitoring energy generation rates.
Immediate detection of panel malfunctions occurs when energy collection metrics drop.
Proxy meteorological data: Aggregated solar generation deficits act as real-time proxies for local microclimate weather variations (e.g., localized cloud cover or rainfall over specific towns).
Defining the Vision / Point of View (POV):
Superficial smart technology deployments (e.g., Barcelona 1.0 installing solar streetlights costing per unit) fail if disconnected from human-centric outcomes.
A true Point of View dictates that technology is secondary to human impact: System efficacy is judged on whether it improves human lives, yields cost savings, enhances convenience, elevates safety, and sustains the environment.
Requirements Taxonomy in Software Engineering
Requirements gathering encompasses distinct functional, non-functional, and data dimensions:
Functional Requirements:
Define the specific, concrete actions and behaviors a software system must execute.
Standard focus in computer science and software engineering.
Examples in e-commerce:
Displaying vendor catalog items.
Selecting items to add to a shopping cart.
Executing cart checkout sequences.
Selecting payment gateways, computing discount logic, and processing shipping options.
Non-Functional Requirements (Quality Attributes):
Define operational qualities, performance thresholds, and architectural constraints rather than explicit end-user features.
Key Quality Attributes:
Maintainability
Performance speed
Usability (core focus of User Experience design)
Scalability
Security
Boundary gray lines exist between categories: Authentication mechanisms (e.g., login screens) serve functional user interactions while simultaneously fulfilling system security quality attributes.
Data Requirements:
Map underlying data flows, entity relationship structures, and database schemas essential for functional execution and machine learning/AI model processing.
User Experience (UX) Requirements and Personas
UX requirements prioritize understanding user behaviors, pain points, and psychological contexts prior to software execution.
Persona Definition:
Archetypal, fictional user representations whose goals, demographic traits, and behaviors reflect a broader segment of actual users.
Identify recurring behavioral patterns to reveal shared user friction points.
Must be grounded in empirical qualitative/quantitative research (interviews, field observations, empathy sessions), not constructed purely from speculation.
Persona Attributes and Variables:
Captured dimensions include skill level, background experience, personal attitudes, socio-economic status, purchasing behavior, and tool preferences.
Target ranges must encompass spectrums such as Novice vs. Expert, frequency of system usage, and foundational technical competencies.
Personification requires assigning realistic identifiers (names, age, employment, income) to foster design empathy without adding extraneous noise.
Case Example: Jayen Leu:
Age/Status: 21-year-old Year 1 university student.
Physical Condition: Semi-deaf (representing the hard-of-hearing demographic).
Pain Points: Experiencing friction when communicating in classroom environments.
Goals: Comprehending professor lectures accurately and expressing thoughts seamlessly.
Persona Optimization Rules:
Include only relevant details directly impacting design decisions.
Avoid over-specifying irrelevant traits that add unnecessary complexity or induce character inconsistencies.
Balance realistic humanization with foundational research data.
Provisional Personas:
Formulated based on baseline assumptions when empirical user research data is incomplete or unavailable (e.g., pioneering a novel product like AI smart glasses, as opposed to mature platforms like Facebook with massive telemetry data).
Typology and Construction of Personas
Persona Categories:
Primary Persona: The single main user profile targeted by the product design. Every project scope must focus strictly on one primary persona. (ONLY ONE PRIMARY PERSONA)
Secondary Personas: Essential auxiliary profiles required to illustrate complete workflow dynamics (e.g., representing the seller side in an e-commerce ecosystem where the buyer is primary).
Supplemental Personas: Indirect stakeholders, such as enterprise procurement officers or purchasing managers who acquire software for employees who serve as actual end users.
Step-by-Step Persona Creation Process: *** (IMPORTANT)
Identify critical user characteristics and define their relevant ranges.
Plot target range spectrums across identified traits.
Group mapped traits into repeating behavioral patterns.
Synthesize traits into representative demographic and psychographic profiles.
Strip away redundant data and reconcile internal inconsistencies.
Humanize the profile via naming and background details, subsequently categorizing its persona class (e.g., Primary Persona).
Empathy Mapping Framework
Definition and Function:
An empathy map (popularized by Dave Gray) is a collaborative visualization tool utilized to establish a unified team consensus regarding end-user mental models and drive user-centric design choices.
The Four Quadrants:
Says: Contains direct, explicit statements spoken by the user during research interviews or observational studies.
Thinks: Captures internal cognitive processes, beliefs, and implicit thoughts held throughout task execution.
Does: Documents observable physical actions, steps, and behaviors undertaken to fulfill tasks.
Feels: Maps emotional states, tracking moments of excitement, anxiety, frustration, and operational friction.
Empathy Map Instance: Consumer Purchasing a Television:
Says: "I want something reliable"; "What size is it?"
Thinks: "I am wasting too much time"; "I want something awesome."
Does: Searches online retail websites; conducts comparative research; consults peer recommendations.
Feels: Excited, overwhelmed, fearful of making an incorrect decision.
Narrative Scenarios and Use Cases
Scenario Definition:
An informal narrative describing a specific operational situation, illustrating how system features relieve persona pain points and fulfill goals.
Focuses concretely on problem resolution while deliberately keeping user interface (UI) and technical implementation details abstract.
Scenario Instance: Home Bakery Logistics (Jason):
Persona Profile: Jason, 21-year-old student working as a part-time delivery driver for his mother's home bakery business; utilizes standard Google Maps.
Goals: Assist his mother; complete delivery runs efficiently via optimized route planning.
Frustrations: Excessive manual planning effort; dealing with unresponsive or untrackable customers.
Narrative Context: At noon, Jason launches the Roadrunner application and imports delivery orders. The application automatically generates an optimized route and task sequencing. Roadrunner pushes automated arrival notifications to recipients containing real-time estimated arrival times (ETA). Halfway through the route, Jason re-orders stops dynamically to adapt to traffic, subsequently navigating to available parking spaces.
Scenario vs. Use Case Taxonomy:
Scenario: Goal-concrete, UI-abstract. Emphasizes human narrative and problem resolution.
Use Case: UI-concrete, Goal-abstract. Formally delineates discrete interactions split between system responses and user inputs.
Use Case Step Sequence Example:
System displays data input interface.
User imports order manifest via Google Spreadsheet.
System computes and displays recommended route sequence.
Scenario Types:
Context / Simple / Easy Scenarios: Depict the "happy path" where operational flows occur without errors or exceptions.
Key / Concrete Scenarios: Integrate detailed system behaviors as UI architectures solidify.
Hard / Exception / Validation Scenarios: Detail system performance during edge cases and operational disruptions (e.g., absent recipients, sudden delivery delay requests, road accidents along planned routes), directly defining supplementary functional requirements.
Personas and Scenarios in AI-First Systems
The integration of Artificial Intelligence intensifies the reliance on robust personas and scenario planning.
When user interfaces are generated dynamically by adaptive AI engines, static screen layouts become obsolete; user goals and operational constraints remain the only stable anchors.
Ambiguous or poorly defined requirements yield erratic and unpredictable AI agent behaviors.
Scenario mapping establishes essential framework boundaries for human-AI interaction, governing algorithmic responsibility, user trust calibration, and system-to-human handoffs
Task :
(-Select a problem in our team
-Use data from interviews/observations to identify user needs and pain points
-Create a provisional persona (Identify key charactersistics of this persona, and give it a name, goal and frustrations. Don’t make it too detailed, only include details of this persona that are relevant to the problem.
-Write a context scenario (Narrate a realistic situation to achieve the main goal, and base the scenario on the persona. Focus on what happens and why.) My question is, is the scenario for the persona before using the product or after?
Context scenario: Laura, a busy project manager at a mid-sized tech firm, struggles to manage her team's workload effectively. She often feels overwhelmed by the constant influx of emails and meetings, which distract her from her primary goal of ensuring project deadlines are met. One day, while attempting to prioritize tasks for her team, she realizes that without a centralized tool to track project progress, communication breaks down, leading to missed deadlines and increased stress.
-Reflection : Are there UI solutions coming in? Is it getting too detailed too early? Are the information presented relevant?
Questions:
-’make your requirements less dumb’ what does that mean? This phrase suggests that we should strive for clarity and simplicity in our requirements to enhance understanding and usability, ensuring that they are practical and actionable rather than overly complex or vague.
-In stories/scenario, the devil is in the details, make sure your story is SUPER detailed, not in the form of software, but in the story elements. Refer to home bake delivery story in IS211 03 Requirements video.
-User story = Hero (the user) + Goal + Conflict, it is one sentence long. To create effective user stories, we need to identify the hero's motivations clearly, define the specific goal they aim to achieve, and articulate the conflict they face in reaching that goal.
-