This is a pretty simple philosophy, however, in practice, this can be very difficult. We tend to focus on wants and needs as separate requirements. In software, you could call needs non-functional requirements and wants the functional requirements. However, this too can cause a myriad of questions - is the user's needs more important or their wants? If we incorporate person centered thinking in our design methodologies we can learn to use important to and important for to balance the scales and set a solid foundation for our software to be built upon.

What is Important To versus Important For?

"Important To" is what the person wants, it is what is important to them. "Important For" is what the person needs, or what is important for them. Often people in care situations have unbalanced scales - they often have their physical needs met but are not able to do much of what they actually want. In software and games, we want to provide a balance to this or even lean into user wants nonetheless we have to be considerate and careful to not negate things like performance, reliability, security and all the other -ilities.

Important For

I am choosing to start with the "Important For" thought experiment because I think in software/game design we look at the "Important To" aspect in ideation and tend to think of things like accessibility, scalability, reliability, security, performance, and especially maintainability much later on - or dare I say when we have to. As a Quality Engineer, this often causes me great anxiety. I would love to see collaboration on these topics as a way to ensure we have balanced the scales for development cycles well beyond our MVP. If we think of reliability like housing, scalability like renewable resources, accessibility like public transportation, and maintainability like our public works running efficiently our software would operate like a utopian metropolis.

Although I might have utopian dreams, I do not think it is reasonable. That is why we should in ideation or design phases we should try and come to agreements on what we deliver that is "Important To" the users and what is needed to support that across their experience.

Important To

There is not much more explanation I need to provide here other than thinking through scope. This planning practice will fail us if we don't think through what we can provide with the tools, resources, and energy at our disposal. This is an area to shoot for the stars but aim for the moon. Get all the ideas out there and then prioritize so you can be effective.

How do I implement this?

Step 1: When in doubt draw it out.

This was my favorite line to tell my students when I was a teacher. If you don't know where to start drawing a basic set of scales. On one side is what is "Important To" your user, and on the other what is "Important For" them. The scales are balanced on a foundation draw that to as this is what will be what is equal to user support systems.

Step 2: Stickies, lots and lots of stickies.

Sticky notes are a designer's best friend are they not? Make it an activity or collaborative event for people to add what they think is important to, for, and support the user.

Step 3: Scope it out.

Determine what is feasible for the given lifecycle and use the ideas generated for backlog material. Do your best to balance the scales in each release so that both to and for are addressed in each phase or cycle of development.

Conclusion

We do a lot of these practices already, I know that... I see that. This is just a simplification of processes. I think by doing this type of exercise we will exit the activity with better requirements, better timelines, and ultimately more optimal user/player experiences.