A computerized solution begins with a problem someone is trying to solve.
That sounds obvious, but it is easy to reverse the order. People often start with a favorite technology and then ask how they can use it.
A better question is:
What does someone need to accomplish, and how could a computerized system help?
Imagine a community soccer program. Before Saturday's match, a coach needs to know which players are available.
The need is not:
Build a website.
The need is:
Help the coach know who is available for the match.
A website might eventually be part of the solution. So might a mobile app, a shared system, or another digital tool. But choosing the technology before understanding the need can lead to a system that works technically and still solves the wrong problem.
The real soccer program contains far more information than the coach needs for this particular question.
Players have:
For Saturday's lineup, only some of those details matter.
A computerized solution cannot—and should not—represent everything about the real world.
Instead, it represents enough information to support a particular purpose.
For the coach's question, the system might need to know:
The point is not to decide the final design yet. The point is to notice that purpose determines what the system needs to represent and do.
A useful solution is designed around someone who needs to accomplish something.
In the soccer example, several people could interact with the same system:
Each person has a different goal.
If you do not know who is using the system, it becomes difficult to decide what the system should do.
Before designing a computerized solution, ask:
Those questions keep the focus on the user's need instead of on the technology.
A vague goal such as:
Make team scheduling easier.
does not tell you enough to decide whether the solution works.
A stronger goal describes something you could observe:
The coach can see which players have reported that they are available for Saturday's match.
Now there is something to check.
You can ask:
A computerized solution becomes much easier to design when the desired result can be observed.
There is also an important difference between what the user needs and the work required to create it.
Consider these statements:
The coach needs to know who is available for Saturday's match.
Add a way to record player availability.
Check that the coach can see the recorded availability.
The first statement describes the need.
The second describes work that might help create the solution.
The third describes a way to check the result.
Those three ideas are related, but they are not interchangeable.
In the next Learning Activities, you will give them more precise names and learn how they work together.
Technical work is rarely a straight line from idea to finished product.
A more realistic process looks like this:
Suppose the coach opens the system and sees player names but cannot tell which match the availability belongs to.
The system may be functioning exactly as programmed, but it is not yet solving the full problem.
That gap is useful information.
The check tells you what needs to improve.
At this point in the course, you do not need to know how to program the solution.
Focus on the reasoning.
A useful computerized solution should have a clear connection among:
Need → User → Desired result → Work → Evidence
If one of those pieces is unclear, the solution is more likely to drift away from the real problem.
Computerized solutions begin with people and purposes.
Before thinking about code, diagrams, or specific software, identify:
The next activity introduces a structured way to describe that need.