Add Empathy At Work community article

Adds the final Post.md for the 'Empathy in the Workplace for Software Companies' community article, along with a supporting image. Also updates draft files with minor title and content edits.

docs/en/Community-Articles/2026-07-17-Empathy-At-Work/Post.md

@@ -0,0 +1,208 @@
+# Empathy in the Workplace for Software Companies
+
+My articles are mostly technical but this time I want to mention a soft-skill in workplaces. This is an emotional skill (EQ) which is important like IQ but without this skill people around you will think you are rude. That's empathy. Even though empathy comes with your character, if you realize you lack of it you can improve your empathy level. 
+
+## What's Empathy?
+
+It's as a discipline which puts behaviors to human-centered practices. Why we do it? For understanding users’ goals, constraints, emotions, mentality and tradeoffs. Then using that understanding to improve what teams build, sell, market and support. 
+
+**Empathy means making an effort to understand how another person sees a feature, message, workflow or pricing decision.**
+
+>  Great software is not created only with clean code, attractive designs, strong marketing campaigns or polished sales demos.
+
+It is created when teams understand the people behind the requirements:
+
+- What are users trying to achieve?
+- What do they already know?
+- What confuses or slows them down?
+- What makes them trust the product?
+- What do they see as valuable?
+
+For a software company, empathy should not be treated only as a soft skill or company value. It should be a practical way to replace internal assumptions with real evidence about users, buyers, administrators, developers and other people affected by the product.
+
+Empathy should also be a cross-functional responsibility. Developers, designers, product managers, sales, marketing, support and leadership all see different parts of the customer experience.
+
+When these teams bring their knowledge together, they can make better product and business decisions.
+
+## What Empathy Means in a Software Company
+
+![Why empathy matters in software development](https://chatgpt.com/images/why-empathy.png)
+
+Empathy has two main parts.
+
+**Affective empathy** means feeling or sharing another person’s emotions. 
+
+**Cognitive empathy** means understanding another person’s point of view, goals, needs, concerns and limitations.
+
+Both are important. However, cognitive empathy is usually more useful when teams review a feature, workflow, message, onboarding process or pricing decision.
+
+It encourages the team to ask what a specific person would understand and experience.
+
+> **The useful question is not:**
+> “Would I like this?”
+>
+> **It is:**
+> “Would this specific user, in this situation, with this knowledge and these limitations, understand the value and complete the task?”
+
+This distinction is important because employees know much more about the product than customers do.
+
+> A workflow that seems obvious to the software developer who implemented it, **may be confusing to a first-time user**. A message that sounds clear to an engineer may **sound like technical jargon to a buyer.** A feature that looks simple in a sales demo may still be **difficult to use in a real company**.
+
+Affective empathy also matters because it helps people care about customers and make responsible decisions. However, emotion alone is not always a reliable evaluation method.
+
+A strong customer story may receive too much attention, even when it does not represent most users. Emotional pressure can also lead to stress or biased decisions.
+
+A better approach is to combine emotional concern with structured questions:
+
+- What kind of disappointment or confusion might this situation cause?
+- What is the user trying to achieve?
+- What information can the user see?
+- What would the user reasonably understand?
+- What could stop the user from continuing?
+- What would make the user trust or doubt the product?
+
+In simple terms:
+
+> Empathy means testing our assumptions and learning how real users actually think, feel and use the product / feature.
+
+ALWAYS ASK YOURSELF:
+
+> **If I were using this feature / app, what would I criticize?**
+
+I know you can all find negative sides of your development, but we just don't care, ignore it... This leads the outputs are less usable of our work. This makes us far from being empathic. 
+
+**Sit on the other side of the desk for a minute.**
+
+## Empathy Is a Cross-Functional Responsibility
+
+![Empathy questions for developers, designers, sales, marketing and the wider team](https://chatgpt.com/images/roles.png)
+
+Empathy should not belong only to the design or research team.
+
+Each team member sees a different part of the customer reality.
+
+| Team             | Ask your self this question                                  | Inspect these things...                                      |
+| ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| Developers       | Where would a first-time user fail, hesitate or misunderstand the system? | Defaults, errors, performance, learnability, edge cases and technical friction |
+| Designers        | Does the interface match the user’s language, expectations, abilities and situation? | Navigation, accessibility, cognitive load, interaction flow and error recovery |
+| Product managers | Are we solving a real and important user problem?            | User goals, priorities, evidence, value and expected outcomes |
+| Sales            | What would make a buyer question the value, risk, effort or credibility? | Demo flow, objections, trust signals, implementation concerns and time to value |
+| Marketing        | Would the intended customer recognize the problem and believe the promise? | Positioning, jargon, calls to action, expectation-setting and message-market fit |
+| Support          | Where does the product repeatedly cause confusion or extra work? | Ticket themes, escalations, documentation gaps and common workarounds |
+| Leaders          | What in our process makes customer understanding difficult or optional? | Incentives, priorities, team structure, review habits, tech trends and psychological safety |
+
+The goal is for each team to use the customer evidence available to them and bring it into product and business decisions.
+
+## Empathy Loop That's Stated in a ISO Standard
+
+And yes! Someone even created a standard for what I'm talking. It's called **ISO 9241-210 standard**. 
+Its full title is *Ergonomics of human-system interaction*. Basically it deals with any system that has interactivity. So our screens, APIs are all included in this standard. The main idea is simple: teams should design software around real users, their goals and their working environment. Not only around technical requirements. These 6 steps about how to design a better system, puts customers in the center.
+
+![image-20260720210821166](D:\github\volosoft\abp\docs\en\Community-Articles\2026-07-17-Empathy-At-Work\image-20260720210821166.png)
+
+Let me adjust these to a software developing team:
+
+1. Decide how user experience work will be managed, who is responsible and what risks or limitations exist. The below are the different areas to understand the feature/app/requirements:
+   - User interviews
+   - Customer calls
+   - Support quetions
+   - Sales notes
+   - Product analytics
+   - Surveys
+   - Session recordings
+   - Contextual observation
+   - Customer feedback
+   - Win-loss analysis
+2. Learn who the users are, what they want to do, where they use the product and what problems they face. In this section you really do empathy. Understand your user’s:
+   - Goals
+   - Concerns
+   - Knowledge level
+   - Mental model
+   - Limitations
+   - Expectations
+   - Work environment
+   - Emotional state
+3. Turn user needs into clear and testable requirements.
+   - For example imagine there's a problem like Users don't use the reporting module. We need to report this as "New users can't easily find the information they need to prepare a weekly performance report."
+4. Build ideas, wireframes, prototypes or simulations. It is better to test simple versions early before spending too much time on development. You can do the followings:
+   - Prototypes
+   - New workflows
+   - Updated copy
+   - Better defaults
+   - Simplified onboarding
+   - Improved documentation
+   - Pricing changes
+   - Sales and marketing materials
+5. Test the product with users or UX experts. Check whether it is easy to use and whether it meets user requirements. And be open to the discussions. You can test via the following methods:
+   - Usability testing
+   - Customer interviews
+   - Prototype testing
+   - Cognitive walkthroughs
+   - Heuristic reviews
+   - A/B tests
+   - Product analytics
+6. If there're still problems, improve the design and test again. The process ends when the important user needs are met. Empathy should not be a one-time workshop.
+
+---
+
+## Empathy Maps
+
+An empathy map helps teams organize what users:
+
+- Say
+- Think
+- Do
+- Feel
+- Find difficult
+- Want to achieve
+
+It is useful after interviews, support reviews or customer observations.
+
+| Area          | Question                                                     |
+| ------------- | ------------------------------------------------------------ |
+| Says          | What has the user directly said in emails, calls or support questions? |
+| Thinks        | What concerns or beliefs may guide their behavior?           |
+| Does          | What actions, repeated steps or workarounds can we observe?  |
+| Feels         | What emotions appear during important moments?               |
+| Pains         | What creates confusion, risk, delay or extra effort?         |
+| Gains         | What result, speed, control or reassurance does the user want? |
+| Evidence gaps | What do we still need to learn?                              |
+
+Important points should be connected to real customer evidence whenever possible. Inferences should be clearly marked as assumptions.
+
+## Journey Maps
+
+A journey map shows the user’s experience across several stages.
+
+These may include:
+
+- Awareness
+- Evaluation
+- Trial
+- Purchase
+- Onboarding
+- First successful use
+- Regular use
+- Support
+- Renewal
+- Expansion
+
+Journey maps help teams see where users:
+
+- Become confused
+- Lose trust
+- Experience delays
+- Need help
+- Stop using the product
+- Create workarounds
+- Leave the process
+
+They are especially useful for cross-functional work because product, marketing, sales, support and engineering can all contribute
+
+
+
+## Better Empathy, Better Software
+
+Empathy is not simply about being nice. In a software company, it means building the right thing, for the right people, in the right way. It helps developers anticipate failure, designers reduce cognitive friction, sales teams understand buyer risk, marketers communicate in the customer’s language, and leaders create systems that reward learning rather than assumption.
+
+When teams consistently ask how their work will be understood, used, trusted, and valued by the people on the other side of the screen, they build products they can be proud to use, recommend, and stand behind.t

docs/en/Community-Articles/2026-07-17-Empathy-At-Work/draft/deep-research-report (2).md

@@ -1,8 +1,6 @@
-# Empathy in the Workplace: The hidden skill behind a successful product
+# Empathy in the Workplace: The hidden skill behind success 
 
-## Executive Summary
-
-For a mid-size software company, workplace empathy should not be treated as a soft cultural slogan. The strongest evidence supports treating it as a disciplined, human-centered practice for understanding users’ goals, constraints, emotions, mental models, and tradeoffs, then using that understanding to improve what teams build, sell, market, and support. In software work, the most operationally useful form is usually **cognitive empathy** or **perspective-taking**: the deliberate effort to understand how another person interprets a feature, message, workflow, or pricing decision. **Affective empathy** matters too, because it motivates care and ethical concern, but on its own it is less reliable as an evaluation method and can produce distress or biased judgment if it is not structured. citeturn34view0turn29view1turn29view2turn28view3turn7search0turn28view0
+For a company, workplace empathy should not be treated as a soft cultural slogan. The strongest evidence supports treating it as a disciplined, human-centered practice for understanding users’ goals, constraints, emotions, mental models, and tradeoffs, then using that understanding to improve what teams build, sell, market, and support. In software work, the most operationally useful form is usually **cognitive empathy** or **perspective-taking**: the deliberate effort to understand how another person interprets a feature, message, workflow, or pricing decision. **Affective empathy** matters too, because it motivates care and ethical concern, but on its own it is less reliable as an evaluation method and can produce distress or biased judgment if it is not structured. citeturn34view0turn29view1turn29view2turn28view3turn7search0turn28view0
 
 Human-centered design standards and guidance point in the same direction: good systems are built on an explicit understanding of users, tasks, and environments; users are involved throughout design and development; evaluation is iterative; and multidisciplinary teams participate in the work. That makes empathy a cross-functional operating principle, not just a design-team activity. Developers, designers, sales, marketing, support, and product leaders all have relevant pieces of the customer reality. citeturn34view0turn34view1
 

docs/en/Community-Articles/2026-07-17-Empathy-At-Work/draft/v1/deep-research-report (2).md

@@ -2,11 +2,9 @@
 
 ## Executive Summary
 
-For a mid-size software company, workplace empathy should not be treated as a soft cultural slogan. The strongest evidence supports treating it as a disciplined, human-centered practice for understanding users’ goals, constraints, emotions, mental models, and tradeoffs, then using that understanding to improve what teams build, sell, market, and support. In software work, the most operationally useful form is usually **cognitive empathy** or **perspective-taking**: the deliberate effort to understand how another person interprets a feature, message, workflow, or pricing decision. **Affective empathy** matters too, because it motivates care and ethical concern, but on its own it is less reliable as an evaluation method and can produce distress or biased judgment if it is not structured. citeturn34view0turn29view1turn29view2turn28view3turn7search0turn28view0
+ 
 
-Human-centered design standards and guidance point in the same direction: good systems are built on an explicit understanding of users, tasks, and environments; users are involved throughout design and development; evaluation is iterative; and multidisciplinary teams participate in the work. That makes empathy a cross-functional operating principle, not just a design-team activity. Developers, designers, sales, marketing, support, and product leaders all have relevant pieces of the customer reality. citeturn34view0turn34view1
-
-For day-to-day practice, the most effective pattern is a repeatable loop: gather direct customer evidence, synthesize it in empathy maps or journey maps, run structured role-reversal critiques on a feature or message, validate with usability inspection and user testing, then connect findings to a small balanced scorecard of UX metrics and business outcomes. Google’s HEART framework, Brooke’s SUS, task-completion measures, and DORA-style delivery metrics are complementary here: together they help teams answer whether a feature is useful, usable, valuable, and operationally healthy. citeturn20view0turn33view1turn24view0turn23view0turn21view0turn22view0
+ 
 
 The practical implication is straightforward: a software company should institutionalize empathy as a **review discipline**. Before release, teams should ask, from the viewpoint of a real user or buyer, “Would I understand what this is for, find it, trust it, complete the task, and feel the value was worth the effort?” After release, teams should ask, “Did the evidence improve activation, task success, retention, support burden, or conversion?” That combination of role-reversal and measurement is the most defensible way to make empathy evidence-based rather than rhetorical. citeturn20view0turn24view0turn23view0turn26view0turn25view0turn27view0