This is a brief guideline for reporting business ideas, product concepts or technical implementation.
- Product Concept
- Technical Implementation
- Business Plan
A Product Concept explores a user problem in the context of a stakeholder system. It is based on personal purposed that is shared within a team of like-minded innovators. The development of a product concept follows an iterative process adhering to goals of desirability, feasibility, and viability.
4-6 pages (ca. 2500-3000 Words), free format, attachment unlimited
Is it a real user problem and do you have (anecdotal) evidence? How sever is the problem for user on a continuum between mosquito-bite to shark-bite?
Is it technically feasible within the laws of physics or within the lifetime of an engineer?
Is economically efficient or is a net loss business? Can you save investors' or tax payers' money immediately or in the long run?
- Purpose
- Describe why the topic is important to you and why you chose this topic
- Provide an empathetic personal description to catch the readers attention
- Provide quantitative data to show the magnitude of the problem for an organization or society
- Team
- Who are you and what are your roles in the team?
- Which is your unique skill and resources that nobody has or can beat you in?
- Why is your team the best for the mission at hand?
- Context and Stakeholders
- List all stakeholders in the system you analyzed with a brief description
- Show interdependencies between stakeholder groups
- Describe the most important stakeholder group(s) and their interactions in Detail
- Exploration Journey
- Show how your project developed over time
- Provide any material you to showcase how your understanding of the problem, use-cases, and prototypes
- Help the reader understand why you chose to slightly change course or pivot during the project?
- Problem Description
- Why is the problem relevant to your users?
- Why did you chose exactly these problems from the set of existing problems your users have?
- List and describe the most important user problems you discovered (sometimes needs to go into the attachment)
- Use Cases
- List the most important use cases and why you prioritized them
- Show the additional material you used to brief developers on the use case
- Provide the full list of use-cases and all briefing material in the attachment
- Solutions
- Show the solution and describe the benefits
- Clearly map the requirements from the uses case to the benefits of the solution
- Provide qualitative and quantitative estimation of the solution's advantages
- Reflection and Next Steps
- Reflect on the process and the outcome: What would you change next time, what would you have added?
- Which next immediate steps are you planning to do to implement your solution both technically and economically?
- Which future vision of your product do you have?
A technical implementation as a software or hardware prototype being built as part of a business model or product concept. It is based on validated user feedback from a thoroughly explored context. It is created based on the briefing of a product team supplying neatly defined use cases and basic pretotypes, e.g. wireframes. It follows an agile methodology adhering to goals of usability, extensibility, and efficiency. Security is an additional objective only valid at Master Level.
Technical Implementations can be Data Visualizations (Data goes one way), Web-Apps (Data goes two ways), IoT-Systems (Data goes multiple ways)
- Can I immediately understand all UI Elements? (Don't make think!)
- Can I reach my goals faster than with alternative solutions? (Paper is faster?)
- Is the UI visually appealing and follows basic accessibility standards? (Form follows function)
- Is the code base well structured and formatted?
- Can a third party easily understand and extend the code base?
- Is the code clean and following idiomatic standards of the chosen technology stack?
- Is the processing fast enough for the UI to be effective?
- Is the code profiled and are implications on processing time and memory usage understand and handled, if no solved?
- How does the system behave under load (e.g. high-traffic or extreme requests)?
- Is data protected from non-malicious attacks (user access model)
- Are basic security mechanisms within and between systems engineered well?
- Is the data and its processing protecting users from being de-anonymized or identified?
The Report Structure for Data Visualization Project follows the Framework for Data Visualization, Analysis, and Design from Munzner. The Framework offers a precise language for describing implementation purpose and detail of data visualization heavy project.
- Context: Domain Situation (10%)
- What is the domain and who are the stakeholders?
- What is you key user and what are their goals?
- Which Use-Cases are there and which did you prioritize?
- Translation (30%):
- Reason about Data and Task Abstraction, i.e.
- Display you Design choice for Visual Encoding and Abstraction Idiom
- Marks and Channels
- Implementation (50%):
-
Display the detailed description of your implementation
-
Show the technology stack and architecture your used
-
Describe the design choices for each element in detail
-
Show the final product in Screenshots on the most important user interactions
-
Quality Criteria:
- Optimum: Web application based on real-time data with own frontend and usage and sharing of FHIR Data
- Medium: Web application based on non-realtime data with frontend from visualization framework usage of FHIR data but no API
- Minimum: Data Visualization of non-realtime data with custom data structure
- Testing (5%):
- Provide unit tests
- Show results of runtime and memory profiling
- Show results of a load test
- Roadmap (5%):
- Reflect on the development process and its outcomes: What went well, what to change?
- What are immediate next steps?
- What is the vision for the product and its architecture?
TBD