Back to feed
Planning Notes·핏과 결에 대한 소고

On Types of Problems, Coaching, Company Culture, Agile, Improv, and More

NS
normalstory
cover image
YouTube 영상 미리보기YouTube
external media

Video summaries

  1. No summary yet.


A summary of what we shared through UX study group activities



* Types of problems

  1) Puzzle: has an answer, and you can get better at it with continuous practice/experience. 

              Tests, school, curriculum, best practices — they all belong here.

  2) Problem: there can be several good answers.

  3) Mess: there is no correct answer.

               Most of daily life falls into this category.

               You have to think about how to persuade and how much of your learned (known) knowledge to include.

               * The moment you graduate high school, from that point on there are no answers. 

                 The instant you think there is an answer, a problem arises.





* An owner needs the capacity for business coaching. ( http://www.youtube.com/watch?v=tYH81mDlrbc )

         : advice, guidance, mentoring, pursuit-coaching, consulting, a peer relationship, not mandatory, focused on the individual, interaction,

           courage, goals, improving attitude, expanding the range of thinking, understanding the participant’s ability (potential), removing obstacles.

* The rookie coach’s problem is “thinking they need to solve it right away.” Because of this, people come to expect answers from the coach.

* The role of consulting: expressing the CEO’s intent in data, managing the internal (client-side) political issues of the project, providing a basis people can trust in the data, lending legitimacy through a big name, distinguishing within the client’s stated problem between issues of concept and issues of preconception, not solving the problem but generating the “concept.”

* Getting fired is rarely an issue of ability or of communication — more often it’s about interests at play, or simply the CEO’s will.





* Setting goals is, of course, also about checking whether the goals are right. (Since every problem is the difference between the perceived state and the desired state, solving a problem in one state usually creates one or more other problems.)

* When everyone agrees something is right, ask the “but what if it isn’t” question so that each person can find the answer themselves. (Video example — at the moment when you lie down, kneel, or say “I give up,” you have to fight against that.)

* You need to deal with the Gremlin (the enemy within you that nobody warns you about when you try to create change): look at whether it’s really a “Dremlin” at eye level. If you change one person, the water doesn’t ripple outward.

* What matters most for change is the “environment.”

    -> You have to change the very air itself.

    -> What you need is not willpower alone, but the will to change the environment (an environment that can control and sustain willpower).

* Everyone acts in line with the context demanded by the group or situation, and acts rationally.

   -> Thinking “why on earth is that person like that?” is itself the problem. Go and ask them, or put them into a different context.

   -> “That person isn’t good” — but modern education has only answered the question of whether you tried to become a useful “part,” or whether you’re suited to be a “part.”

* It’s the question that stings, isn’t it?
* Haven’t you just been working, not actually learning?
* After genuinely trying to do well, you need time to reflect on the outcome.
* The only answer to improving attitude: if there’s no time, make it. But the real issue is that each person simply lacks the motivation to solve the problem they’re facing.  -> You need to understand the fundamental interests at play. Once you start helping, happiness begins. 
* Is the team’s desire unified? 
* Do you feel the things you’re learning through the project? How much weight or value do you personally place on that?
* Understand each person’s desires and what you yourself can do.
* The more people there are, the higher the cost of reaching consensus.







* Agile (the classic serial process: contract → planning → design → development → customer  : X )
   -> Business changes over time and customer requirements change.
   -> Instead of documents, share the program or an alpha (beta) version of the output and get feedback.
   -> 1. Execute (produce a first-round sample based on documented information)
       2. Retrospect (understand each person’s interests and desires, align themes, fail fast, failure you don’t need to be upset about, 
          productive failure, grow by that much). 
       3. Improve (iterate) → customer  




* Through a study on improv, there’s a need to improve our ability to communicate more effectively.

1. Useful for prototyping. For those wondering what that means: previously, at Chang-jun Kim’s prototyping workshop, he said that once you’ve built a prototype, don’t stop there — it’s good to actually perform improv with it. That is, run the real simulation as improv. That’s what he’s talking about. 

2. Improv can be seen as one of those practices. This reminds me of something. At Agile Korea 2011 last year, Chang-jun Kim talked about a weakness of agile. There’s no “how to do it well” in agile practices. Among XP’s values is communication, but there’s no method for “how to communicate well.” There are things that make you do it more often, sure. Improv could be the thing that makes you do communication well. ^^*

3. Additional material (http://story.pxd.co.kr/540), (http://story.pxd.co.kr/537)

     * Reference: Improv and programming → http://www.slideshare.net/parkpd/ss-6238122




This English version was translated by Claude.

친절한 찰쓰씨
Written by
친절한 찰쓰씨

Pleasant Charles — UI/UX researcher at AIT. Keeping notes on design, planning, and slow days here since 2010.

More on the author's page

Keep reading

Planning Notes

May 26, 2026·1 min
Planning Notes

Turning AI’s Decisions into Real-World Action

May 24, 2026·2 min
Planning Notes

The two unchanging principles of vibe coding

Apr 12, 2026·3 min