Lecture 14: Design Thinking and Implementation

Welcome to lecture 14. The final period is in progress with two lectures remaining before final presentations.
Thomas, a colleague, is observing for pedagogical studies.
Agenda:
- Recap of course goals.
- Briefly address grading.
- Reflection on project agreement documents.
- Tips on testing.
- Final documentation template.
- Preview of upcoming lectures.

Design Thinking: Conceptual framing of a "tracker of something weird". Students define:
- The phenomenon to track.
- The users.
- The features.
- Present idea based on implementation and testing experiences.
- Define name and purpose.
- Express design drivers.
- Document in a Notion template for the Wilhelm Paya web gallery.
- Option to keep documentation private, if desired.
Reflective Prototyping: Intended to improve for the next year.
- Involves prototyping early to validate technical feasibility before defining requirements.
- Using dev kits, coding, and testing sensors.
- Custom PCBs during implementation.
Technical Skills: First six weeks focused on basic technical skills.
- Apply skills to create a working project.
- Rehearse creating semi-complex systems.
- Collaboration across specializations.
- Demo implementation.
Teamwork: Emphasizes:
- Communication.
- Planning.
- Agreement.
- Negotiation.
- Openness.
- Commitment.
- Responsibility for technical contributions.

Design Thinking: (1/5 of grade)
- Based on initial ideas, presentation, poster, and report.
Reflective Prototyping: (1/5 of grade)
- Scenario document, solution document, requirements specification, and project plan.
Technical Specialization: (1/5 of grade)
- Completed exercises and task reports.
Proof of Concept Implementation: (1/5 of grade)
- Demo, final presentation, and test report.
Teamwork: (1/5 of grade)
- Peer assessment.

Field testing should start soon with a goal to complete it by the 20th of the month.
Test report due by the end of the month.
Final presentation on May 28th in the atrium space.
Final Presentation Details:
- Design poster.
- 15-minute presentation, including demo.
- Prepared video of the demo in case of technical issues.
- Video expected to be continuous, showing the demo working.
Final Documentation: Includes design concept, demo implementation, and test report.
Compensatory essays due by June 6th.

Knowledge Needed to Create a Key Interaction Scenario:
- Basic functionality.
- The problem being solved.
- Target audience/users.
- Alternative ideas.
- User needs.
- Preliminary test results.
- Positive user feedback.
- Technical feasibility.
Reflections on Creating the Scenario:
- User need/product idea framing requires ideation, review, and filtering.
- Express ideas as a story including the user, their motivation, and how the design serves their need.
- User research and context are required.
- Feasibility with available IoT technology is key.
- Confidence that users prefer the solution.

Need to know my requirements for the course, kind of the generic course requirements.
- Principal solution document is on a higher level than the requirements. The requirements are more specific and they need to be expressed in a way that's very definite and testable.
Knowledge Needed for the Solution:
- The scenario.
- How it will function.
- That the technical solution will work.
- Proper scoping for the course.
- Technical details (cloud service, communication, web sockets, Bluetooth).
- Ability to describe the solution clearly to a non-technical audience.
In order to come up with this solution based on the user scenario, you must be able to show that you can actually do with the solution.

Information needed
- Requirements.
- Progress
- Difficulties/Risks
- Team capabilities and Availability
Plan should match the goal defined in the scenario.
Detailed knowledge from the requirements document.
Awareness of existing creations and available resources.
Incorporate risk mitigation strategies.

It's important that you have one requirement per statement. Also you need to be clear on why you have certain values there. Also an important thing in order for you to be able to maintain your documentation and work is that you don't have duplicate entries.
Important Considerations for Requirements:
- Express requirements using "must".
- Ensure testability.
- One requirement per statement.
- Justify values based on research.
- Avoid duplication and conflicts.
- Place requirements in the correct section (hardware vs. software).
- Establish traceability for testing.
- Specify core functionalities in greater detail.
- Use use case-based approach for interactional requirements.
- Consider available resources.

Requirements and specifications should be solution independent to allow flexibility.
The difficulty lies in balancing generalist and specialist skills.
- Reflective Skills: Design thinking, user relevance, technology relevance, business opportunity.
- Specialist Skills: Specifications, controlled reasoning, measurable results.

Goal: Validate all requirements in the required spec.
Some tests are checks, others are real tests.
The requirements especially about the style or easiness of use are really challenging to put into requirements.
Must-Have Requirements
- Sense the phenomenon being tracked.
- Transmit data to the cloud.
- Receive and handle commands.
- Pairing.
- Wireless/physical.
- Low power.
- Rechargeability.
- 4 cloud services(User accounts, devices, data and the app itself).
- Different types of app(User accounts there. You have the pairing. You have the data from the device shown in the app).

The more bigger unit you are testing, the more sources there are for possible errors.
Test each unit separately, starting with individual components and functions.
Test interactions across boundaries between different elements of the integrated system.
Use dummy data to test communication functionality before implementing real data.
Test with users, with use case based testing before going to the users. Before this you have to polish all the errors before going there.
When testing with users, prioritize safety and avoid guiding them too much.

Listing team members, specializations, who is the project manager in your team. Then about the concept that it has a name. There's your vision. It's basically very similar to what you are going to present in your poster. In the final report also you need to explain what's the purpose, what's the competitive advantage, so what makes the difference that makes your design your design And what's kind of why it's preferred for user?
Include background research. The last lecture will be about cost estimation.
Address the demo scenario, video, and test reports.
Share creations online with proper licenses.
Final lectures will cover cost estimation and final presentations/poster details.