mirror of https://github.com/abpframework/abp.git
maliming
2 months ago
95 changed files with 1599 additions and 54 deletions
|
After Width: | Height: | Size: 379 KiB |
|
After Width: | Height: | Size: 244 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 9.1 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 45 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 181 KiB |
@ -0,0 +1,394 @@ |
|||
# Building a Vendor Onboarding Workflow with ABP Low-Code |
|||
|
|||
Vendor onboarding usually starts with a few familiar steps. |
|||
|
|||
A company sends its details, someone checks the documents, another person reviews the score, and the team either approves the vendor or asks for more information. After a while, the process turns into a mix of spreadsheets, uploaded files, status notes, and "who is waiting on this one?" messages. |
|||
|
|||
In this article, we'll build that workflow with the [Low-Code System](https://abp.io/docs/latest/low-code/index). We'll model the data in the [Low-Code Designer](https://abp.io/docs/latest/low-code/designer), let the [React runtime](https://abp.io/docs/latest/low-code/react-runtime) render the page, and then add one [custom endpoint](https://abp.io/docs/latest/low-code/custom-endpoints) for a summary that does not belong to normal CRUD. |
|||
|
|||
The example is an internal operations page where a team receives vendor applications, reviews compliance documents, tracks deadlines, and follows rejected or priority vendors from one place. |
|||
|
|||
That is a good place to try ABP Low-Code, because the first version of the workflow is mostly data, screens, validation rules, and a few process-specific actions. You do not need to hand-write a React page only to list vendor applications, upload a compliance document, or show a rejection reason when the status is rejected. |
|||
|
|||
We will start from an already running ABP React + EF Core application with Low-Code enabled, so the article can stay focused on the Admin Console, the Designer, and the runtime flow. |
|||
|
|||
## What We Are Building |
|||
|
|||
The workflow has one main record: `VendorApplication`. |
|||
|
|||
A reviewer should be able to: |
|||
|
|||
- Create a vendor application with company and contact details. |
|||
- Track whether the vendor is `Submitted`, `InReview`, `Approved`, or `Rejected`. |
|||
- Set the requested date and approval deadline. |
|||
- Mark priority vendors. |
|||
- Assign a category such as `Software`, `Services`, or `Hardware`. |
|||
- Upload a logo and a compliance document. |
|||
- Fill in a rejection reason only when the application is rejected. |
|||
- Filter the generated grid by status, requested date, priority, and category. |
|||
- Call a summary endpoint that returns counts for dashboard-like use. |
|||
|
|||
We'll also touch two extra pieces around that main record. `VendorReviewTemplate` comes from C# so you can see how code-defined metadata appears in the Designer. Later, a `VendorEscalation` model is added while the Designer is switched to `Runtime JSON`. You could build the whole workflow with one entry point, but using these three entry points makes the hybrid model visible without turning the article into three separate implementations. |
|||
|
|||
## A Quick Note on How Low-Code Fits Together |
|||
|
|||
The Low-Code Designer is where you describe the model and the UI metadata. In this article we use four areas: |
|||
|
|||
- `Data` for enums and entities. |
|||
- `Pages` for the generated grid route. |
|||
- `Forms` for the create/edit form layout. |
|||
- `Actions` for the custom HTTP endpoint. |
|||
|
|||
The Designer stores metadata. The React runtime reads that metadata and renders the page at runtime. That is the important mental model: when we add a field to the entity, the field can become a grid column, a filter, a validation rule, or a form input depending on how we configure the metadata around it. |
|||
|
|||
There is also one database detail to keep in mind. Metadata that comes from C# code or from `Dev JSON` is source-controlled application metadata. When it introduces or changes a persisted entity, run the normal EF Core migration and database update flow before using the generated runtime page. In the validated demo for this article I used SQLite, so the migration updated the local SQLite database. `Runtime JSON` is different: it is authored at runtime, so I do not run a C# migration in that section. |
|||
|
|||
## Add a Code-Defined Review Template |
|||
|
|||
Let's start with one model that does not come from the Designer. |
|||
|
|||
In this workflow, vendor reviewers can use review templates. The template itself is not the center of the workflow, so I kept it focused on the review rules: |
|||
|
|||
```csharp |
|||
[DynamicEnum] |
|||
public enum VendorReviewTemplateType |
|||
{ |
|||
Standard = 0, |
|||
Security = 1, |
|||
Finance = 2 |
|||
} |
|||
|
|||
[DynamicEntity(DefaultDisplayPropertyName = nameof(Name))] |
|||
[DynamicEntityUI(DisplayName = "Vendor Review Templates")] |
|||
public class VendorReviewTemplate : DynamicEntityBase |
|||
{ |
|||
[Required] |
|||
[StringLength(128)] |
|||
[DynamicPropertyUnique] |
|||
public string Name { get; set; } |
|||
|
|||
public VendorReviewTemplateType TemplateType { get; set; } |
|||
public int MinimumComplianceScore { get; set; } |
|||
public bool RequiresDocumentReview { get; set; } |
|||
public string? Notes { get; set; } |
|||
} |
|||
``` |
|||
|
|||
Then include the entity in your EF Core DbContext. This is the part that makes the migration create a real backing table for the code-defined model: |
|||
|
|||
```csharp |
|||
public DbSet<VendorReviewTemplate> VendorReviewTemplates { get; set; } |
|||
|
|||
builder.Entity<VendorReviewTemplate>(b => |
|||
{ |
|||
b.ToTable( |
|||
VendorOnboardingLowCodeConsts.DbTablePrefix + "VendorReviewTemplates", |
|||
VendorOnboardingLowCodeConsts.DbSchema |
|||
); |
|||
b.ConfigureByConvention(); |
|||
b.Property(x => x.Name).IsRequired().HasMaxLength(128); |
|||
b.Property(x => x.Notes).HasMaxLength(512); |
|||
b.HasIndex(x => x.Name).IsUnique(); |
|||
}); |
|||
``` |
|||
|
|||
Because this model is defined in C#, treat it like the rest of your application schema changes: add the entity, add the DbSet/mapping, create/apply the EF Core migration, and then start the application. |
|||
|
|||
After the app starts, open **Admin Console > Low-Code Designer > Data**. The model is visible there, but it is read-only because it was defined in code. |
|||
|
|||
 |
|||
|
|||
Open the **Properties** tab and you can see the fields that came from the C# class. They are available to the Low-Code System, but the Designer marks them as code-owned. |
|||
|
|||
 |
|||
|
|||
That is useful in real projects. Some metadata can be shipped with the application, while the rest of the workflow can still be designed through the Admin Console. |
|||
|
|||
## Create the Vendor Enums |
|||
|
|||
Now move to the part we actually build in the Designer. |
|||
|
|||
The animation below shows the Designer path in one pass. The next sections slow it down and explain the enum, entity, page, and form steps. |
|||
|
|||
 |
|||
|
|||
Open `Data > Enums` and create the status enum: |
|||
|
|||
```text |
|||
VendorApplicationStatus |
|||
Submitted |
|||
InReview |
|||
Approved |
|||
Rejected |
|||
``` |
|||
|
|||
Before saving, the enum modal should contain the name and the four values: |
|||
|
|||
 |
|||
|
|||
Then create the category enum: |
|||
|
|||
```text |
|||
VendorCategory |
|||
Software |
|||
Services |
|||
Hardware |
|||
``` |
|||
|
|||
The order of the status values matters for the custom endpoint later, because the script checks the enum values by their numeric indexes. In this example `Submitted` is `0`, `Approved` is `2`, and `Rejected` is `3`. |
|||
|
|||
After saving, the enum detail page shows the numeric values that the runtime and scripts will use: |
|||
|
|||
 |
|||
|
|||
## Create the VendorApplication Entity |
|||
|
|||
Go to `Data > Entities` and create `VendorApplication`. |
|||
|
|||
This is the model that drives the rest of the article. Add these fields: |
|||
|
|||
| Field | Type | Configuration | |
|||
| --- | --- | --- | |
|||
| `CompanyName` | `String` | Required and unique | |
|||
| `ContactEmail` | `String` | Required, email validation | |
|||
| `Status` | `Enum` | `VendorApplicationStatus` | |
|||
| `RequestedOn` | `Date` | Application date | |
|||
| `ApprovalDeadline` | `Date` | Review deadline | |
|||
| `IsPriority` | `Boolean` | Priority flag | |
|||
| `Category` | `Enum` | `VendorCategory` | |
|||
| `ComplianceScore` | `Int` | Review score | |
|||
| `Logo` | `Image` | Logo upload | |
|||
| `ComplianceDocument` | `File` | Document upload | |
|||
| `RejectionReason` | `String` | Optional | |
|||
|
|||
 |
|||
|
|||
The **Properties** tab is where the entity becomes more than a name. The table shows the field types, enum bindings, and source layer. Scroll down and the upload-related fields are visible with their `Image` and `File` types: |
|||
|
|||
 |
|||
|
|||
There is no React code yet, but we already have a lot of behavior described: required fields, uniqueness, email validation, enum fields, upload fields, and the data shape that the runtime will use. |
|||
|
|||
The `Image` and `File` types are worth calling out. They are not plain strings with a path. In the generated form they become upload controls, which is exactly what we need for vendor logos and compliance documents. |
|||
|
|||
Since `VendorApplication` is authored in the `Dev JSON` layer, it also belongs to the source-controlled model. After saving the entity metadata, create/apply the EF Core migration before you open the generated page in the runtime. This is the step that creates the backing table for the low-code entity in the database. |
|||
|
|||
## Generate a Grid Page |
|||
|
|||
The reviewers need a page where they can work with applications, so go to `Pages` and create a `dataGrid` page named `vendor-onboarding`. |
|||
|
|||
Bind it to `VendorApplication`. |
|||
|
|||
Before saving the page, the modal connects the route name, title, icon, and entity: |
|||
|
|||
 |
|||
|
|||
After the page is created, set `RequestedOn` as the default sort field, keep it descending, adjust the icon if you want, and assign `vendor-application-form` as the create/edit form: |
|||
|
|||
 |
|||
|
|||
For the review workflow, keep the configured columns focused on the fields reviewers use most: |
|||
|
|||
- Company name |
|||
- Status |
|||
- Requested date |
|||
- Priority |
|||
- Category |
|||
|
|||
Then configure the filters you want reviewers to use most often. In this workflow, the important filters are company, status, requested date, priority, and category. Depending on the runtime defaults, the generated grid may still expose additional fields such as contact email; the workflow is still driven by the focused page metadata above. |
|||
|
|||
Once the page is saved, the React runtime can resolve the route from the page metadata. The grid is generated from the entity and page configuration rather than from a hand-written React component. |
|||
|
|||
## Build the Create/Edit Form |
|||
|
|||
A grid is not enough. We also need a form that feels like the workflow. |
|||
|
|||
Go to `Forms` and create `vendor-application-form` for `VendorApplication`. Split the fields into three tabs: |
|||
|
|||
 |
|||
|
|||
- **Company**: `CompanyName`, `ContactEmail`, `Category`, `IsPriority` |
|||
- **Review**: `Status`, `RequestedOn`, `ApprovalDeadline`, `ComplianceScore`, `RejectionReason` |
|||
- **Documents**: `Logo`, `ComplianceDocument` |
|||
|
|||
Now add the conditional behavior for `RejectionReason`. In this demo I used two complementary rules: one rule shows the field when `Status = Rejected`, and the other hides it for non-rejected statuses. |
|||
|
|||
 |
|||
|
|||
This is one of the places where Low-Code becomes more than "generate a CRUD page". The runtime does more than render a static form; it evaluates the rule while the user edits the record. |
|||
|
|||
## Apply the Migration Before Opening the Runtime |
|||
|
|||
Before opening the generated page, apply the database migration for the `Dev JSON` changes. We used `Dev JSON` for `VendorApplication`, so the Designer wrote source-controlled descriptor files under `_Dynamic`. The entity shape is now part of the application model, and the database needs the matching backing table before the React runtime can save records. |
|||
|
|||
That is why `Dev JSON` is a good fit during development: the metadata files and the EF Core migration can be reviewed, committed, and reproduced in another environment. If the same entity had been created in the `Runtime JSON` layer, you would not create a C# migration for that runtime edit; the metadata change would be stored in the database instead. In practice, use `Dev JSON` for development-time, source-controlled changes, and use `Runtime JSON` when you want production-time changes to be managed from the Admin Console and persisted in the database. |
|||
|
|||
## Try It in the React Runtime |
|||
|
|||
Open the generated `vendor-onboarding` page in the React runtime and create a vendor application. |
|||
|
|||
On the `Documents` tab, the `Logo` and `ComplianceDocument` fields are rendered as upload fields: |
|||
|
|||
 |
|||
|
|||
Now edit a record and change the status to `Rejected`. The `RejectionReason` field becomes available on the `Review` tab: |
|||
|
|||
 |
|||
|
|||
After saving a few records, use the generated filters to narrow the list to rejected vendors. Depending on the runtime configuration, the filter panel can expose more fields than the small set you configured for the workflow; here we only use the `Status = Rejected` filter: |
|||
|
|||
 |
|||
|
|||
The short animation below gives a quick pass through the same runtime states: upload fields, the conditional rejection reason, and the filtered grid. |
|||
|
|||
 |
|||
|
|||
At this point we have a working page, form, validation, uploads, and filters. The important part is that all of it came from the metadata we configured in the Designer. |
|||
|
|||
## Add a Custom Summary Endpoint |
|||
|
|||
Generated CRUD is enough for day-to-day record editing, but teams often need one operation that is specific to their process. |
|||
|
|||
For vendor onboarding, a summary endpoint is a good example: |
|||
|
|||
```text |
|||
GET /api/custom/vendor-onboarding/summary |
|||
``` |
|||
|
|||
In the Designer, open `Actions` and create a custom HTTP action with that route. The script can use the [Scripting API](https://abp.io/docs/latest/low-code/scripting-api) to query the same `VendorApplication` data that the generated grid uses. |
|||
|
|||
 |
|||
|
|||
Here is the script used in the demo: |
|||
|
|||
```js |
|||
var entityName = 'Acme.VendorOnboardingLowCode.Procurement.VendorApplication'; |
|||
var vendorQuery = await db.query(entityName); |
|||
var totalVendors = await db.count(entityName); |
|||
var submittedVendors = await vendorQuery.where(x => x.Status === 0).count(); |
|||
var approvedVendors = await vendorQuery.where(x => x.Status === 2).count(); |
|||
var today = query.today || new Date().toISOString().slice(0, 10); |
|||
var overdueReviews = await vendorQuery |
|||
.where(x => x.ApprovalDeadline != null && x.ApprovalDeadline < today && x.Status !== 2) |
|||
.count(); |
|||
|
|||
return ok({ |
|||
totalVendors: totalVendors, |
|||
submittedVendors: submittedVendors, |
|||
approvedVendors: approvedVendors, |
|||
overdueReviews: overdueReviews, |
|||
evaluatedOn: today |
|||
}); |
|||
``` |
|||
|
|||
Use the entity name shown in your Designer. In the screenshots, it is `Acme.VendorOnboardingLowCode.Procurement.VendorApplication`. |
|||
|
|||
When the endpoint runs, it returns the current counts from the low-code records: |
|||
|
|||
 |
|||
|
|||
That is the bridge I like here. The page and form stay metadata-driven, but the process-specific summary is a short script exposed as a custom endpoint. |
|||
|
|||
## Add One Runtime Model |
|||
|
|||
Now switch the Designer layer to `Runtime JSON` and add one more entity: `VendorEscalation`. |
|||
|
|||
This model represents the items that need extra attention. It could have been created in the same place as `VendorApplication`; I am adding it here only to show that runtime-authored metadata participates in the same Low-Code System. |
|||
|
|||
Unlike the code and `Dev JSON` examples above, this runtime-authored model is not part of the source-controlled migration flow in this walkthrough. |
|||
|
|||
The create modal is the same Designer experience, but the selected layer is now `Runtime JSON`: |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
Create a data grid page for it and open it in the React runtime: |
|||
|
|||
 |
|||
|
|||
From the user's point of view, it behaves like the first generated page. From the metadata point of view, we have now seen code-defined metadata, Designer-authored metadata, and runtime-authored metadata in the same application. |
|||
|
|||
## Read the Same Data from ABP Code |
|||
|
|||
The last bridge is application code. |
|||
|
|||
Sometimes the generated page is not the only consumer. You may want a typed application service, a scheduled job, or another API to read the same low-code records. The code below shows the idea by returning a backlog summary: |
|||
|
|||
```csharp |
|||
private readonly IRepository<DynamicEntity, Guid> _vendorApplicationRepository; |
|||
private readonly IAsyncQueryableExecuter _queryableExecuter; |
|||
|
|||
public async Task<VendorBacklogDto> GetBacklogAsync() |
|||
{ |
|||
var entityDescriptor = DynamicModelManager.Instance.Find( |
|||
"Acme.VendorOnboardingLowCode.Procurement.VendorApplication" |
|||
); |
|||
|
|||
if (entityDescriptor == null) |
|||
{ |
|||
throw new UserFriendlyException("VendorApplication model was not found."); |
|||
} |
|||
|
|||
var query = await _vendorApplicationRepository |
|||
.SetEntityName(entityDescriptor.Name) |
|||
.GetQueryableAsync(); |
|||
var today = DateOnly.FromDateTime(Clock.Now); |
|||
var priorityQuery = query.Where(vendor => |
|||
vendor.Data["IsPriority"] != null && |
|||
(bool?)vendor.Data["IsPriority"] == true); |
|||
|
|||
var nextPriorityVendor = await _queryableExecuter.FirstOrDefaultAsync( |
|||
priorityQuery.OrderByDescending(vendor => |
|||
(DateOnly?)vendor.Data["RequestedOn"])); |
|||
|
|||
return new VendorBacklogDto |
|||
{ |
|||
TotalVendors = checked((int)await _queryableExecuter.LongCountAsync(query)), |
|||
PriorityVendors = checked((int)await _queryableExecuter.LongCountAsync(priorityQuery)), |
|||
RejectedVendors = checked((int)await _queryableExecuter.LongCountAsync( |
|||
query.Where(vendor => |
|||
vendor.Data["Status"] != null && |
|||
(int?)vendor.Data["Status"] == 3))), |
|||
OverdueReviews = checked((int)await _queryableExecuter.LongCountAsync( |
|||
query.Where(vendor => |
|||
vendor.Data["ApprovalDeadline"] != null && |
|||
(DateOnly?)vendor.Data["ApprovalDeadline"] < today && |
|||
vendor.Data["Status"] != null && |
|||
(int?)vendor.Data["Status"] != 2))), |
|||
NextPriorityVendor = nextPriorityVendor?.GetData<string>("CompanyName") |
|||
}; |
|||
} |
|||
``` |
|||
|
|||
 |
|||
|
|||
The important detail is that the aggregate operations stay on `IQueryable`; the code does not load every vendor into memory just to count them. This is not a replacement for the generated page. It is the other direction: use the generated page for the admin experience, then read the same records from normal ABP code when another part of the application needs them. |
|||
|
|||
## Going Further |
|||
|
|||
The workflow we built is intentionally focused, but the same shape can grow in a few directions: |
|||
|
|||
- Add permissions around the generated pages and custom endpoint. |
|||
- Add more form rules for review-specific fields. |
|||
- Add an approval notification after a vendor is accepted. |
|||
- Add a scheduled job that checks overdue applications. |
|||
- Build a dashboard widget on top of the summary endpoint. |
|||
|
|||
The main pattern stays the same: model the data in the Low-Code Designer, let the React runtime render the operational page, and add code or scripting only for the parts that are specific to your business process. |
|||
|
|||
## Conclusion |
|||
|
|||
ABP Low-Code is useful when the first version of a business workflow is mostly metadata: entities, fields, filters, forms, validation, uploads, and a few custom actions. |
|||
|
|||
In this vendor onboarding example, the `VendorApplication` model gave us a generated grid and form, the runtime handled upload fields and conditional UI, and a custom endpoint added the summary that CRUD would not provide by itself. We also saw that low-code metadata can come from the Designer, from runtime JSON, or from C# code when you need that bridge. |
|||
|
|||
That is the part worth remembering: you can start with a working admin experience quickly, then extend the workflow where the generated behavior stops being enough. |
|||
|
|||
### Further Reading |
|||
|
|||
- [Low-Code System Overview](https://abp.io/docs/latest/low-code/index) |
|||
- [Low-Code Designer](https://abp.io/docs/latest/low-code/designer) |
|||
- [React Runtime](https://abp.io/docs/latest/low-code/react-runtime) |
|||
- [Custom Endpoints](https://abp.io/docs/latest/low-code/custom-endpoints) |
|||
- [Scripting API](https://abp.io/docs/latest/low-code/scripting-api) |
|||
@ -0,0 +1 @@ |
|||
Build a vendor onboarding workflow with ABP Low-Code: model vendor applications in the Designer, let the React runtime render the grid and form, then add a custom endpoint and a typed ABP code bridge for process-level counts. |
|||
|
After Width: | Height: | Size: 252 KiB |
|
After Width: | Height: | Size: 974 KiB |
|
After Width: | Height: | Size: 165 KiB |
|
After Width: | Height: | Size: 12 MiB |
|
After Width: | Height: | Size: 403 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 33 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 104 KiB |
@ -0,0 +1,225 @@ |
|||
# Introducing ABP Low-Code: Build Real ABP Apps in Minutes |
|||
|
|||
**Create runtime-managed pages, generated React screens, code-first C# entities, and Script API extensions without leaving the ABP application model.** |
|||
|
|||
 |
|||
|
|||
> **Want to try the same path?** Start from ABP Studio, enable the Low-Code runtime and designer, define pages in the Admin Console, and see them resolve inside the running ABP app. |
|||
|
|||
--- |
|||
|
|||
## ABP Low-Code at a glance |
|||
|
|||
| Runtime authoring | Generated screens | ABP-native extensibility | One application model | |
|||
| :---: | :---: | :---: | :---: | |
|||
| Define and update pages in the Admin Console | Grid, Form, Calendar, Kanban, Gallery, Dashboard | Code-first entities, Script API actions, and C# query paths | Runtime metadata, generated UI, and application code stay together | |
|||
|
|||
--- |
|||
|
|||
## Built into the ABP Platform |
|||
|
|||
Low-code is most useful when speed does not create a separate stack to maintain later. |
|||
|
|||
That is where many low-code products start to strain. They move quickly at the beginning, then force a second implementation track when the app needs permissions, auditability, custom logic, or tighter integration with existing application code. |
|||
|
|||
ABP Low-Code takes a different path. It runs **inside the ABP Platform**, so runtime-managed pages are part of an application foundation that already includes identity, permissions, audit logging, APIs, and code-level extensibility. |
|||
|
|||
--- |
|||
|
|||
## Edit at runtime. See it in the app. |
|||
|
|||
In the Low-Code Designer, you update a runtime-managed page. A few seconds later, the same application surface is visible in the live app. No rebuild loop. No parallel front-end implementation. No "we will wire it later" gap between authoring and runtime. |
|||
|
|||
ABP Low-Code shortens the cycle from model change to running screen while keeping the output grounded in the same ABP application. |
|||
|
|||
 |
|||
|
|||
> **What this shows:** authoring and runtime are connected. Pages are defined in the designer and resolved in the running application. |
|||
|
|||
--- |
|||
|
|||
## CRUD is table stakes |
|||
|
|||
If low-code only saves you from drawing a table and a form, it is not enough. Business applications need richer operational surfaces. |
|||
|
|||
In the generated app, the `Events` screen ships with search, actions, filters, and form-driven editing. The form structure already understands tabs, relations, validation, and business-shaped input instead of leaving you with a blank shell to finish by hand. |
|||
|
|||
 |
|||
|
|||
The point is not just generated CRUD. It is generated CRUD that already looks like the operational screens teams maintain in real applications. |
|||
|
|||
--- |
|||
|
|||
## One model, multiple operational screens |
|||
|
|||
Business users do not think in one view. Operators want a calendar for scheduling, a kanban board for workflow, a grid for bulk operations, a gallery when media matters, and a dashboard when they need the state of the business at a glance. |
|||
|
|||
ABP Low-Code keeps those surfaces attached to the same underlying model. The same `Session` model can appear as a **calendar** for planning and a **kanban pipeline** for operational flow. The same generated app can also include a **speaker gallery** and an **overview dashboard** for metrics. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
This is where ABP Low-Code starts to feel less like a form generator and more like a runtime application layer: one model, many working screens, no second implementation track for each view type. |
|||
|
|||
--- |
|||
|
|||
## When low-code needs code |
|||
|
|||
The real differentiator is not that ABP Low-Code can go fast. It is that **speed does not require isolation from the application foundation**. |
|||
|
|||
When generated CRUD is not enough, you extend the same app instead of throwing the low-code layer away. |
|||
|
|||
ABP Low-Code exposes a server-side **Script API** inside the same application model. That scripting surface can back: |
|||
|
|||
- **Custom endpoints** when the UI needs an API-shaped response. |
|||
- **Interceptors** when create or update commands need validation or mutation. |
|||
- **Event handlers** when logic should react to runtime events. |
|||
- **Background jobs** when work should continue asynchronously. |
|||
- **Background workers** when operational logic should run on a schedule. |
|||
|
|||
In this article, the visible proof happens to be `GET /api/custom/eventflow/highlights`. The GIF shows an endpoint because it is the easiest proof surface to read. But the broader point is that endpoints are only one consumer of the same low-code scripting layer. |
|||
|
|||
That hybrid model matters in both directions: |
|||
|
|||
- **Code-first ABP entities can be surfaced in low-code flows and runtime pages.** |
|||
- **Low-code-managed data and screens stay reachable from Script API actions, application services, repository queries, and custom endpoints.** |
|||
- **Teams do not lose architectural control just because they gained a faster authoring layer.** |
|||
|
|||
 |
|||
|
|||
The actual capability is the shared ABP application model behind it: script when runtime logic is enough, C# when typed application services and repository queries are the better fit. |
|||
|
|||
This is the difference between "low-code as a shortcut" and "low-code as part of your application platform." |
|||
|
|||
--- |
|||
|
|||
## From code-first entity to generated page |
|||
|
|||
The first direction is code-first to low-code. A **code-first** `SponsorActivation` entity checked into the ASP.NET Core project can still become a working runtime page without forking into a separate low-code-only model. |
|||
|
|||
The code-first entity carries the same metadata that ABP Low-Code uses to generate the page: |
|||
|
|||
```csharp |
|||
[DynamicEntity(DefaultDisplayPropertyName = nameof(CompanyName))] |
|||
[DynamicEntityUI("Sponsor Activations")] |
|||
[DynamicEntityAttachments("application/pdf", "image/*", MaxFileCount = 4)] |
|||
public class SponsorActivation : DynamicEntityBase |
|||
{ |
|||
[Required] |
|||
[DynamicPropertyUI(DisplayName = "Sponsor")] |
|||
public string CompanyName { get; private set; } |
|||
|
|||
[Required] |
|||
[EmailAddress] |
|||
[DynamicPropertyUI(DisplayName = "Contact Email")] |
|||
public string ContactEmail { get; private set; } |
|||
|
|||
public SponsorActivationStatus Status { get; set; } |
|||
|
|||
[DynamicForeignKey("EventFlow.Events.Event", "Title")] |
|||
public Guid? EventId { get; set; } |
|||
|
|||
[DynamicForeignKey("Volo.Abp.Identity.IdentityUser", nameof(IdentityUser.UserName), ForeignAccess.View)] |
|||
public Guid? OwnerUserId { get; set; } |
|||
|
|||
[DynamicPropertyType(EntityPropertyType.Money)] |
|||
public decimal ActivationBudget { get; set; } |
|||
|
|||
[DynamicPropertyImageOptions("image/png", "image/jpeg")] |
|||
public string? BrandLogo { get; set; } |
|||
|
|||
[DynamicPropertyFileOptions("application/pdf", ".pptx", ".docx")] |
|||
public string? ActivationBrief { get; set; } |
|||
} |
|||
``` |
|||
|
|||
That class lives as normal C# source, gets migrated like the rest of the application, and is seeded with real records so the runtime page does not open as an empty shell. |
|||
|
|||
Inside the designer, selecting the `SponsorActivation` entity auto-generates the page identity, binds the grid to the entity, and lands on a real runtime route at `/dynamic/sponsor-activation`. The generated surface includes sponsor, email, event lookup, owner lookup, budget, image, and file fields directly from the C# model. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
That is the distinction that matters: code-first ABP entities can move through low-code without becoming throwaway artifacts, and low-code-generated surfaces remain part of the same application story. |
|||
|
|||
--- |
|||
|
|||
## Low-code data stays reachable from C# |
|||
|
|||
The bridge also works in the other direction. A normal ABP application service can query a low-code model through `IRepository<DynamicEntity, Guid>`, apply real filters, and combine that result with code-first aggregates. |
|||
|
|||
The service behind the endpoint in the previous section looks like this: |
|||
|
|||
```csharp |
|||
public async Task<EventFlowLowCodeProofDto> GetHybridSummaryAsync() |
|||
{ |
|||
var liveSessionQuery = (await _dynamicEntityRepository |
|||
.SetEntityName("EventFlow.Events.Session") |
|||
.GetQueryableAsync()) |
|||
.Where("int(it[\"Status\"]) == @0", 2); |
|||
|
|||
var publicSessionQuery = liveSessionQuery |
|||
.Where("bool(it[\"IsPublic\"]) == @0", true); |
|||
|
|||
var sponsorQuery = (await _sponsorActivationRepository.GetQueryableAsync()) |
|||
.Where(activation => |
|||
activation.Status == SponsorActivationStatus.Approved || |
|||
activation.Status == SponsorActivationStatus.Live); |
|||
|
|||
var liveSessionCount = await AsyncExecuter.CountAsync(liveSessionQuery); |
|||
var publicSessionCount = await AsyncExecuter.CountAsync(publicSessionQuery); |
|||
var activeSponsorActivationCount = await AsyncExecuter.CountAsync(sponsorQuery); |
|||
|
|||
return new EventFlowLowCodeProofDto |
|||
{ |
|||
LiveSessionCount = liveSessionCount, |
|||
PublicSessionCount = publicSessionCount, |
|||
ActiveSponsorActivationCount = activeSponsorActivationCount |
|||
}; |
|||
} |
|||
``` |
|||
|
|||
Here, low-code-managed `Session` rows are filtered from C# with real `Where(...)` clauses, then combined with the typed `SponsorActivation` repository. The endpoint and dashboard are just one presentation surface for that shared ABP query path. |
|||
|
|||
That is the ABP difference: low-code data stays reachable from code, and code-first entities stay reachable from low-code. |
|||
|
|||
--- |
|||
|
|||
## Why ABP Low-Code matters |
|||
|
|||
The value is not novelty. It is a faster way to build real business applications without separating speed from the application foundation. |
|||
|
|||
- **Speed without replatforming.** Runtime-managed screens reduce delivery time without moving the team onto a separate application stack. |
|||
- **Governance without friction.** Permissions, identity, auditability, and ABP platform foundations stay part of the story from day one. |
|||
- **Extensibility without rewrite pressure.** When custom behavior shows up, the same application can be extended instead of replacing the low-code output. |
|||
|
|||
That is the core ABP Low-Code promise: faster delivery, still inside the application model you can extend. |
|||
|
|||
--- |
|||
|
|||
## Try it yourself |
|||
|
|||
The public starting point for ABP Low-Code is **ABP Studio**. |
|||
|
|||
 |
|||
|
|||
1. Open **ABP Studio** and create a new solution. |
|||
2. In the solution wizard, enable **Include Low-Code runtime and designer**. |
|||
3. Complete the wizard, then run the generated backend and React UI from the solution. |
|||
4. Sign in with the administrator account created for that solution. |
|||
5. Open **Admin Console** to define runtime-managed entities, forms, pages, permissions, endpoints, and script actions. |
|||
6. Switch to the application side to see those changes resolve live in the running app. |
|||
|
|||
--- |
|||
|
|||
## Further reading |
|||
|
|||
- [ABP Low-Code Designer Documentation](https://abp.io/docs/latest/low-code/designer) |
|||
- [ABP Low-Code Configuration & Fluent API](https://abp.io/docs/latest/low-code/fluent-api) |
|||
- [ABP Low-Code Scripting API](https://abp.io/docs/latest/low-code/scripting-api) |
|||
- [ABP Low-Code Script Actions](https://abp.io/docs/latest/low-code/script-actions) |
|||
- [ABP Low-Code Interceptors](https://abp.io/docs/latest/low-code/interceptors) |
|||
- [ABP Studio Documentation](https://abp.io/docs/latest/studio) |
|||
- [Get Started with ABP: Creating a Layered Web Application](https://abp.io/docs/latest/get-started/layered-web-application) |
|||
@ -0,0 +1 @@ |
|||
Discover how ABP Low-Code blends runtime page building with code-first entities, C# queries, and extensible application logic. |
|||
@ -0,0 +1,221 @@ |
|||
# Empathy in the Workplace: The hidden skill behind a successful product |
|||
|
|||
## 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. citeturn34view0turn29view1turn29view2turn28view3turn7search0turn28view0 |
|||
|
|||
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. citeturn34view0turn34view1 |
|||
|
|||
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. citeturn20view0turn33view1turn24view0turn23view0turn21view0turn22view0 |
|||
|
|||
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. citeturn20view0turn24view0turn23view0turn26view0turn25view0turn27view0 |
|||
|
|||
The table below condenses the report’s practical recommendations into an operating model for a mid-size software company. It synthesizes ISO human-centered-design principles, Google’s HEART and DORA guidance, NNGroup methods, Atlassian workshop practices, and company examples from IBM, Intuit, Microsoft, and GitHub. citeturn34view0turn20view0turn21view0turn26view0turn31view0turn31view4turn17view0turn31view2 |
|||
|
|||
| Operating area | Minimum recommendation | Why it matters | |
|||
|---|---|---| |
|||
| Product and UX | Run a structured empathy review on every material feature before release | Converts assumptions into observable critique, especially for learnability and value | |
|||
| Engineering | Add cognitive walkthroughs for new workflows and dogfooding with caution | Helps expose first-time-user friction, while recognizing employees are not the same as customers | |
|||
| Sales and marketing | Review landing pages, pricing pages, demos, emails, and onboarding copy from the buyer’s perspective | Brings empathy into acquisition and expectation-setting, not only UI | |
|||
| Measurement | Track one small balanced scorecard: task success, time or effort, perceived usability, adoption or activation, retention, and one business KPI | Prevents “feel-good empathy” without outcome accountability | |
|||
| Culture and process | Involve support, research, sales, and engineering in cross-functional reviews | Broadens perspective and reduces local optimization | |
|||
| Leadership | Protect psychological safety and blameless critique | Teams cannot surface customer pain honestly if they fear blame | |
|||
|
|||
## What Empathy Means in a Software Company |
|||
|
|||
Empathy is not one thing. Across psychology and design research, it is commonly treated as a multidimensional construct with at least two major components. **Affective empathy** refers to sharing or resonating with another person’s feeling state. **Cognitive empathy** refers to understanding another person’s viewpoint, intentions, needs, or mental state. Related work argues that empathy and perspective-taking should be conceptually separated, because affect sharing and cognitive perspective-taking can diverge and recruit different processes. citeturn29view1turn29view2turn28view3 |
|||
|
|||
That distinction matters in the workplace. If a software company wants teams to evaluate features, copy, onboarding, pricing pages, or service flows by “putting themselves in the user’s shoes,” the most reliable mechanism is usually **structured perspective-taking** rather than pure emotional resonance. Perspective-taking is the cognitive process of adopting another person’s viewpoint to understand their preferences, values, and needs. Work on organizations and creativity shows that perspective-taking helps employees generate ideas that are not only novel but also useful to other people inside and outside the organization. Other research shows it can improve negotiation and creative problem solving, which is especially relevant for sales, pricing, and product tradeoff discussions. citeturn28view0turn6search8turn7search0 |
|||
|
|||
Affective empathy still matters, but it should be used carefully. It is often the source of prosocial concern and ethical motivation, yet it can also become empathic distress or bias attention toward vivid pain rather than representative evidence. Recent reviews distinguish empathic distress from compassion and caution that empathy can have downsides when it is unstructured or emotionally overloading. A good software-company practice is therefore to pair an affective prompt such as “What frustration or anxiety is this causing?” with cognitive prompts such as “What is the user trying to achieve, what cues do they see, and what would they reasonably infer at this step?” citeturn28view3turn29view2turn29view1 |
|||
|
|||
In a software firm, empathy should also be understood as **human-centered evaluation across the full customer experience**, not just interface design. ISO and NIST guidance emphasize that human-centered design addresses the whole user experience, is driven by user-centered evaluation, and requires multidisciplinary perspectives. That means developers should empathize with first-time and edge-case users, designers with user cognition and accessibility needs, sales with the buyer’s decision journey and implementation anxieties, and marketing with the customer’s information needs and language during awareness, evaluation, trial, and adoption. citeturn34view0turn34view1 |
|||
|
|||
The strongest practical interpretation for a software company is this: **empathy is the disciplined replacement of internal assumptions with testable, role-reversed understanding**. It is not “Would I like this?” It is “Would this specific user or buyer, in this context, with this knowledge and these constraints, understand the value, succeed at the task, and consider the result worth the cost?” That framing aligns with human-centered design, cognitive walkthroughs, and modern UX benchmarking. citeturn34view0turn25view0turn24view0 |
|||
|
|||
## Methods for Role Reversal and Feature Critique |
|||
|
|||
A software company does not need a single empathy method. It needs a **stack** of methods, each serving a different diagnostic purpose. Empathy maps are useful for capturing what users say, think, do, and feel, and for building shared understanding. Journey maps are better for exposing end-to-end friction, especially across acquisition, onboarding, support, and renewal moments. Cognitive walkthroughs are ideal when the question is learnability for a new user. Heuristic evaluations are strong for systematic usability inspection. Role play is useful when the room lacks real users or sufficient perspective diversity. Dogfooding is valuable for surfacing operational issues rapidly, but it is incomplete because employees often have too much institutional knowledge and use the product differently than real customers. citeturn25view1turn26view0turn25view0turn27view0turn25view3turn35view1turn26view0 |
|||
|
|||
```mermaid |
|||
flowchart LR |
|||
A[Direct customer evidence<br/>interviews, support logs, analytics, follow-me-homes] --> B[Shared artifact<br/>empathy map or journey map] |
|||
B --> C[Role-reversal review<br/>developers, designers, sales, marketing] |
|||
C --> D[Structured critique<br/>cognitive walkthrough and heuristic evaluation] |
|||
D --> E[Prototype or revise] |
|||
E --> F[Validate with users and analytics] |
|||
F --> G[Decision<br/>ship, iterate, or stop] |
|||
G --> A |
|||
``` |
|||
|
|||
The workflow above reflects the common structure across ISO human-centered design, Intuit’s deep-customer-empathy methods, NNGroup workshop guidance, and Google’s Goals-Signals-Metrics logic: start from real evidence, externalize it, inspect from the other person’s perspective, then validate with measurement. citeturn34view0turn32view1turn32view0turn25view3turn20view0 |
|||
|
|||
The comparison below is a practical selection guide for software teams. |
|||
|
|||
| Method | Best question it answers | Best time to use | Main output | Strengths | Main limitation | Evidence base | |
|||
|---|---|---|---|---|---|---| |
|||
| Empathy map | What does one user or segment say, think, do, and feel? | Early discovery, after interviews, before ideation | Shared user-understanding artifact | Builds common ground, highlights knowledge gaps, helps prioritize needs | Can become speculative if not grounded in research | citeturn25view1 | |
|||
| Journey map | Where along the end-to-end journey do pain points, emotions, and drop-offs occur? | Acquisition, onboarding, support, renewal, cross-functional redesign | Current-state or future-state journey | Excellent for linking UX, marketing, analytics, and support data | Too-broad scope easily creates vague maps | citeturn26view0turn25view2 | |
|||
| Cognitive walkthrough | Will a new user know what to do, find the right action, and recognize progress? | New workflows, first-use experiences, major redesigns | Step-level learnability diagnosis | Strong for developers and PMs; inexpensive compared with full user testing | Best for learnability, not all UX questions | citeturn25view0 | |
|||
| Heuristic evaluation | Does the interface violate known usability principles? | Prototype stage, pre-test cleanup, complex UIs | Usability issue list by severity and principle | Fast, systematic, good for stretching research budget | Cannot replace testing with actual users | citeturn27view0turn27view1 | |
|||
| Role play | What changes when we force ourselves to speak from another perspective? | Workshops with insufficient diversity, early critique | Reframed assumptions and priorities | Useful for cross-functional teams; challenges bias and groupthink | Can feel artificial; needs a clear prompt and facilitation | citeturn25view3turn26view3 | |
|||
| Dogfooding | What breaks when we use the product in real work? | Continuous internal validation, prerelease builds | Operational issues, rough edges, adoption friction | Fast signal, good for operational empathy | Employees are not representative users; internal knowledge masks friction | citeturn35view0turn35view1turn26view0 | |
|||
| Follow-me-homes and contextual observation | What do people actually do, and why do they work around the system? | Discovery, onboarding research, problem reframing | Behavioral observations, pain points, surprises | Strong antidote to self-report bias and internal assumptions | Requires access to customers and disciplined observation | citeturn31view4turn32view1 | |
|||
|
|||
For a mixed technical and non-technical audience, the best recurring pattern is usually **contextual evidence → empathy map or journey map → role-reversal critique → cognitive walkthrough or heuristic review → user validation**. That sequence is especially well suited to feature critique because it moves from broad understanding to narrow diagnosis. It also gives different functions a clear role: support and sales provide frontline signals, marketing contributes message and expectation analysis, designers frame tasks and artifacts, and developers inspect learnability, error prevention, and operational feasibility. citeturn25view1turn26view0turn25view0turn27view0turn14search16 |
|||
|
|||
## What to Measure |
|||
|
|||
Empathy becomes actionable only when it is connected to measurement. Google’s HEART framework remains one of the most useful ways to structure product-level UX metrics because it covers **Happiness, Engagement, Adoption, Retention, and Task Success**, and pairs well with a **Goals–Signals–Metrics** process. The framework is intentionally selective: teams should not track every category mechanically, but should choose the mix that reflects the user and business problem at hand. Google later extended the same logic to developer experience, emphasizing that HEART helps teams choose what to measure rather than serving as a tool itself. citeturn20view0turn22view0 |
|||
|
|||
For software companies, the key analytical move is to connect **upstream** user-experience metrics to **downstream** business outcomes. NNGroup’s recent guidance draws the distinction clearly: upstream metrics tell you how the design performed, while downstream metrics indicate what changed in the business, such as support volume, conversion, or churn. That is exactly the bridge an empathy program needs. If a role-reversal review finds onboarding confusion, the resulting metrics should not stop at “users seemed confused”; they should also ask whether the redesign improved first-use completion, reduced support contacts, and improved retention or activation. citeturn23view0turn24view0 |
|||
|
|||
```mermaid |
|||
flowchart LR |
|||
A[Goal<br/>Help a first-time user understand and complete a feature] --> B[Signals<br/>finds feature, understands value, completes task, returns] |
|||
B --> C[UX metrics<br/>SEQ, SUS, task success, time on task, error rate] |
|||
C --> D[Behavioral metrics<br/>activation, adoption, retention] |
|||
D --> E[Business metrics<br/>conversion, support cost, churn, renewal] |
|||
``` |
|||
|
|||
The logic above follows Google’s Goals–Signals–Metrics model and NNGroup’s upstream-to-downstream bridge: a role-reversal review should define a concrete user goal, specify what success would look like from the user’s perspective, then connect that to metrics leadership already cares about. citeturn20view0turn23view0 |
|||
|
|||
The scorecard below is a rigorous but practical measurement model for feature critique. |
|||
|
|||
| Evaluation question | Recommended UX metrics | Related business KPIs | Why this pairing works | Source basis | |
|||
|---|---|---|---|---| |
|||
| Is the feature understandable and learnable? | Task-success rate, error rate, time on task, SEQ, cognitive-walkthrough issue count | Support contacts, implementation friction, trial-to-activation rate | Learnability failures usually surface first as failed tasks or slow tasks, then downstream as support burden or drop-off | citeturn25view0turn24view0turn23view0turn33view0 | |
|||
| Is the feature usable overall? | SUS, ease-of-use rating, heuristic-violation count | CSAT, churn risk, post-launch rework | SUS gives a global usability benchmark; heuristics catch preventable design problems before user testing | citeturn33view1turn33view0turn27view0turn27view1 | |
|||
| Is the feature useful and valuable? | Adoption, repeat usage, retention, feature-level engagement | Conversion, renewal, expansion, churn | A usable feature can still be low-value; adoption and retention test whether the feature solves a meaningful problem | citeturn20view0turn24view0turn23view0 | |
|||
| Is the onboarding or first-run experience working? | First-use completion, time to first value, SEQ, activation rate | Trial conversion, sales-cycle efficiency, support cost | Early friction has outsized consequences for activation and retention | citeturn24view0turn23view0turn26view0 | |
|||
| Is the feature accessible and inclusive? | Accessibility issue rate, task success for diverse users, error recovery, assistive-tech compatibility | Market reach, legal and compliance risk, satisfaction | Inclusive design reduces exclusion and often improves the experience more broadly | citeturn17view0turn18view0turn31view2 | |
|||
| Is the internal delivery system supporting empathy rather than undermining it? | Developer happiness, task success on internal platforms, platform adoption, incident recovery | DORA metrics, engineering throughput, change stability | Product empathy erodes if internal tools create enough friction that teams optimize for shipping over usefulness | citeturn22view0turn21view0turn4search19 | |
|||
|
|||
Where a company has internal developer platforms or design systems, it should use a second, lighter scorecard for internal users. Google Cloud’s guidance on applying HEART to developer experience is useful here: measure developer happiness, platform engagement, adoption, retention, and task success, then read those signals alongside DORA metrics such as deployment frequency, change lead time, change fail rate, failed-deployment recovery time, and deployment rework rate. DORA explicitly warns against weaponizing the metrics or comparing unlike teams; the goal is continuous improvement, not gamification. citeturn22view0turn21view0 |
|||
|
|||
A note on specific instruments: Brooke’s SUS remains a reliable low-cost ten-item questionnaire for overall perceived usability, and NNGroup recommends pairing short attitudinal questions such as the Single Ease Question with behavioral methods such as quantitative usability testing or analytics. That combination is usually better than relying on a single metric alone. citeturn33view1turn33view0turn24view0 |
|||
|
|||
## How to Embed Empathy in Process and Culture |
|||
|
|||
Empathy becomes durable when it is built into process gates, review rituals, and decision rights. Human-centered-design standards already imply the core process changes: understand the context of use, specify user requirements, produce design solutions, and evaluate them iteratively with multidisciplinary involvement. In practice, that means a software company should not wait for a late-stage usability test. It should create visible checkpoints where teams explicitly ask whether a feature, message, workflow, or campaign still makes sense from the user’s viewpoint. citeturn34view0turn34view1 |
|||
|
|||
A good operating model for a mid-size software company is to insert empathy into four moments. First, during discovery, use direct user evidence, support data, field observation, or follow-me-homes. Second, during definition, require an empathy artifact such as an empathy map, journey map, or problem statement linked to a real persona and task. Third, during critique, run a cross-functional walkthrough on the feature, landing page, or campaign with explicit role-reversal prompts. Fourth, after release, review a compact dashboard of UX and business metrics so that the organization learns whether its empathic assumptions were valid. citeturn32view1turn25view1turn26view0turn20view0turn23view0 |
|||
|
|||
The role-specific pattern below is a useful way to keep empathy from remaining “owned” by design alone. |
|||
|
|||
| Function | Role-reversal prompt | What this team should inspect | Typical evidence | |
|||
|---|---|---|---| |
|||
| Developers | “If I were a first-time user with no product knowledge, where would I fail or hesitate?” | Learnability, error prevention, defaults, performance blockers, operational friction, edge cases | Cognitive walkthrough, dogfooding, support tickets, logs, task-success metrics | |
|||
| Designers | “If I were this user in this context, would the interface match my language, expectations, and abilities?” | Information scent, interaction flow, accessibility, recovery from errors, emotional friction | User interviews, empathy maps, prototypes, usability tests, heuristic review | |
|||
| Sales | “If I were a buyer evaluating risk, value, and effort, what would block commitment?” | Demo flow, objection handling, implementation anxiety, trust signals, time to first value | Discovery calls, win-loss notes, onboarding friction, trial-conversion data | |
|||
| Marketing | “If I were the intended customer, would I recognize myself, understand the promise, and believe it?” | Positioning clarity, message-market fit, jargon, expectation setting, CTA friction | Journey maps, interview quotes, funnel analytics, campaign conversion and bounce patterns | |
|||
| Support and success | “Where does the product force preventable workarounds or confusion?” | Repeated pain points, failure demand, documentation gaps, friction across handoffs | Ticket themes, chat transcripts, escalation reasons, contact volume | |
|||
| Managers and leaders | “What in our process makes customer understanding difficult or optional?” | Decision latency, resourcing, review cadence, incentives, safety to surface bad news | Retrospectives, DORA trends, team surveys, roadmap churn | |
|||
|
|||
This model is consistent with IBM’s view that everyone on a team should focus on users first, Microsoft’s statement that inclusive design is for program managers, engineers, data scientists, designers, and others who create products, and Intuit’s expectation that every employee improves customers’ lives through deep customer empathy. citeturn31view1turn17view0turn31view4 |
|||
|
|||
Barriers are predictable, and the software-engineering literature increasingly names them directly. Recent studies and syntheses in software engineering report barriers such as toxic organizational culture, workplace bias, individualistic behavior, excessive technical focus, and insufficient sustained empathy in developer-user interactions. Those findings match longstanding UX workshop experience: empathy breaks down when teams are distant from users, when the room is insufficiently diverse, or when hierarchy suppresses candid critique. citeturn8search0turn8search8turn8search20turn26view3turn25view3 |
|||
|
|||
The mitigation pattern is therefore both social and procedural. |
|||
|
|||
| Barrier | What it looks like in a software company | Mitigation | Evidence base | |
|||
|---|---|---|---| |
|||
| Excessive technical focus | Shipping what is elegant to build rather than what is useful | Require a user task, persona, and success metric for each material feature | citeturn8search8turn20view0turn34view0 | |
|||
| Institutional-knowledge blindness | Internal experts assume customers know what the team knows | Use cognitive walkthroughs and external customer evidence; do not rely on dogfooding alone | citeturn25view0turn35view1turn26view0 | |
|||
| Low user contact | Teams build based on second-hand summaries | Bring real users into workshops when possible and expose teams to direct interviews or observation | citeturn14search16turn26view3turn32view1 | |
|||
| Weak cross-functional alignment | Product, engineering, sales, and support optimize different local goals | Use journey maps and empathy workshops to create shared language and visible tradeoffs | citeturn25view2turn26view2turn31view0 | |
|||
| Hierarchy and groupthink | Senior opinions dominate; uncomfortable feedback is softened | Facilitate workshops, allow anonymity where useful, and use role play when the room lacks diversity | citeturn25view3turn14search18turn26view3 | |
|||
| Fear of blame | Teams hide pain points or avoid early critique | Build psychological safety and blameless review practices | citeturn9search0turn31view3 | |
|||
| Emotional overload or empathy fatigue | Teams over-index on vivid anecdotes or burn out from constant affective labor | Emphasize perspective-taking, representative evidence, and bounded review rituals | citeturn7search0turn28view3turn0search12 | |
|||
|
|||
Psychological safety is especially important. Google’s research on team effectiveness identifies it as a foundational ingredient of high-performing teams, and GitHub’s on-call culture notes the need for safe, blameless spaces where engineers can learn from unfamiliar situations. Empathy reviews fail when people fear that surfacing customer pain will be interpreted as incompetence or delay. citeturn9search0turn31view3 |
|||
|
|||
## Evidence from Software Companies |
|||
|
|||
Public case evidence on empathy in software is useful, but it is uneven. The strongest public materials are often official process descriptions or commissioned studies rather than controlled field experiments. That means these cases are best used as **implementation patterns** and **directional evidence**, not as universal causal proofs. Still, taken together, they show a consistent pattern: software companies that embed empathy structurally tend to connect it to cross-functional alignment, earlier problem discovery, accessibility, and better customer experience. citeturn31view0turn31view1turn17view0turn31view2turn31view4 |
|||
|
|||
| Company | Public empathy practice | What the public evidence shows | What a mid-size software company can learn | Evidence quality | |
|||
|---|---|---|---|---| |
|||
| IBM | Enterprise Design Thinking | IBM frames design thinking as a user-first, scalable framework with principles of user outcomes, restless reinvention, and diverse empowered teams. IBM publicly reports faster time to market, ROI, and team-efficiency gains on its training page, clearly tying these claims to Forrester studies linked from the page. citeturn31view1turn31view0 | Give teams a common language, make user outcomes explicit, and keep design work tied to business delivery rather than isolated discovery | Moderate; official process description plus vendor-linked commissioned outcomes | |
|||
| Intuit | Design for Delight and Deep Customer Empathy | Intuit explicitly says every employee is expected to improve customers’ lives and defines D4D through Deep Customer Empathy, broad ideation, and rapid experimentation. Its method cards formalize follow-me-homes and empathy debriefs, including time boxes and prompts. citeturn31view4turn32view1turn32view0 | Treat empathy as an organizational capability, not only a design technique; make observation and debrief routine | Moderate; official methods are detailed, but quantified public outcomes are limited | |
|||
| Microsoft | Inclusive Design | Microsoft’s inclusive-design guidance centers on recognizing exclusion, learning from diversity, and solving for one then extending to many. It explicitly says the practice is for PMs, engineers, data scientists, designers, and others, and provides real-world examples like Copilot, Live Captions, Mesh Avatars, and reader tools. citeturn17view0turn18view0 | Broaden “user empathy” beyond the average user; use exclusion cases to improve mainstream experiences | Moderate; strong official practice guidance and product examples, lighter on causal metrics | |
|||
| GitHub | Accessibility shift and customer-centered operational ownership | GitHub’s public accessibility write-up emphasizes cultural shift, dedicated specialists, and permission for incremental progress. Its on-call culture case explains that ownership aligned with the code a team maintains was pursued to improve the customer experience and create a blameless, supportive culture. citeturn31view2turn31view3 | Empathy is not only front-end UX. Ownership, incident response, accessibility, and supportability are also empathy work | Moderate; strong operational narrative, limited quantified public results | |
|||
|
|||
Two additional company lessons are especially practical. First, Microsoft’s official “dogfood” guidance makes clear that internal prerelease use helps teams test the newest versions and build a better experience for customers, but dogfooding works best as a **final internal check**, not as a substitute for external user evidence. Second, Atlassian’s journey-mapping guidance states the problem bluntly: even teams that use their own products every day do not necessarily use them the same ways as customers, and it is easy to assume customers share the team’s institutional knowledge. Those two observations together explain why healthy empathy programs use internal usage plus external observation, not one or the other. citeturn35view0turn26view0 |
|||
|
|||
The broader research on software engineering supports the case-study pattern. Recent studies in the field identify empathy as increasingly recognized but still underdeveloped in software practice, with barriers including toxic culture, bias, excessive technical focus, and weak developer-user contact. That makes the company examples above more than isolated anecdotes: they are mature responses to recurring structural problems. citeturn8search0turn8search8turn8search20turn2search19 |
|||
|
|||
## Practical Toolkit |
|||
|
|||
The templates below are designed for direct reuse in a mid-size software company. They synthesize the report’s source base: ISO human-centered design, Google’s HEART and DORA guidance, NNGroup workshop and evaluation methods, Atlassian journey mapping, and Intuit’s deep-customer-empathy practices. citeturn34view0turn20view0turn21view0turn25view0turn25view1turn26view0turn32view1turn32view0 |
|||
|
|||
A practical feature-critique checklist should force teams to review **usefulness, usability, and value** separately. Many software features fail because teams collapse those into one question. |
|||
|
|||
| Dimension | Review question | Evidence to inspect | Rating | Escalate if… | |
|||
|---|---|---|---|---| |
|||
| User goal | What exact task is the user trying to complete? | Persona, job-to-be-done, top task, customer quote | Green / Yellow / Red | Team cannot state the task in one sentence | |
|||
| Discoverability | Would a first-time user know where to start? | Walkthrough notes, prototype, navigation labels | Green / Yellow / Red | Users must rely on insider vocabulary | |
|||
| Learnability | Would the user know what action to take next? | Cognitive-walkthrough discussion, error-prone steps | Green / Yellow / Red | Two or more steps fail walkthrough questions | |
|||
| Usefulness | Does this solve a real pain point or only an internal idea of one? | Interview evidence, support themes, workarounds | Green / Yellow / Red | No direct evidence of pain, workaround, or unmet need | |
|||
| Usability | Can the user complete the task with low friction? | Success rate, SEQ, SUS, time on task, heuristics | Green / Yellow / Red | Success is low, time is high, or severe heuristic issues remain | |
|||
| Value | Would the user feel the outcome is worth the effort, time, or cost? | Adoption hypothesis, buyer objections, retention logic | Green / Yellow / Red | Value depends on explanation from a salesperson or onboarding specialist | |
|||
| Trust | Is the message, state, and consequence clear enough to inspire confidence? | Copy review, state feedback, error recovery | Green / Yellow / Red | Critical states are ambiguous or recovery is weak | |
|||
| Inclusion | What user group is most likely to be excluded by default? | Accessibility review, edge-case discussion | Green / Yellow / Red | Team cannot name the likely exclusion case | |
|||
| Operational empathy | If this breaks, who feels the pain first and how? | Support scenarios, incident scenarios, runbooks | Green / Yellow / Red | Support or recovery path is unclear | |
|||
| Measurement | What metric would improve if the feature truly helped? | HEART/DORA/KPI scorecard | Green / Yellow / Red | No metric is tied to the problem statement | |
|||
|
|||
An empathy map template is most useful when every statement is anchored to evidence rather than intuition. |
|||
|
|||
| Empathy-map field | Template prompt | Evidence source | |
|||
|---|---|---| |
|||
| Says | What has this user literally said in interviews, calls, tickets, or demos? | Direct quote or transcript | |
|||
| Thinks | What belief or concern seems to guide behavior, even if not stated directly? | Inference from observation, marked as inference | |
|||
| Does | What actions, workarounds, avoidance patterns, or repeated steps were observed? | Observation, analytics, support logs | |
|||
| Feels | What emotion is visible or credibly inferable at key moments? | Observation, sentiment line, quotes | |
|||
| Pains | What friction, risk, confusion, or cost keeps recurring? | Ticket themes, journey-map pain points | |
|||
| Gains | What outcome, reassurance, speed, or control does the user actually want? | Interviews, adoption patterns | |
|||
| Evidence gaps | What do we still not know? | Research backlog | |
|||
|
|||
A user-journey critique template should connect what people experience to what teams can change. |
|||
|
|||
| Journey stage | User goal | Key touchpoint | Pain point | Emotion | Current workaround | Opportunity | Owner | Metric to watch | |
|||
|---|---|---|---|---|---|---|---|---| |
|||
| Awareness | | | | | | | | | |
|||
| Evaluation | | | | | | | | | |
|||
| Trial or onboarding | | | | | | | | | |
|||
| First successful use | | | | | | | | | |
|||
| Reuse or expansion | | | | | | | | | |
|||
| Support or recovery | | | | | | | | | |
|||
|
|||
For most mid-size software companies, three workshop formats are sufficient: a quick feature review, a deeper cross-functional empathy workshop, and a lightweight empathy sprint around a risky initiative. The suggested agendas below are based on Atlassian’s 90-minute journey-mapping play, NNGroup’s workshop guidance, and Intuit’s time-boxed observation and debrief methods. citeturn26view0turn26view2turn25view3turn32view1turn32view0 |
|||
|
|||
| Workshop format | Participants | Time | Agenda | Best use | |
|||
|---|---|---|---|---| |
|||
| Feature empathy review | PM, designer, 1–2 developers, support or sales representative, facilitator | 60–90 min | Re-state persona and task; review evidence; run cognitive walkthrough; run quick heuristic scan; assign redesign actions and metrics | A feature, release candidate, onboarding step, pricing page | |
|||
| Cross-functional empathy workshop | 4–8 people across product, design, engineering, sales, marketing, support; optional customer | 90 min | Persona and scope; build back-story; map journey; mark pain points; chart sentiment; analyze high-impact opportunities | Discovery, onboarding redesign, funnel friction | |
|||
| Lightweight empathy sprint | Cross-functional core team plus user research support | 1–2 weeks | Observe customers; debrief surprises and pain points; define problem statement; prototype; validate; prioritize by metric impact | Risky roadmap item, new audience, weak adoption, churn spike | |
|||
|
|||
```mermaid |
|||
gantt |
|||
title Two-week empathy sprint |
|||
dateFormat YYYY-MM-DD |
|||
axisFormat %d %b |
|||
|
|||
section Discovery |
|||
Gather support, sales, analytics evidence :a1, 2026-07-20, 2d |
|||
Follow-me-homes or contextual interviews :a2, after a1, 3d |
|||
|
|||
section Synthesis |
|||
Empathy debrief and pattern clustering :b1, after a2, 1d |
|||
Problem statement and journey critique :b2, after b1, 1d |
|||
|
|||
section Evaluation |
|||
Prototype or revise :c1, after b2, 2d |
|||
Role-reversal walkthrough and heuristic pass :c2, after c1, 1d |
|||
User validation and metric baseline :c3, after c2, 2d |
|||
|
|||
section Decision |
|||
Go, iterate, or stop decision :d1, after c3, 1d |
|||
``` |
|||
|
|||
A final recommendation: keep the cadence small enough that the practice survives contact with delivery pressure. DORA warns against turning metrics into goals to be gamed, and NNGroup cautions against reporting only UX activity instead of impact. The best workshop is therefore not the most elaborate one. It is the smallest recurring ritual that still connects role-reversal to measurable change. For many software companies, that means one empathy review for every major release, one cross-functional journey workshop each quarter, and one targeted empathy sprint whenever a high-value initiative has weak user evidence. citeturn21view0turn23view0 |
|||
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 1.7 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 962 KiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 940 KiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 908 KiB |
@ -0,0 +1,221 @@ |
|||
# Empathy in the Workplace for Software Companies |
|||
|
|||
## 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. citeturn34view0turn29view1turn29view2turn28view3turn7search0turn28view0 |
|||
|
|||
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. citeturn34view0turn34view1 |
|||
|
|||
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. citeturn20view0turn33view1turn24view0turn23view0turn21view0turn22view0 |
|||
|
|||
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. citeturn20view0turn24view0turn23view0turn26view0turn25view0turn27view0 |
|||
|
|||
The table below condenses the report’s practical recommendations into an operating model for a mid-size software company. It synthesizes ISO human-centered-design principles, Google’s HEART and DORA guidance, NNGroup methods, Atlassian workshop practices, and company examples from IBM, Intuit, Microsoft, and GitHub. citeturn34view0turn20view0turn21view0turn26view0turn31view0turn31view4turn17view0turn31view2 |
|||
|
|||
| Operating area | Minimum recommendation | Why it matters | |
|||
|---|---|---| |
|||
| Product and UX | Run a structured empathy review on every material feature before release | Converts assumptions into observable critique, especially for learnability and value | |
|||
| Engineering | Add cognitive walkthroughs for new workflows and dogfooding with caution | Helps expose first-time-user friction, while recognizing employees are not the same as customers | |
|||
| Sales and marketing | Review landing pages, pricing pages, demos, emails, and onboarding copy from the buyer’s perspective | Brings empathy into acquisition and expectation-setting, not only UI | |
|||
| Measurement | Track one small balanced scorecard: task success, time or effort, perceived usability, adoption or activation, retention, and one business KPI | Prevents “feel-good empathy” without outcome accountability | |
|||
| Culture and process | Involve support, research, sales, and engineering in cross-functional reviews | Broadens perspective and reduces local optimization | |
|||
| Leadership | Protect psychological safety and blameless critique | Teams cannot surface customer pain honestly if they fear blame | |
|||
|
|||
## What Empathy Means in a Software Company |
|||
|
|||
Empathy is not one thing. Across psychology and design research, it is commonly treated as a multidimensional construct with at least two major components. **Affective empathy** refers to sharing or resonating with another person’s feeling state. **Cognitive empathy** refers to understanding another person’s viewpoint, intentions, needs, or mental state. Related work argues that empathy and perspective-taking should be conceptually separated, because affect sharing and cognitive perspective-taking can diverge and recruit different processes. citeturn29view1turn29view2turn28view3 |
|||
|
|||
That distinction matters in the workplace. If a software company wants teams to evaluate features, copy, onboarding, pricing pages, or service flows by “putting themselves in the user’s shoes,” the most reliable mechanism is usually **structured perspective-taking** rather than pure emotional resonance. Perspective-taking is the cognitive process of adopting another person’s viewpoint to understand their preferences, values, and needs. Work on organizations and creativity shows that perspective-taking helps employees generate ideas that are not only novel but also useful to other people inside and outside the organization. Other research shows it can improve negotiation and creative problem solving, which is especially relevant for sales, pricing, and product tradeoff discussions. citeturn28view0turn6search8turn7search0 |
|||
|
|||
Affective empathy still matters, but it should be used carefully. It is often the source of prosocial concern and ethical motivation, yet it can also become empathic distress or bias attention toward vivid pain rather than representative evidence. Recent reviews distinguish empathic distress from compassion and caution that empathy can have downsides when it is unstructured or emotionally overloading. A good software-company practice is therefore to pair an affective prompt such as “What frustration or anxiety is this causing?” with cognitive prompts such as “What is the user trying to achieve, what cues do they see, and what would they reasonably infer at this step?” citeturn28view3turn29view2turn29view1 |
|||
|
|||
In a software firm, empathy should also be understood as **human-centered evaluation across the full customer experience**, not just interface design. ISO and NIST guidance emphasize that human-centered design addresses the whole user experience, is driven by user-centered evaluation, and requires multidisciplinary perspectives. That means developers should empathize with first-time and edge-case users, designers with user cognition and accessibility needs, sales with the buyer’s decision journey and implementation anxieties, and marketing with the customer’s information needs and language during awareness, evaluation, trial, and adoption. citeturn34view0turn34view1 |
|||
|
|||
The strongest practical interpretation for a software company is this: **empathy is the disciplined replacement of internal assumptions with testable, role-reversed understanding**. It is not “Would I like this?” It is “Would this specific user or buyer, in this context, with this knowledge and these constraints, understand the value, succeed at the task, and consider the result worth the cost?” That framing aligns with human-centered design, cognitive walkthroughs, and modern UX benchmarking. citeturn34view0turn25view0turn24view0 |
|||
|
|||
## Methods for Role Reversal and Feature Critique |
|||
|
|||
A software company does not need a single empathy method. It needs a **stack** of methods, each serving a different diagnostic purpose. Empathy maps are useful for capturing what users say, think, do, and feel, and for building shared understanding. Journey maps are better for exposing end-to-end friction, especially across acquisition, onboarding, support, and renewal moments. Cognitive walkthroughs are ideal when the question is learnability for a new user. Heuristic evaluations are strong for systematic usability inspection. Role play is useful when the room lacks real users or sufficient perspective diversity. Dogfooding is valuable for surfacing operational issues rapidly, but it is incomplete because employees often have too much institutional knowledge and use the product differently than real customers. citeturn25view1turn26view0turn25view0turn27view0turn25view3turn35view1turn26view0 |
|||
|
|||
```mermaid |
|||
flowchart LR |
|||
A[Direct customer evidence<br/>interviews, support logs, analytics, follow-me-homes] --> B[Shared artifact<br/>empathy map or journey map] |
|||
B --> C[Role-reversal review<br/>developers, designers, sales, marketing] |
|||
C --> D[Structured critique<br/>cognitive walkthrough and heuristic evaluation] |
|||
D --> E[Prototype or revise] |
|||
E --> F[Validate with users and analytics] |
|||
F --> G[Decision<br/>ship, iterate, or stop] |
|||
G --> A |
|||
``` |
|||
|
|||
The workflow above reflects the common structure across ISO human-centered design, Intuit’s deep-customer-empathy methods, NNGroup workshop guidance, and Google’s Goals-Signals-Metrics logic: start from real evidence, externalize it, inspect from the other person’s perspective, then validate with measurement. citeturn34view0turn32view1turn32view0turn25view3turn20view0 |
|||
|
|||
The comparison below is a practical selection guide for software teams. |
|||
|
|||
| Method | Best question it answers | Best time to use | Main output | Strengths | Main limitation | Evidence base | |
|||
|---|---|---|---|---|---|---| |
|||
| Empathy map | What does one user or segment say, think, do, and feel? | Early discovery, after interviews, before ideation | Shared user-understanding artifact | Builds common ground, highlights knowledge gaps, helps prioritize needs | Can become speculative if not grounded in research | citeturn25view1 | |
|||
| Journey map | Where along the end-to-end journey do pain points, emotions, and drop-offs occur? | Acquisition, onboarding, support, renewal, cross-functional redesign | Current-state or future-state journey | Excellent for linking UX, marketing, analytics, and support data | Too-broad scope easily creates vague maps | citeturn26view0turn25view2 | |
|||
| Cognitive walkthrough | Will a new user know what to do, find the right action, and recognize progress? | New workflows, first-use experiences, major redesigns | Step-level learnability diagnosis | Strong for developers and PMs; inexpensive compared with full user testing | Best for learnability, not all UX questions | citeturn25view0 | |
|||
| Heuristic evaluation | Does the interface violate known usability principles? | Prototype stage, pre-test cleanup, complex UIs | Usability issue list by severity and principle | Fast, systematic, good for stretching research budget | Cannot replace testing with actual users | citeturn27view0turn27view1 | |
|||
| Role play | What changes when we force ourselves to speak from another perspective? | Workshops with insufficient diversity, early critique | Reframed assumptions and priorities | Useful for cross-functional teams; challenges bias and groupthink | Can feel artificial; needs a clear prompt and facilitation | citeturn25view3turn26view3 | |
|||
| Dogfooding | What breaks when we use the product in real work? | Continuous internal validation, prerelease builds | Operational issues, rough edges, adoption friction | Fast signal, good for operational empathy | Employees are not representative users; internal knowledge masks friction | citeturn35view0turn35view1turn26view0 | |
|||
| Follow-me-homes and contextual observation | What do people actually do, and why do they work around the system? | Discovery, onboarding research, problem reframing | Behavioral observations, pain points, surprises | Strong antidote to self-report bias and internal assumptions | Requires access to customers and disciplined observation | citeturn31view4turn32view1 | |
|||
|
|||
For a mixed technical and non-technical audience, the best recurring pattern is usually **contextual evidence → empathy map or journey map → role-reversal critique → cognitive walkthrough or heuristic review → user validation**. That sequence is especially well suited to feature critique because it moves from broad understanding to narrow diagnosis. It also gives different functions a clear role: support and sales provide frontline signals, marketing contributes message and expectation analysis, designers frame tasks and artifacts, and developers inspect learnability, error prevention, and operational feasibility. citeturn25view1turn26view0turn25view0turn27view0turn14search16 |
|||
|
|||
## What to Measure |
|||
|
|||
Empathy becomes actionable only when it is connected to measurement. Google’s HEART framework remains one of the most useful ways to structure product-level UX metrics because it covers **Happiness, Engagement, Adoption, Retention, and Task Success**, and pairs well with a **Goals–Signals–Metrics** process. The framework is intentionally selective: teams should not track every category mechanically, but should choose the mix that reflects the user and business problem at hand. Google later extended the same logic to developer experience, emphasizing that HEART helps teams choose what to measure rather than serving as a tool itself. citeturn20view0turn22view0 |
|||
|
|||
For software companies, the key analytical move is to connect **upstream** user-experience metrics to **downstream** business outcomes. NNGroup’s recent guidance draws the distinction clearly: upstream metrics tell you how the design performed, while downstream metrics indicate what changed in the business, such as support volume, conversion, or churn. That is exactly the bridge an empathy program needs. If a role-reversal review finds onboarding confusion, the resulting metrics should not stop at “users seemed confused”; they should also ask whether the redesign improved first-use completion, reduced support contacts, and improved retention or activation. citeturn23view0turn24view0 |
|||
|
|||
```mermaid |
|||
flowchart LR |
|||
A[Goal<br/>Help a first-time user understand and complete a feature] --> B[Signals<br/>finds feature, understands value, completes task, returns] |
|||
B --> C[UX metrics<br/>SEQ, SUS, task success, time on task, error rate] |
|||
C --> D[Behavioral metrics<br/>activation, adoption, retention] |
|||
D --> E[Business metrics<br/>conversion, support cost, churn, renewal] |
|||
``` |
|||
|
|||
The logic above follows Google’s Goals–Signals–Metrics model and NNGroup’s upstream-to-downstream bridge: a role-reversal review should define a concrete user goal, specify what success would look like from the user’s perspective, then connect that to metrics leadership already cares about. citeturn20view0turn23view0 |
|||
|
|||
The scorecard below is a rigorous but practical measurement model for feature critique. |
|||
|
|||
| Evaluation question | Recommended UX metrics | Related business KPIs | Why this pairing works | Source basis | |
|||
|---|---|---|---|---| |
|||
| Is the feature understandable and learnable? | Task-success rate, error rate, time on task, SEQ, cognitive-walkthrough issue count | Support contacts, implementation friction, trial-to-activation rate | Learnability failures usually surface first as failed tasks or slow tasks, then downstream as support burden or drop-off | citeturn25view0turn24view0turn23view0turn33view0 | |
|||
| Is the feature usable overall? | SUS, ease-of-use rating, heuristic-violation count | CSAT, churn risk, post-launch rework | SUS gives a global usability benchmark; heuristics catch preventable design problems before user testing | citeturn33view1turn33view0turn27view0turn27view1 | |
|||
| Is the feature useful and valuable? | Adoption, repeat usage, retention, feature-level engagement | Conversion, renewal, expansion, churn | A usable feature can still be low-value; adoption and retention test whether the feature solves a meaningful problem | citeturn20view0turn24view0turn23view0 | |
|||
| Is the onboarding or first-run experience working? | First-use completion, time to first value, SEQ, activation rate | Trial conversion, sales-cycle efficiency, support cost | Early friction has outsized consequences for activation and retention | citeturn24view0turn23view0turn26view0 | |
|||
| Is the feature accessible and inclusive? | Accessibility issue rate, task success for diverse users, error recovery, assistive-tech compatibility | Market reach, legal and compliance risk, satisfaction | Inclusive design reduces exclusion and often improves the experience more broadly | citeturn17view0turn18view0turn31view2 | |
|||
| Is the internal delivery system supporting empathy rather than undermining it? | Developer happiness, task success on internal platforms, platform adoption, incident recovery | DORA metrics, engineering throughput, change stability | Product empathy erodes if internal tools create enough friction that teams optimize for shipping over usefulness | citeturn22view0turn21view0turn4search19 | |
|||
|
|||
Where a company has internal developer platforms or design systems, it should use a second, lighter scorecard for internal users. Google Cloud’s guidance on applying HEART to developer experience is useful here: measure developer happiness, platform engagement, adoption, retention, and task success, then read those signals alongside DORA metrics such as deployment frequency, change lead time, change fail rate, failed-deployment recovery time, and deployment rework rate. DORA explicitly warns against weaponizing the metrics or comparing unlike teams; the goal is continuous improvement, not gamification. citeturn22view0turn21view0 |
|||
|
|||
A note on specific instruments: Brooke’s SUS remains a reliable low-cost ten-item questionnaire for overall perceived usability, and NNGroup recommends pairing short attitudinal questions such as the Single Ease Question with behavioral methods such as quantitative usability testing or analytics. That combination is usually better than relying on a single metric alone. citeturn33view1turn33view0turn24view0 |
|||
|
|||
## How to Embed Empathy in Process and Culture |
|||
|
|||
Empathy becomes durable when it is built into process gates, review rituals, and decision rights. Human-centered-design standards already imply the core process changes: understand the context of use, specify user requirements, produce design solutions, and evaluate them iteratively with multidisciplinary involvement. In practice, that means a software company should not wait for a late-stage usability test. It should create visible checkpoints where teams explicitly ask whether a feature, message, workflow, or campaign still makes sense from the user’s viewpoint. citeturn34view0turn34view1 |
|||
|
|||
A good operating model for a mid-size software company is to insert empathy into four moments. First, during discovery, use direct user evidence, support data, field observation, or follow-me-homes. Second, during definition, require an empathy artifact such as an empathy map, journey map, or problem statement linked to a real persona and task. Third, during critique, run a cross-functional walkthrough on the feature, landing page, or campaign with explicit role-reversal prompts. Fourth, after release, review a compact dashboard of UX and business metrics so that the organization learns whether its empathic assumptions were valid. citeturn32view1turn25view1turn26view0turn20view0turn23view0 |
|||
|
|||
The role-specific pattern below is a useful way to keep empathy from remaining “owned” by design alone. |
|||
|
|||
| Function | Role-reversal prompt | What this team should inspect | Typical evidence | |
|||
|---|---|---|---| |
|||
| Developers | “If I were a first-time user with no product knowledge, where would I fail or hesitate?” | Learnability, error prevention, defaults, performance blockers, operational friction, edge cases | Cognitive walkthrough, dogfooding, support tickets, logs, task-success metrics | |
|||
| Designers | “If I were this user in this context, would the interface match my language, expectations, and abilities?” | Information scent, interaction flow, accessibility, recovery from errors, emotional friction | User interviews, empathy maps, prototypes, usability tests, heuristic review | |
|||
| Sales | “If I were a buyer evaluating risk, value, and effort, what would block commitment?” | Demo flow, objection handling, implementation anxiety, trust signals, time to first value | Discovery calls, win-loss notes, onboarding friction, trial-conversion data | |
|||
| Marketing | “If I were the intended customer, would I recognize myself, understand the promise, and believe it?” | Positioning clarity, message-market fit, jargon, expectation setting, CTA friction | Journey maps, interview quotes, funnel analytics, campaign conversion and bounce patterns | |
|||
| Support and success | “Where does the product force preventable workarounds or confusion?” | Repeated pain points, failure demand, documentation gaps, friction across handoffs | Ticket themes, chat transcripts, escalation reasons, contact volume | |
|||
| Managers and leaders | “What in our process makes customer understanding difficult or optional?” | Decision latency, resourcing, review cadence, incentives, safety to surface bad news | Retrospectives, DORA trends, team surveys, roadmap churn | |
|||
|
|||
This model is consistent with IBM’s view that everyone on a team should focus on users first, Microsoft’s statement that inclusive design is for program managers, engineers, data scientists, designers, and others who create products, and Intuit’s expectation that every employee improves customers’ lives through deep customer empathy. citeturn31view1turn17view0turn31view4 |
|||
|
|||
Barriers are predictable, and the software-engineering literature increasingly names them directly. Recent studies and syntheses in software engineering report barriers such as toxic organizational culture, workplace bias, individualistic behavior, excessive technical focus, and insufficient sustained empathy in developer-user interactions. Those findings match longstanding UX workshop experience: empathy breaks down when teams are distant from users, when the room is insufficiently diverse, or when hierarchy suppresses candid critique. citeturn8search0turn8search8turn8search20turn26view3turn25view3 |
|||
|
|||
The mitigation pattern is therefore both social and procedural. |
|||
|
|||
| Barrier | What it looks like in a software company | Mitigation | Evidence base | |
|||
|---|---|---|---| |
|||
| Excessive technical focus | Shipping what is elegant to build rather than what is useful | Require a user task, persona, and success metric for each material feature | citeturn8search8turn20view0turn34view0 | |
|||
| Institutional-knowledge blindness | Internal experts assume customers know what the team knows | Use cognitive walkthroughs and external customer evidence; do not rely on dogfooding alone | citeturn25view0turn35view1turn26view0 | |
|||
| Low user contact | Teams build based on second-hand summaries | Bring real users into workshops when possible and expose teams to direct interviews or observation | citeturn14search16turn26view3turn32view1 | |
|||
| Weak cross-functional alignment | Product, engineering, sales, and support optimize different local goals | Use journey maps and empathy workshops to create shared language and visible tradeoffs | citeturn25view2turn26view2turn31view0 | |
|||
| Hierarchy and groupthink | Senior opinions dominate; uncomfortable feedback is softened | Facilitate workshops, allow anonymity where useful, and use role play when the room lacks diversity | citeturn25view3turn14search18turn26view3 | |
|||
| Fear of blame | Teams hide pain points or avoid early critique | Build psychological safety and blameless review practices | citeturn9search0turn31view3 | |
|||
| Emotional overload or empathy fatigue | Teams over-index on vivid anecdotes or burn out from constant affective labor | Emphasize perspective-taking, representative evidence, and bounded review rituals | citeturn7search0turn28view3turn0search12 | |
|||
|
|||
Psychological safety is especially important. Google’s research on team effectiveness identifies it as a foundational ingredient of high-performing teams, and GitHub’s on-call culture notes the need for safe, blameless spaces where engineers can learn from unfamiliar situations. Empathy reviews fail when people fear that surfacing customer pain will be interpreted as incompetence or delay. citeturn9search0turn31view3 |
|||
|
|||
## Evidence from Software Companies |
|||
|
|||
Public case evidence on empathy in software is useful, but it is uneven. The strongest public materials are often official process descriptions or commissioned studies rather than controlled field experiments. That means these cases are best used as **implementation patterns** and **directional evidence**, not as universal causal proofs. Still, taken together, they show a consistent pattern: software companies that embed empathy structurally tend to connect it to cross-functional alignment, earlier problem discovery, accessibility, and better customer experience. citeturn31view0turn31view1turn17view0turn31view2turn31view4 |
|||
|
|||
| Company | Public empathy practice | What the public evidence shows | What a mid-size software company can learn | Evidence quality | |
|||
|---|---|---|---|---| |
|||
| IBM | Enterprise Design Thinking | IBM frames design thinking as a user-first, scalable framework with principles of user outcomes, restless reinvention, and diverse empowered teams. IBM publicly reports faster time to market, ROI, and team-efficiency gains on its training page, clearly tying these claims to Forrester studies linked from the page. citeturn31view1turn31view0 | Give teams a common language, make user outcomes explicit, and keep design work tied to business delivery rather than isolated discovery | Moderate; official process description plus vendor-linked commissioned outcomes | |
|||
| Intuit | Design for Delight and Deep Customer Empathy | Intuit explicitly says every employee is expected to improve customers’ lives and defines D4D through Deep Customer Empathy, broad ideation, and rapid experimentation. Its method cards formalize follow-me-homes and empathy debriefs, including time boxes and prompts. citeturn31view4turn32view1turn32view0 | Treat empathy as an organizational capability, not only a design technique; make observation and debrief routine | Moderate; official methods are detailed, but quantified public outcomes are limited | |
|||
| Microsoft | Inclusive Design | Microsoft’s inclusive-design guidance centers on recognizing exclusion, learning from diversity, and solving for one then extending to many. It explicitly says the practice is for PMs, engineers, data scientists, designers, and others, and provides real-world examples like Copilot, Live Captions, Mesh Avatars, and reader tools. citeturn17view0turn18view0 | Broaden “user empathy” beyond the average user; use exclusion cases to improve mainstream experiences | Moderate; strong official practice guidance and product examples, lighter on causal metrics | |
|||
| GitHub | Accessibility shift and customer-centered operational ownership | GitHub’s public accessibility write-up emphasizes cultural shift, dedicated specialists, and permission for incremental progress. Its on-call culture case explains that ownership aligned with the code a team maintains was pursued to improve the customer experience and create a blameless, supportive culture. citeturn31view2turn31view3 | Empathy is not only front-end UX. Ownership, incident response, accessibility, and supportability are also empathy work | Moderate; strong operational narrative, limited quantified public results | |
|||
|
|||
Two additional company lessons are especially practical. First, Microsoft’s official “dogfood” guidance makes clear that internal prerelease use helps teams test the newest versions and build a better experience for customers, but dogfooding works best as a **final internal check**, not as a substitute for external user evidence. Second, Atlassian’s journey-mapping guidance states the problem bluntly: even teams that use their own products every day do not necessarily use them the same ways as customers, and it is easy to assume customers share the team’s institutional knowledge. Those two observations together explain why healthy empathy programs use internal usage plus external observation, not one or the other. citeturn35view0turn26view0 |
|||
|
|||
The broader research on software engineering supports the case-study pattern. Recent studies in the field identify empathy as increasingly recognized but still underdeveloped in software practice, with barriers including toxic culture, bias, excessive technical focus, and weak developer-user contact. That makes the company examples above more than isolated anecdotes: they are mature responses to recurring structural problems. citeturn8search0turn8search8turn8search20turn2search19 |
|||
|
|||
## Practical Toolkit |
|||
|
|||
The templates below are designed for direct reuse in a mid-size software company. They synthesize the report’s source base: ISO human-centered design, Google’s HEART and DORA guidance, NNGroup workshop and evaluation methods, Atlassian journey mapping, and Intuit’s deep-customer-empathy practices. citeturn34view0turn20view0turn21view0turn25view0turn25view1turn26view0turn32view1turn32view0 |
|||
|
|||
A practical feature-critique checklist should force teams to review **usefulness, usability, and value** separately. Many software features fail because teams collapse those into one question. |
|||
|
|||
| Dimension | Review question | Evidence to inspect | Rating | Escalate if… | |
|||
|---|---|---|---|---| |
|||
| User goal | What exact task is the user trying to complete? | Persona, job-to-be-done, top task, customer quote | Green / Yellow / Red | Team cannot state the task in one sentence | |
|||
| Discoverability | Would a first-time user know where to start? | Walkthrough notes, prototype, navigation labels | Green / Yellow / Red | Users must rely on insider vocabulary | |
|||
| Learnability | Would the user know what action to take next? | Cognitive-walkthrough discussion, error-prone steps | Green / Yellow / Red | Two or more steps fail walkthrough questions | |
|||
| Usefulness | Does this solve a real pain point or only an internal idea of one? | Interview evidence, support themes, workarounds | Green / Yellow / Red | No direct evidence of pain, workaround, or unmet need | |
|||
| Usability | Can the user complete the task with low friction? | Success rate, SEQ, SUS, time on task, heuristics | Green / Yellow / Red | Success is low, time is high, or severe heuristic issues remain | |
|||
| Value | Would the user feel the outcome is worth the effort, time, or cost? | Adoption hypothesis, buyer objections, retention logic | Green / Yellow / Red | Value depends on explanation from a salesperson or onboarding specialist | |
|||
| Trust | Is the message, state, and consequence clear enough to inspire confidence? | Copy review, state feedback, error recovery | Green / Yellow / Red | Critical states are ambiguous or recovery is weak | |
|||
| Inclusion | What user group is most likely to be excluded by default? | Accessibility review, edge-case discussion | Green / Yellow / Red | Team cannot name the likely exclusion case | |
|||
| Operational empathy | If this breaks, who feels the pain first and how? | Support scenarios, incident scenarios, runbooks | Green / Yellow / Red | Support or recovery path is unclear | |
|||
| Measurement | What metric would improve if the feature truly helped? | HEART/DORA/KPI scorecard | Green / Yellow / Red | No metric is tied to the problem statement | |
|||
|
|||
An empathy map template is most useful when every statement is anchored to evidence rather than intuition. |
|||
|
|||
| Empathy-map field | Template prompt | Evidence source | |
|||
|---|---|---| |
|||
| Says | What has this user literally said in interviews, calls, tickets, or demos? | Direct quote or transcript | |
|||
| Thinks | What belief or concern seems to guide behavior, even if not stated directly? | Inference from observation, marked as inference | |
|||
| Does | What actions, workarounds, avoidance patterns, or repeated steps were observed? | Observation, analytics, support logs | |
|||
| Feels | What emotion is visible or credibly inferable at key moments? | Observation, sentiment line, quotes | |
|||
| Pains | What friction, risk, confusion, or cost keeps recurring? | Ticket themes, journey-map pain points | |
|||
| Gains | What outcome, reassurance, speed, or control does the user actually want? | Interviews, adoption patterns | |
|||
| Evidence gaps | What do we still not know? | Research backlog | |
|||
|
|||
A user-journey critique template should connect what people experience to what teams can change. |
|||
|
|||
| Journey stage | User goal | Key touchpoint | Pain point | Emotion | Current workaround | Opportunity | Owner | Metric to watch | |
|||
|---|---|---|---|---|---|---|---|---| |
|||
| Awareness | | | | | | | | | |
|||
| Evaluation | | | | | | | | | |
|||
| Trial or onboarding | | | | | | | | | |
|||
| First successful use | | | | | | | | | |
|||
| Reuse or expansion | | | | | | | | | |
|||
| Support or recovery | | | | | | | | | |
|||
|
|||
For most mid-size software companies, three workshop formats are sufficient: a quick feature review, a deeper cross-functional empathy workshop, and a lightweight empathy sprint around a risky initiative. The suggested agendas below are based on Atlassian’s 90-minute journey-mapping play, NNGroup’s workshop guidance, and Intuit’s time-boxed observation and debrief methods. citeturn26view0turn26view2turn25view3turn32view1turn32view0 |
|||
|
|||
| Workshop format | Participants | Time | Agenda | Best use | |
|||
|---|---|---|---|---| |
|||
| Feature empathy review | PM, designer, 1–2 developers, support or sales representative, facilitator | 60–90 min | Re-state persona and task; review evidence; run cognitive walkthrough; run quick heuristic scan; assign redesign actions and metrics | A feature, release candidate, onboarding step, pricing page | |
|||
| Cross-functional empathy workshop | 4–8 people across product, design, engineering, sales, marketing, support; optional customer | 90 min | Persona and scope; build back-story; map journey; mark pain points; chart sentiment; analyze high-impact opportunities | Discovery, onboarding redesign, funnel friction | |
|||
| Lightweight empathy sprint | Cross-functional core team plus user research support | 1–2 weeks | Observe customers; debrief surprises and pain points; define problem statement; prototype; validate; prioritize by metric impact | Risky roadmap item, new audience, weak adoption, churn spike | |
|||
|
|||
```mermaid |
|||
gantt |
|||
title Two-week empathy sprint |
|||
dateFormat YYYY-MM-DD |
|||
axisFormat %d %b |
|||
|
|||
section Discovery |
|||
Gather support, sales, analytics evidence :a1, 2026-07-20, 2d |
|||
Follow-me-homes or contextual interviews :a2, after a1, 3d |
|||
|
|||
section Synthesis |
|||
Empathy debrief and pattern clustering :b1, after a2, 1d |
|||
Problem statement and journey critique :b2, after b1, 1d |
|||
|
|||
section Evaluation |
|||
Prototype or revise :c1, after b2, 2d |
|||
Role-reversal walkthrough and heuristic pass :c2, after c1, 1d |
|||
User validation and metric baseline :c3, after c2, 2d |
|||
|
|||
section Decision |
|||
Go, iterate, or stop decision :d1, after c3, 1d |
|||
``` |
|||
|
|||
A final recommendation: keep the cadence small enough that the practice survives contact with delivery pressure. DORA warns against turning metrics into goals to be gamed, and NNGroup cautions against reporting only UX activity instead of impact. The best workshop is therefore not the most elaborate one. It is the smallest recurring ritual that still connects role-reversal to measurable change. For many software companies, that means one empathy review for every major release, one cross-functional journey workshop each quarter, and one targeted empathy sprint whenever a high-value initiative has weak user evidence. citeturn21view0turn23view0 |
|||
Binary file not shown.
@ -0,0 +1,96 @@ |
|||
# Empathy in the Workplace for Software Companies |
|||
|
|||
 |
|||
|
|||
Great software is not created only through clean code, attractive interfaces, persuasive campaigns, or polished sales demonstrations. It is created when teams understand the people behind the requirements: what users are trying to achieve, what they already know, what confuses them, and what they consider valuable. |
|||
|
|||
For a software company, empathy should not be treated as a soft cultural slogan. It is a disciplined practice for replacing internal assumptions with evidence about users, buyers, administrators, developers, and other people affected by the product. |
|||
|
|||
## What Empathy Means in a Software Company |
|||
|
|||
 |
|||
|
|||
Empathy includes both emotional concern and perspective-taking. In product work, the most actionable form is often cognitive empathy: deliberately examining a feature, workflow, message, or pricing decision from another person’s point of view. |
|||
|
|||
> **The useful question is not:** “Would I like this?” |
|||
> **It is:** “Would this specific user, in this context, with this knowledge and these constraints, understand the value and complete the task?” |
|||
|
|||
This distinction matters because employees possess institutional knowledge that customers do not. A flow that feels obvious to the product team may be unclear to a first-time user. A message that sounds precise to engineering may sound like jargon to a buyer. A feature that is easy to demonstrate may still be difficult to adopt in a real organization. |
|||
|
|||
## Empathy Is a Cross-Functional Responsibility |
|||
|
|||
 |
|||
|
|||
Empathy cannot remain owned only by product designers. Every function sees a different part of the customer reality: |
|||
|
|||
| Function | Perspective-taking question | What to inspect | |
|||
|---|---|---| |
|||
| Developers | Where would a first-time user fail, hesitate, or misunderstand the system? | Defaults, errors, performance, learnability, edge cases, operational friction | |
|||
| Designers | Does the interface match the user’s language, expectations, abilities, and context? | Information architecture, accessibility, cognitive load, recovery from mistakes | |
|||
| Sales | What would make a buyer doubt the value, risk, implementation effort, or credibility? | Demo flow, objections, trust signals, time to value, organizational anxiety | |
|||
| Marketing | Would the intended customer recognize their problem and believe the promise? | Positioning, jargon, expectation setting, calls to action, message-market fit | |
|||
| Support and success | Where does the product repeatedly create avoidable confusion or workarounds? | Ticket themes, escalations, documentation gaps, recurring failure patterns | |
|||
|
|||
## A Practical Empathy Loop |
|||
|
|||
 |
|||
|
|||
A reliable empathy practice begins with real evidence and ends with validation. The process can be kept simple: |
|||
|
|||
1. **Understand:** Talk to users, observe them, review support conversations, and study behavioral data. |
|||
2. **Empathize:** Identify goals, fears, limitations, mental models, and environmental constraints. |
|||
3. **Define:** Frame the problem from the user’s viewpoint rather than the product’s internal structure. |
|||
4. **Create:** Design and build with that user context visible to the team. |
|||
5. **Validate:** Test assumptions with users and measurable outcomes. |
|||
6. **Repeat:** Treat empathy as an ongoing operating habit, not a workshop completed once. |
|||
|
|||
## Methods for Role Reversal and Feature Critique |
|||
|
|||
Different questions require different methods. Empathy maps help teams distinguish what users say, think, do, and feel. Journey maps reveal friction across acquisition, onboarding, support, and renewal. Cognitive walkthroughs test whether a new user can discover the correct action and recognize progress. Heuristic reviews expose systematic usability problems. Contextual observation reveals what people actually do rather than what they remember doing. |
|||
|
|||
Dogfooding is useful, but it is not sufficient. Employees usually know too much about the product, understand its vocabulary, and forgive rough edges that genuine customers may not tolerate. Internal usage should therefore supplement—not replace—external user evidence. |
|||
|
|||
## Putting Empathy into Daily Practice |
|||
|
|||
 |
|||
|
|||
Empathy becomes durable when it is built into ordinary delivery rituals. A team can begin with a few lightweight practices: |
|||
|
|||
- Bring real customer feedback into planning and refinement sessions. |
|||
- Watch users attempt important tasks without coaching them. |
|||
- Ask what would frustrate, confuse, or reduce trust at each step. |
|||
- Review important work as though encountering the product for the first time. |
|||
- Include product, engineering, design, sales, marketing, and support in selected critiques. |
|||
- Connect findings to activation, task success, adoption, retention, conversion, support volume, or churn. |
|||
|
|||
 |
|||
|
|||
## Measure Whether Empathy Changes Outcomes |
|||
|
|||
Empathy should produce testable hypotheses. When a team identifies onboarding confusion, it should define what improvement would look like: higher first-use completion, shorter time to value, fewer support contacts, or stronger activation and retention. |
|||
|
|||
A balanced scorecard can combine behavioral and attitudinal evidence: |
|||
|
|||
- Task-success and error rates |
|||
- Time or effort required to complete a task |
|||
- Perceived ease of use and overall usability |
|||
- Activation, adoption, repeat use, and retention |
|||
- Support demand, conversion, renewal, and churn |
|||
|
|||
The goal is not to turn empathy into a single number. The goal is to ensure that teams learn whether their understanding of the user was accurate. |
|||
|
|||
## Create the Conditions for Honest Critique |
|||
|
|||
Empathy reviews fail when teams fear blame, senior opinions dominate the room, or technical elegance consistently outweighs user value. Leaders should protect psychological safety, invite uncomfortable evidence, and treat surfaced friction as useful information rather than personal criticism. |
|||
|
|||
Teams should also avoid over-indexing on vivid anecdotes. A powerful customer story can reveal an important problem, but decisions should be checked against representative research, usage data, and business context. |
|||
|
|||
--- |
|||
|
|||
 |
|||
|
|||
## 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. |
|||
|
After Width: | Height: | Size: 908 KiB |
|
After Width: | Height: | Size: 962 KiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 1.7 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 1.1 MiB |
@ -0,0 +1,64 @@ |
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">WeAreDevelopers World Congress 2026 has come to an end, and we'd like to thank everyone who stopped by the ABP booth in Berlin!</span></span></span></span> |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">We had the opportunity to meet developers, architects, engineering leaders, and technology enthusiasts from around the world. It was a pleasure connecting with so many members of the developer community, hearing about the projects you're building, and discussing the challenges and opportunities shaping modern software development.</span></span></span></span> |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
## **<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Lexend, sans-serif;"><span style="font-size: 17pt;">Great Conversations and Product Demos</span></span></span></span>** |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">Throughout the event, our team showcased the latest developments across the ABP ecosystem, including ABP Framework, ABP Studio, and our AI-powered development capabilities.</span></span></span></span> |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">We had countless conversations about modular application development, clean architecture, microservices, AI-assisted development, and how teams can build enterprise applications faster while maintaining long-term quality and maintainability.</span></span></span></span> |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">Thank you to everyone who shared feedback, asked questions, and explored how ABP can support your development journey.</span></span></span></span> |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
## **<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Lexend, sans-serif;"><span style="font-size: 17pt;">Sharing Our Experience on Stage</span></span></span></span>** |
|||
|
|||
In addition to connecting with attendees at our booth, we were proud to see our Co-founder, **Halil İbrahim Kalkan**, speak at WeAreDevelopers World Congress 2026. |
|||
|
|||
His session, **"Dynamic Entities in .NET: Building Low-Code Systems on Top of Entity Framework Core"** explored how developers can build flexible, dynamic applications while leveraging the power of Entity Framework Core and the .NET ecosystem. |
|||
|
|||
It was a great opportunity to share the engineering practices and ideas behind ABP with the wider developer community. Thank you to everyone who attended the session and joined the discussion. |
|||
|
|||
 |
|||
|
|||
## **<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Lexend, sans-serif;"><span style="font-size: 17pt;">More Than Just a Conference</span></span></span></span>** |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">WeAreDevelopers World Congress wasn't only about technical sessions. The event also featured interactive experiences, including a lively arcade gaming area, creating plenty of opportunities for attendees to relax, connect, and enjoy the conference between talks.</span></span></span></span> |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">This is the approach I'd recommend. It keeps the ABP story focused while giving you a natural place to include photos or videos of the arcade area.</span></span></span></span> |
|||
|
|||
[](https://youtu.be/K2WzoMfO76k) |
|||
|
|||
 |
|||
|
|||
## **<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Lexend, sans-serif;"><span style="font-size: 17pt;">Meeting The Developer Community</span></span></span></span>** |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">One of the best parts of WeAreDevelopers World Congress is bringing together developers, architects, engineering leaders, and technology experts from around the world. The conference featured inspiring keynotes and technical sessions covering AI, software architecture, cloud, developer productivity, and many other topics that are shaping the future of software development.</span></span></span></span> |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
## **<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Lexend, sans-serif;"><span style="font-size: 17pt;">Until Next Time</span></span></span></span>** |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">A big thank you to the WeAreDevelopers team for organizing another fantastic event and to everyone who visited us at Hall A, Booth A-41.</span></span></span></span> |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">If we didn't get the chance to meet in Berlin, you can always explore ABP online, join our community, or reach out to us with your questions and feedback.</span></span></span></span> |
|||
|
|||
<span style="background-color: transparent;"><span style="color: rgb(0, 0, 0);"><span style="font-family: Poppins, sans-serif;"><span style="font-size: 11pt;">We appreciate everyone who made WeAreDevelopers World Congress 2026 such a memorable experience, and we look forward to seeing you again at future events!</span></span></span></span> |
|||
|
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
|
|||
@ -0,0 +1,32 @@ |
|||
using Microsoft.AspNetCore.Http; |
|||
using Microsoft.Extensions.Options; |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace Volo.Abp.AspNetCore.Uow; |
|||
|
|||
public class AspNetCoreUnitOfWorkTransactionBehaviourProvider_Tests |
|||
{ |
|||
private static AspNetCoreUnitOfWorkTransactionBehaviourProvider CreateProvider(string method) |
|||
{ |
|||
var httpContext = new DefaultHttpContext(); |
|||
httpContext.Request.Method = method; |
|||
|
|||
return new AspNetCoreUnitOfWorkTransactionBehaviourProvider( |
|||
new HttpContextAccessor { HttpContext = httpContext }, |
|||
Microsoft.Extensions.Options.Options.Create(new AspNetCoreUnitOfWorkTransactionBehaviourProviderOptions())); |
|||
} |
|||
|
|||
[Theory] |
|||
[InlineData("GET", false)] |
|||
[InlineData("QUERY", false)] |
|||
[InlineData("query", false)] |
|||
[InlineData("HEAD", true)] |
|||
[InlineData("POST", true)] |
|||
[InlineData("PUT", true)] |
|||
[InlineData("DELETE", true)] |
|||
public void IsTransactional_Should_Treat_Get_And_Query_As_Non_Transactional(string method, bool expected) |
|||
{ |
|||
CreateProvider(method).IsTransactional.ShouldBe(expected); |
|||
} |
|||
} |
|||
@ -0,0 +1,64 @@ |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using NSubstitute; |
|||
using Xunit; |
|||
|
|||
namespace Volo.Abp.Auditing; |
|||
|
|||
public class AuditingInterceptor_HttpMethod_Tests : AbpAuditingTestBase |
|||
{ |
|||
protected IAuditingStore AuditingStore; |
|||
|
|||
private string? _httpMethod; |
|||
|
|||
protected override void AfterAddApplication(IServiceCollection services) |
|||
{ |
|||
AuditingStore = Substitute.For<IAuditingStore>(); |
|||
services.Replace(ServiceDescriptor.Singleton(AuditingStore)); |
|||
|
|||
services.Configure<AbpAuditingOptions>(options => |
|||
{ |
|||
options.IsEnabledForGetRequests = false; |
|||
options.Contributors.Add(new TestHttpMethodAuditContributor(() => _httpMethod)); |
|||
}); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Not_Write_AuditLog_For_Query_Http_Method_Without_Explicit_Scope() |
|||
{ |
|||
_httpMethod = "QUERY"; |
|||
|
|||
var auditedObject = GetRequiredService<Auditing_Tests.MyAuditedObject1>(); |
|||
await auditedObject.DoItAsync(new Auditing_Tests.InputObject { Value1 = "x", Value2 = 1 }); |
|||
|
|||
await AuditingStore.DidNotReceive().SaveAsync(Arg.Any<AuditLogInfo>()); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Write_AuditLog_For_Post_Http_Method_Without_Explicit_Scope() |
|||
{ |
|||
_httpMethod = "POST"; |
|||
|
|||
var auditedObject = GetRequiredService<Auditing_Tests.MyAuditedObject1>(); |
|||
await auditedObject.DoItAsync(new Auditing_Tests.InputObject { Value1 = "x", Value2 = 1 }); |
|||
|
|||
await AuditingStore.Received().SaveAsync(Arg.Any<AuditLogInfo>()); |
|||
} |
|||
|
|||
public class TestHttpMethodAuditContributor : AuditLogContributor |
|||
{ |
|||
private readonly Func<string?> _httpMethodFactory; |
|||
|
|||
public TestHttpMethodAuditContributor(Func<string?> httpMethodFactory) |
|||
{ |
|||
_httpMethodFactory = httpMethodFactory; |
|||
} |
|||
|
|||
public override void PreContribute(AuditLogContributionContext context) |
|||
{ |
|||
context.AuditInfo.HttpMethod = _httpMethodFactory(); |
|||
} |
|||
} |
|||
} |
|||
@ -0,0 +1,105 @@ |
|||
using System; |
|||
using System.Collections.Generic; |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace Volo.Abp.Http; |
|||
|
|||
public class HttpMethodHelper_Tests |
|||
{ |
|||
private static readonly Dictionary<string, Func<string?, bool>> Predicates = new() |
|||
{ |
|||
[HttpMethodHelper.Get] = HttpMethodHelper.IsGet, |
|||
[HttpMethodHelper.Post] = HttpMethodHelper.IsPost, |
|||
[HttpMethodHelper.Put] = HttpMethodHelper.IsPut, |
|||
[HttpMethodHelper.Delete] = HttpMethodHelper.IsDelete, |
|||
[HttpMethodHelper.Patch] = HttpMethodHelper.IsPatch, |
|||
[HttpMethodHelper.Head] = HttpMethodHelper.IsHead, |
|||
[HttpMethodHelper.Options] = HttpMethodHelper.IsOptions, |
|||
[HttpMethodHelper.Trace] = HttpMethodHelper.IsTrace, |
|||
[HttpMethodHelper.Query] = HttpMethodHelper.IsQuery |
|||
}; |
|||
|
|||
[Theory] |
|||
[InlineData(HttpMethodHelper.Get)] |
|||
[InlineData(HttpMethodHelper.Post)] |
|||
[InlineData(HttpMethodHelper.Put)] |
|||
[InlineData(HttpMethodHelper.Delete)] |
|||
[InlineData(HttpMethodHelper.Patch)] |
|||
[InlineData(HttpMethodHelper.Head)] |
|||
[InlineData(HttpMethodHelper.Options)] |
|||
[InlineData(HttpMethodHelper.Trace)] |
|||
[InlineData(HttpMethodHelper.Query)] |
|||
public void Is_Predicates_Should_Match_Only_Their_Own_Verb_Ignoring_Case(string verb) |
|||
{ |
|||
foreach (var (name, predicate) in Predicates) |
|||
{ |
|||
var shouldMatch = name == verb; |
|||
predicate(verb).ShouldBe(shouldMatch); |
|||
predicate(verb.ToLowerInvariant()).ShouldBe(shouldMatch); |
|||
} |
|||
} |
|||
|
|||
[Fact] |
|||
public void Is_Predicates_Should_Return_False_For_Null() |
|||
{ |
|||
foreach (var predicate in Predicates.Values) |
|||
{ |
|||
predicate(null).ShouldBeFalse(); |
|||
} |
|||
} |
|||
|
|||
[Theory] |
|||
[InlineData("QUERY", true)] |
|||
[InlineData("query", true)] |
|||
[InlineData("Query", true)] |
|||
[InlineData("GET", false)] |
|||
[InlineData("POST", false)] |
|||
[InlineData("", false)] |
|||
[InlineData(null, false)] |
|||
public void IsQuery_Should_Match_Query_Method_Ignoring_Case(string? httpMethod, bool expected) |
|||
{ |
|||
HttpMethodHelper.IsQuery(httpMethod).ShouldBe(expected); |
|||
} |
|||
|
|||
[Fact] |
|||
public void ConvertToHttpMethod_Should_Support_Query() |
|||
{ |
|||
HttpMethodHelper.ConvertToHttpMethod("QUERY").Method.ShouldBe("QUERY"); |
|||
HttpMethodHelper.ConvertToHttpMethod("query").Method.ShouldBe("QUERY"); |
|||
} |
|||
|
|||
[Theory] |
|||
[InlineData("GET")] |
|||
[InlineData("POST")] |
|||
[InlineData("PUT")] |
|||
[InlineData("DELETE")] |
|||
[InlineData("PATCH")] |
|||
[InlineData("QUERY")] |
|||
public void ConvertToHttpMethod_Should_Not_Throw_For_Known_Methods(string httpMethod) |
|||
{ |
|||
Should.NotThrow(() => HttpMethodHelper.ConvertToHttpMethod(httpMethod)); |
|||
} |
|||
|
|||
[Fact] |
|||
public void ConvertToHttpMethod_Should_Throw_For_Unknown_Method() |
|||
{ |
|||
Should.Throw<AbpException>(() => HttpMethodHelper.ConvertToHttpMethod("UNKNOWN")); |
|||
} |
|||
|
|||
[Theory] |
|||
[InlineData("GetFooAsync", "GET")] |
|||
[InlineData("GetListAsync", "GET")] |
|||
[InlineData("CreateFooAsync", "POST")] |
|||
[InlineData("UpdateFooAsync", "PUT")] |
|||
[InlineData("DeleteFooAsync", "DELETE")] |
|||
[InlineData("PatchFooAsync", "PATCH")] |
|||
[InlineData("DoSomethingAsync", "POST")] |
|||
// QUERY is intentionally NOT a naming convention: an action must opt in explicitly
|
|||
// with [AcceptVerbs("QUERY")]. A method named Query* still maps to the default verb.
|
|||
[InlineData("QueryFooAsync", "POST")] |
|||
public void GetConventionalVerbForMethodName_Should_Not_Map_Query_By_Name(string methodName, string expectedVerb) |
|||
{ |
|||
HttpMethodHelper.GetConventionalVerbForMethodName(methodName).ShouldBe(expectedVerb); |
|||
} |
|||
} |
|||
Loading…
Reference in new issue