All organizations make trade-offs to get where they are. To meet its near-term goals, your organization had to make tough choices about what to prioritize vs. defer, which best practices to follow vs. shortcuts to take, and when to invest in the team vs. make do. Your team has made progress, and that’s good. It’s also accrued tech, design, product, or organizational debt that’s standing in the way of its next success. Organizations evolve, and it’s not always obvious that what worked before isn't working now.
Last summer, Figma introduced variables as a beta release, giving us designers a major leg up when building prototypes. However, it can still be hard to get a handle on just how to use these new features. While Figma has produced some good guides and a helpful playground file, I’d like to share a more practical example from a recent project.
You’ve built your business on a large rock, it has served you well over the years, buuuut... technical debt has accumulated everywhere around your applications.
As designers getting up to speed on a new client project, we often feel the tension of designing quickly to earn trust, and designing to provide lasting value to users and the business. We want to be partners, not just another resource to be called upon when desired. But how can we smoothly transition into this partnership?
Product vision can be a powerful thing. It tells a story of what’s possible and pulls people toward that change. A lack of vision can be insidious. At its best, it leads to missed potential. At its worst, it can lead to unmotivated, burned-out teams and a disjointed product that fails to deliver customer value.
A client of ours has a long-lived React application using an architecture that was common at the time of its creation: Redux with thunks and sagas, with Redux Form powering the majority of forms throughout the UI, which is rich with input fields. To those familiar with this combination of technologies, you might immediately understand why they reached out to us to help fix their app’s performance issues.
People say "technical debt" like it's a bad thing. But those who are serious about software development know that this game is all about managing technical debt. Technical debt is a natural part of the landscape in any software development team’s world. It's neither good, nor bad. Yet when trade-offs are mismanaged, technical debt is likely to cause your productivity to grind to a halt. For people who hit that point and wonder why - there should be no mystery about what causes technical debt, the answer is right in front of you.
While the world of office work has changed for us and many others since we first released Lunch in 2016, the app itself has been happily chugging along, attracting regular users and helping teams with one of the most pressing questions of the day: where’s lunch?
If you use the browser development tools, you've likely seen the request timing information on the Network tab. It shows how long it takes for web pages and their components to load. But did you know that servers can also send their own timing information? They can do this with a header named Server-Timing. Modern browsers can show the server timing data next to the client timing data on the Network tab. This can help developers find and fix server-side performance issues such as N+1 queries. You can read more about the Server-Timing header's specification in the W3 working draft, or on Mozilla’s documentation site