Recently, Aaron and I sat down and triaged all 300+ open tickets for TimeStory (we use one ticket system to track both customer feedback and internal backlog). It took us 3 sessions, total of about 8 hours to go through them all. I now fully appreciate the amount of work required of the app as well as the level of sophistication the app has achieved already—that too natively on 2 platforms (macOS and iPadOS/iOS)! Though at times it felt tedious and exhausting, the end result was more than gratifying—
- We closed over 100 tickets (about a third of all open tickets) through disciplined review and deliberation—no details were left, no handwaving for the sake of moving through tickets quickly. This was a mix of product decisions on what to pursue and simple cleanup of redundant or obsolete tickets.
- For each of the remaining open tickets, we estimated a value/impact score as well as a cost/effort score. With this data at hand, we were able to quickly identify candidates for our next release (based on the Impact-Effort matrix).
It had been a while since I had last done detailed product-level ticket triaging (the last time I was accountable for a specific product delivery was over 6 years ago, in a corporate setting). After we had been at it for a while, I couldn’t help but notice, especially after a few hard or picky customer requests, how tempting it was for me to resort to an “easy” solution—just make it configurable. If we didn’t really have more context or understanding of what motivated the request, by making it configurable, we no longer needed to figure out the why and how exactly a user would use the new function for their own benefit. We’d simply give them the ability to implement their own use case.
To be clear, Aaron and I have always felt strongly that a software product should be opinionated, though we value every customer question, request, and interaction and use those to inform that opinion. But I caught myself a few times being tempted by the idea of “just make it configurable” so that I could move on to the next ticket. Just coming off my corporate job, I knew the symptoms and the consequences all too well. In large systems or large companies (that offer solutions for many markets, businesses, or users), configuration can be one of the most misused, most overlooked, least-governed, and the most problematic product/system areas amongst product, design, engineering and architecture teams.
Often, when it comes to anything configurable, it’s assumed to be an engineering responsibility (since configurability is also one of those “ilities” or “non-functional” system quality attributes). But as soon as you make the configuration available via UI for users to configure (as opposed to system internal configs that engineering teams manage), that configurability itself becomes UX/UI, and needs to be approached with the same product & UX design discipline as any other user feature. Unfortunately the recognition and clarity on the nature of the configuration and accordingly the shifting of primary responsibility to product & design are often missed.
Even when a user-facing configurability is led by product and design, it is harder than it seems to keep up the same rigor as other features. When it comes to a customer request, especially when the request is worded very specifically by an experienced user, almost in solution or design terms, it’s especially important to go beyond the literal ask and go back to the basics of product rigor: What’s the underlying pain point or use case? Did the user frame the request only based on existing system constraints, workflows, or even work-arounds in that very narrow context? Should the product be opinionated in this feature area, rather than leaving it to users to customize? Would a new setting cause more confusion or overhead for adoption? …
For our own products, every configuration is weighed carefully. Even as the request itself is legit, new configuration feature design may also be coupled with ease-of-use functionalities (e.g. pre-configured templates or personas). More often than not though, specific configuration requests are clarified, reframed or merged into a better problem to solve that is consistent with our product vision and principles.
Hemi.Zone 