Pages

Saturday, September 5, 2020

Lessons as a product owner: adding touch-screen support to a new enterprise UI

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.

This is a photo by my colleague and UX practitioner 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.

Own it

The earliest User Experience vision, direction, and designs mentioned touch support for this new user interface. And though the existing or now "classic" UI did work for some touch scenarios, it wasn't specifically designed, built, or tested against touch devices.

Several sprints into the implementation, the new UI mostly worked with touch scenarios though stakeholders and my development team had opinions of what we should do with touch including:
  • 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.
In this kind of "chicken and egg" situation where people aren't interested in a feature because it doesn't exist and it doesn't exist because people haven't been interested, it's a good time to take a step back and remember you're the farmer, or perhaps geneticist. You have a stake in both chickens and eggs. You can introduce a new feature as well as influence interest in it, though it takes a bit of research, communication, and expectation management.

Research and negotiate

With several diverging approaches to consider my lead UI developer and I did two things.
  1. 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.
  2. 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

Based on the available research showing some tentative interest in having editors use our CMS on mobile devices as well as mixed adoption of non-laptop/desktop devices in enterprise organizations, we made it clear within the team and stakeholders that:
  1. 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.
  2. 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.
  3. 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.
I could have pushed for even less support, or even abandoned the requirement altogether by committing to just desktop support. But considering the costs to get this feature was not that hard and editors could work with our system outside of the office (we made these decisions before the Covid-19 pandemic) it was still a valuable feature. Also, the fact that the design already looked like it should be touch-friendly with ample space, breathing room, and checkboxes in its various lists risked disappointment by visually suggesting a capability that wasn't supported!

On the other hand, I doubt I could have pushed for an even more mobile device or touch-screen friendly UI. I wasn't going to risk not having any UI to be able to try to design and address for desktop, tablet, and mobile screens. I'm sure if I tried, there would have been well-justified pressure from both management and my developers if I was making a good decision. Ultimately, being a product owner with the right and responsibility to accept stories (or not) means you have control over your requirements though you still have to manage expectations and constraints on what you can realistically deliver.

Be agile

Our enterprise software is still deployed to on-premise customer installations. Though we follow scrum as our agile method, we still have a stabilization phase of a few sprints before releases which may occur every few months to about a year or so.

I've learned that to be able to release in good quality unless you have money to burn and flexible release dates (both of which may be in short supply in enterprise software development), it's best to build the minimum end-to-end experience needed to making something work to start getting feedback. You'll find out sooner-than-later that the back and front ends as well as other components connect correctly (or not) as well as get valuable customer feedback.

Sure, keep future scenarios in mind. And perhaps taking an iterative, agile approach might cost more in the long run. But you cannot predict how everything will go nor how customers and end users will react to what you deliver. As an example, while working on a screen that showed the publishing status of items in our CMS, we confirmed edge cases with our architect and developers and came up with a fairly "sophisticated" screen that had refresh options to check the targets for each publication.

One look by our partners had them asking, "wasn't this supposed to be a simplified interface?"

Luckily, with just some time spent on design but nothing implemented and no quality assurance (QA) needed, we were able to create a much simpler screen, better for both us and end users. This scenario happened several times where we were able to adjust or tweak our designs or implementation as we went along, rather than all at the end.

Similarly, with touch support or any other non-functional requirement, every additional scenario and use case we added meant we had to design, build, and confirm it works across our supported browsers using touch, mouse, and/or keyboard. Each story has downstream not-so-hidden costs. Every difference to layout, interactivity, or behavior meant yet another thing to confirm and validate and test, both from a quality assurance as well as a usability perspective.   

Steer enough and in time

I had a great experience steering a friend's boat in the canals around our past home in Nieuwegein in the Netherlands. My friend, the skipper (captain) explained that while keeping an eye on the horizon, you can tell if you're on course and how much you're drifting one way or another. You want to be on the correct side of the buoys, avoid the shoreline, and maintain space for course corrections such as avoiding a barge or other vessel.

If that tree way off in the distance is rapidly moving to the left compared to a spot on your vessel, you're turning too hard to the right.

For the new UI, we didn't quite run aground on the rocks of touch screen support, but we did get to a spot where we started gathering more iPad Safari-specific bugs than I'd care to admit. And this list of issues started competing with the rest of the work we wanted to finish.

To help course correct and for the sake of transparency and "alignment," I raised our status with product management and our quality assurance manager, who managed the QA engineers on my and everyone else's team. Ultimately, we got what we needed as we confirmed we would keep the touch requirement, document any remaining known issues, and prioritize these touch-related bugs against everything else that needed to be built or fixed.

In hindsight, I probably didn't need as many meetings. I already represented our user personas to my development team and was connected with management. I was already in a position to decide and communicate what's in or out and to prioritize touch-related bugs against everything else.

So in the future, I'd take the time to have more alignment meetings upfront, fewer meetings in general, more actions, and a smoother blend of stubbornness and flexibility. I would revisit basic expectations in the form of the team's definition of done and acceptance criteria, especially as teams or team members change.

I've learned to keep stating your expectations and asking for the team to build and test requirements until people make fun of you for it.

In the end, like a good skipper, I've learned to better steer where we're going by owning requirements while following an agile approach for minimal, iterative improvements. Keeping an eye on the horizon lets you make smaller adjustments along the way. If everything and everyone was predictable, you wouldn't need agile, nor perhaps a skipper.

That's about it on the lessons I've learned on owning a (touch-screen support) requirement, being agile, and "continuous steering." It's probably worth noting that we also tried to avoid the sunk cost fallacy, though that could be explored in a future post on some of my past "mistakes" which were probably (hopefully) successes in disguises.


Here are some "meta" notes on this post and its capitalization for title and headings:
  1. 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.
  2. 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.

No comments:

Post a Comment