My latest product release introduced touch-screen support as part of a new user interface for an enterprise product that's been on the market for nearly two decades. The idea of improving the interface of this particular Content Management System (CMS) to meet modern user expectations using today's UI technology approaches was desired, expected, and perhaps overdue. However, touch-screen support as a non-functional requirement had a more contentious start that needed a bit of attention from user experience (UX) design, development, and quality assurance. As a product owner, I had to own the requirement to set both internal and external expectations for what it meant exactly.Luke Chen, showcasing the mentioned UI working on my iPad. The ultimate design and implementation changed a bit, but touch-screen support was ultimately delivered with the release.
Clarifying, measuring, and prioritizing touch support, especially in the last few sprints before an on-premise release, was a challenging yet interesting exercise. I've learned a few things that might be useful for your (or my) future projects and product releases, especially for product owners working with cross-functional agile teams.
The lessons for this and similar requirements have been three-fold:
- Own it. A requirement isn't a requirement unless you (as a product owner) require it.
- Be agile. Keep it lean and nimble. Each feature or change has downstream, not-so-hidden costs.
- Steer just enough and in time. More alignment upfront. Fewer meetings later. But more reminders on what's acceptable.
- Mobile scenarios seemed interesting from a sales and marketing perspective (with several hypothetical scenarios suggested mainly around review and publishing).
- It's more effective to consider and build for responsive touchpoints upfront rather than later!
- Touch-support is distinct from support for specific devices or even browsers on specific devices.
- We were getting some interest from customer's managers for mobile device support.
- And there were some examples and interest from actual editors for the feature.
Research and negotiate
- Research. I reached out to our marketing intelligence analyst to gather what analyst reports we had on device adoption in the enterprise, did a few online searches myself, and started talking to customers about their interest in our UIs supporting devices.
- Negotiate. Our UI developer lead started negotiating an exchange with management. We would avoid Internet Explorer support for our React-based UI in exchange for devices to test iPad (9.7") browser and eventual touch support.
Decide and then inform stakeholders
- Limited touch-screen support was in. We would explicitly design for touch in general while testing against, and eventually supporting, iPad 9.7" devices (iPad pro and standard models). Though the market research showed Android devices outnumbered Apple, we weren't going to test all Android form factors nor try to have devices ready to replicate customer issues on any touch device.
- A fully responsive UI was out. I didn't see a strong use case for completely mobile scenarios, at least not yet. It also didn't make sense to spend too much time investigating, designing, and testing for the review or publishing scenarios suggested, especially since we didn't have an end-to-end experience. I made sure to confirm the suggestions were insightful and valid, but not the most important thing to tackle at the time.
- After confirming we're not far off from a touch-enabled UI with some additional testing, we'd continue to design, build, and test for touch support with the idea that the basics like navigating, interacting with the UI, and editing in the CMS would work, though we wouldn't over-optimize the touch experience.
Steer enough and in time
Here are some "meta" notes on this post and its capitalization for title and headings:
- As a post on alvinreyes.net as opposed to createandbreak.net, this post is sharing a bit on my own journey, lessons, and advice with product management and specifically my recent work as a product owner. Though astute readers or those with access to Google can easily infer which product I'm specifically talking about, this is less about that product and more about product thinking or thinking about products.
- The same unmentioned product started following sentence-based naming conventions for things like labels in the UI. Though I'm used to Appropriate Title Casing, apparently this is a thing in the blogosphere (see this post by Brian Jackson from Woorkup) that I'd also like to try.