01
Accessible first steps
Basic actions should have clear guidance, with more complex content introduced gradually as needed.
Our approach to product design
We are interested in software that helps people understand relationships through interaction, observation and comparison. This page explains how we evaluate ideas, design interactions and verify results.
Evaluating product ideas
We begin by assessing whether a need is clear, where existing options fall short and whether we can maintain the software.
Technical feasibility is one factor in that decision. The intended use, usage context and maintenance cost also inform whether we proceed with development.
Representing relationships
Different subjects can sometimes be described using similar structures, such as a shared arrangement or pattern of change. We are interested in how software can represent these connections.
Different visual representations can provide several ways to examine the same relationship. They should support comparison of similarities and differences, with explanations of where the model applies.
Interaction design
We focus on interactions that allow people to adjust conditions, observe results and repeat comparisons. A clear connection between an action and its feedback can help people check their understanding.
The design should explain what can be adjusted, which rules apply and what the results mean. People should have the guidance they need to explore independently.
Design requirements
We use these requirements to evaluate interaction designs. Their effectiveness needs to be checked through testing.
02
Verifiable results
For deterministic calculations, the same input, rules and initial state should produce consistent results that can be compared and checked.
03
Timely, clear feedback
Relevant changes should appear promptly after an action. If processing takes time, show its status and where the result will appear.
04
Controls with a clear purpose
The software handles calculations and state. The interface should prioritize controls relevant to the current task and explain their purpose.
05
Independent exploration
Provide clear conditions, scope and feedback so people can compare outcomes and form their own conclusions.
Verifying rules and results
Development tools may change with practical needs. The rules that determine results still need to be documented and available for review and testing.
For deterministic calculations, keeping the input, rules and initial state the same should produce consistent results. This supports repeated comparison and verification.
Discrepancies found during testing need to be recorded and investigated. Any limits on where a rule applies should also be explained.
Design and publishing boundaries
These requirements guide our design and public descriptions. Details of released products belong on their respective product pages.
- Do not preview the name, features or timing of an unreleased product.
- Do not overstate outcomes or make unsupported promises.
- Do not present an interactive experience as a course, examination or assessment of achievement.
- Do not rely on open-ended input without explaining how to use it.
- Do not add prerequisites unrelated to the intended use.
Discuss product and interaction design
Contact us by email with related suggestions, usage scenarios or partnership enquiries.
contact [at] molansen.com