# end-user-experience Published articles for end-user-experience. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## What matters when anyone can build DevFeed: [What matters when anyone can build]() Original publisher: [Read original article]() Author: Yuhki Yamashita Published: 2026-05-22T16:30:00Z Content type: opinion Language: en Sources: [Figma Blog]() Topics: [Artificial Intelligence](), [Figma](), [User Experience]() Tags: [ai](), [building](), [end-user-experience](), [figma](), [product]() ### AI overview The article argues that as AI makes product building faster and more accessible, the key advantage shifts from speed to deciding what is worth building. It recommends exploring multiple directions broadly and developing them deeply into concrete end-to-end experiences before committing. ### Source excerpt If AI can make anyone a product builder, the real edge is knowing what's worth shipping. ## Continuous profiling at Mercado Libre: Turning flamegraphs into fixes DevFeed: [Continuous profiling at Mercado Libre: Turning flamegraphs into fixes]() Original publisher: [Read original article]() Author: Elton Hoffmann Published: 2026-03-11T01:27:33Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [observability](), [Tooling](), [Microservices](), [Latency](), [systems]() Tags: [ai](), [article](), [efficiency](), [end-user-experience](), [flamegraph](), [garbage-collection](), [latency](), [memory](), [microservices](), [observability](), [performance](), [performance-engineering](), [platform-engineering](), [profiling](), [uptime]() ### AI overview Mercado Libre describes building a continuous profiling platform for about 35,000 microservices. The platform treats profiling as an observability signal alongside metrics, logs, and traces, with the goal of helping teams detect performance issues and automate fixes for certain issue classes. ### Source excerpt We continue our series on Performance Engineering at Mercado Libre. In previous articles, we discussed how we crafted an observability culture across the company, how performance relates to other observability signals, and how the Performance Engineering team partners with Business Units to enhance platform efficiency. Today, we'll show how we built a continuous profiling platform for 35,000 microservices and how we started turning profiles into automated fixes. Context Our goal in the Performance Engineering team is threefold: to ensure uptime; to improve the end-user experience by reducing latency; to reduce computing costs. As a cross-functional team, we usually work with application owners to achieve these goals. In our two years of existence, our joint efforts have taken us through countless incidents and bottlenecks. Each problem is unique, but over time, we've seen some common patterns: high memory allocation, lack of garbage collection (GC) tuning, thread pool saturation, blocking I/O, and heavy workloads processing repeated tasks. Image 1: Typical flamegraph of high CPU usage replacing string patterns Trained eyes spot these signals quickly. But two eyeballs won't scale to thousands of services. Mercado Libre is an ever-growing company, with about 35,000 microservices, 30,000 deploys per day, and more than 16,000 people in IT roles. What are the odds that a performance issue found on one microservice doesn't exist in another? Or at least a similar issue? We often encounter systems with issues that are easy to fix but hard to detect (unless you have the right tools). It became clear we had to scale. We needed a platform-level solution that would let teams self-diagnose and self-tune. By the end of this article, you'll see how we built that and how we now automate both detection and fixes for certain classes of issues. Continuous profiling After setting our goal to improve performance tooling, we developed our own continuous profiling solution. Why profiling, ## Human-centered Software Development DevFeed: [Human-centered Software Development]() Original publisher: [Read original article]() Author: Headspace Published: 2021-05-27T20:52:21Z Content type: opinion Language: en Sources: [Stories by Headspace on Medium]() Topics: [Development](), [User Experience](), [Software Engineering](), [interfaces](), [Code](), [App]() Tags: [developers](), [development](), [end-user-experience](), [engineering](), [experience-design](), [interfaces](), [software](), [software-development](), [software-engineer](), [user-experience](), [user-experience-design]() ### AI overview The article argues that software development should be human-centered because developers are users of the code and systems they build. It applies user-experience principles to the development process, emphasizing code readability, maintainability, and attention to engineers' human factors. ### Source excerpt Build stronger software by designing for human interaction Author: Edward Park, Senior Software Engineer Creating software is a human-centered endeavor. The software that we build is used directly by human users. Whether we're building a mobile application, service, or tool, the cumulative moments of delight (or abhorrence) that our human users experience determine the efficacy of the software we build. For this reason, software organizations invest in user experience design, in addition to the nuts-and-bolts of the technology under the hood. Product designers leverage their expertise in interaction psychology to create user flows that are useful, familiar, and discoverable. Designers understand that application interfaces are only as effective as their users find them to be useful. Therefore, the best user experiences incorporate visual components that facilitate task completion while working with the psychological heuristics that humans intuitively employ. Humans seek sensory cues and constraints to navigate a deluge of stimuli and process large amounts of information, and we do so while interacting with computing interfaces as well as the real world. In essence, software organizations are constantly trying to optimize how humans interact with computers. Today, the practice of using design to hone user experience is predominantly applied to visual interfaces. These are commonly the front ends of applications, where humans interact with the visually rendered software (in a browser or mobile app). What about the act of software development itself? OUR FELLOW DEVELOPERS ARE USERS, TOO Most observers would think that software development strives to translate human instructions into machine-understandable directives in a reductive, one-way communication flow. We are "programming" computers to do our bidding, and we do so with cold, logical artifacts composed of code modules. While the software itself is mostly evaluated against human experiences, we compartmentalize th