Perspective. I stand over someone, my head 2 feet above theirs. I point to something in some bushes at my eye level. Can the other person see it?
A lot of interesting things can happen because of differences, even minor differences, in points of view. Arguments can start, ideas discovered, new systems invented. In doing a system design, some changes in perspective can be quite useful. In doing usability studies, some system designers use and watch users use the prototypes, in order to improve the performance of the system under conditions in the field. By viewing a particular problem in more than one way, the solution becomes clear.
A classic example: Plant 10 trees in 5 rows of 4 trees each. One can look at this from the perspective of 10 trees. It becomes clear that the 5 rows can’t all be parallel and so one starts placing 10 trees in various arrangements. It can take some time to arrange these trees to get 5 rows with 4 trees in each row.
Now comes the change in perspective: Instead of placing trees, try placing rows. Since some rows will intersect, you can start by choosing 5 lines, no 2 of which are parallel. When you do this, you will find the 10 points of intersection satisfy the desired conditions. Instead of hunting around for a placement of points, any line placement works.
Delegate. In dealing with large systems, it helps to forget some details, at least temporarily.
Two methods take advantage of this forgetfulness. Designing from the top down involves representing the components of the system by blocks and requirements and interrelations between the blocks, and then considering each block as a system to be designed to fit the previous requirements and interrelations. If necessary, each block can itself be broken into smaller blocks and interrelations.
The second method involves recognizing a set of primitive components, each of which can be easily designed and implemented, and then forgetting the implementation of the components and combining them in interesting ways to form larger systems.
What is success? The system you make should meet some goal, and in some cases you need to demonstrate the goal is being achieved, at least in part. So what do you do?
One strategy is design-to-test. This strategy says to create components that allow you to measure, or test, parts of the system to establish yes/no answers related to the system goals.
One such goal is reliability. Given the same conditions or stimuli, will the system give the same response? Will the system respond the same way even under environmental extremes? What limits will the system endure, or start to malfunction?
Other tests are diagnostics. If the system fails a certain test, does the failure indicate what portions need repair/replacing?
Some systems are transparent enough that all required tests can be performed externally, without the need for components specific for testing. Black box design does require at times a design-for-test philosophy.