Solving “unsexy” problems

What to expect when designing enterprise products?

Published in

Prototypr

7 min readNov 19, 2017

https://pbs.twimg.com/media/BzSb6XYCYAA9ODv.jpg

I started my professional design career as UX researcher, however, the desire for more hands on design challenges introduced me into a world of entirely new products. Not just any product category most designers aspire to work on, but the often intimidating and commonly labeled as “unglamorous” world of enterprise products. The popular perception is that enterprise products are “unsexy” (read boring or not cutting edge) and have no room for creative imagination. I was told on multiple occasions that this will turn into a greek tragedy. Well, after working for more than a year on the log analytics based Network Monitoring solutions in Azure (Microsoft’s cloud based service platform), I can clearly say it has not been a bed of roses (no commercial product is for that matter) but that didn’t stop me from learning and growing as a designer. My peers, friends, and other fellow designers often said that it is discouraging working on business-to-business (or enterprise products) and strive for some kaiser souzai type “cutting edge” solution that will look good on the portfolio. I would like to remind everyone that a vast proportion of UX designers work on enterprise products all over the world with many of them starting their professional careers with these products. Therefore, it is likely that every other design aspirant we come across might be working on these products in near future. I thought it would be appropriate to pen down my experience. Here is a heads up of things to expect when you are designing for large and complex enterprise products.

Leaving your comfort zone

Mekin Maheshwari, founder of Udhyam Learning Foundation talked of a concept called “schema distortion” in a talk I attended some time back. It implies that maximum learning happens when a person changes the environment they are in, instead of working in a predictable loop of things. I can definitely say that working for the enterprise “distorts” your schema in more ways than one. In my case, not only did I have to develop a deep understanding of Network Monitoring, I had to step into shoes of users who were not easily accessible. This was a stark contrast to some of my previous products wherein it was easy to hypothesize scenarios and concepts because either me or someone I might know could be the user of the product. I also learnt what it is like to lean on team members like product managers who act like domain experts and fill you in with the missing pieces of the use cases and scenarios when the user is not someone you can relate to easily. Think of it as trying to design a flight cockpit when you have little or no knowledge of aviation or what it takes for a pilot to fly a plane. One thing that comes handy here is how you build your professional relationships with product managers because they will have to be highly patient when you ask seemingly naive questions.

Moreover, the popular myth got busted that innovation is a limited privilege of the so called “cutting edge products”. There is so much more opportunity in the enterprise world to bring radical changes as not many products have risked experimenting with new designs. I would like to highlight that each right design decision in an enterprise product enables large scale organizations to save time, effort, and money. As a designer, it is indeed a fulfilling experience making this contribution.

Simplifying complexity

I work in a design team where folks are working across a multitude of products. However, I rarely come across those who are interested in learning about what I do. In the beginning, whenever I would start to explain my product, my peers would lose interest in a few seconds. This taught me one important thing, people (including me) have a very small attention span so I need to simplify concepts for the manner in which I understood them in the first place.

I often use simple analogies to explain the schema of my products and try to change the language of it depending on who my audience is. We all know that if you want to learn Sanskrit, you translate it in your own native language first. My experience was no different.

The need for simplifying not only applies to explaining your product but designing the product as well. Products which already have a constellation of competitors in the market, often borrow complexity from existing products, assuming the users are accustomed to the mental model that exists out there. It is indeed embarrassing when product teams assume that their users are dumb and will absorb whatever we throw at them. On the contrary, most users are enterprise products are trained professionals with taxing responsibilities. It is important to address this aspect of enterprise users as well, which is easier said than done.

Dealing with a non-demanding user

“The user can live with that”, or “they will figure it out” is an assumption we make even when we know that our experience might be faulty and unsatisfying. As I mentioned earlier, it is wrong to assume that the user can’t figure out problems. I sometimes feel trapped because this can actually be true for a large number of B2B users who have very low expectations. They are used to following a particular schema, forced upon them by the products, their enterprises have subscribed to, even if it is unintuitive.

It is a classic case which Henry Ford brought forth when he said, when you ask someone using a cart what more do you want and they would reply by saying a faster horse. It is here where a designer can break these traditions and try things out of the box, while being in it. Yes, the experiments may fall flat sometimes. Your hunches may be totally incorrect but that is where the designer must muster motivation and keep going by learning from mistakes and blunders and work towards the ultimate goal of a better designed product.

The truth is, our users can actually live with that because the least they expect from a product is that it works and doesn’t waste their time by being buggy. They don’t have high expectations from the experience and are even willing to learn unintuitive product flows. This makes designing for these users all the more challenging as the entire team has user experience in the bottom most priority and issues are fixed only when ‘enough’ users had cried foul.

Users don’t have to live with that. A designer can bring forth ideas which push them to dream beyond what is being offered.

Locking horns with legacy

Some products were not built in a day. It takes years to arrive at where they are today. Especially, some enterprise products, which act as the mother ship for many smaller products & services running on them and are rife with inflexible standards and protocols. Legacy in design, in this case, becomes that bounding box in which the designer is often forced to think. To propose small niceties in design you might have to go through a very structured procedure as even a small change can raise eyebrows at various levels. Sometimes you might end-up putting band aid on something that requires surgery due to external limitations or undiagnosed internal injuries that manifest themselves at later stages. This is where persistence plays a very important role. You need to prove your metal as a designer in your team and convince them the importance of your perspective and uniqueness you bring to the table. This also refers to winning small battles even if you don’t win the war. You will face roadblocks and continuous loss might wear you down. But I can’t recall any other domain where you will not face similar roadblocks. It’s a part of any professional endeavour.

Communication also has a big role to play if you have dependencies on teams spanning across geographical boundaries. But trust me, if you are able to even make the smallest of impacts, it will be a bittersweet reward that can keep you going in the long run.

Need for Speed

The way to go forward in the product design world is agile. However, there is a possibility that you might be disguising a waterfall model in the name of being agile. This can move things very slow if you are a part of a titanic of a product and also allow little agility over time. But what you will take out of this is what it takes to actually be running a titanic and yet avoid the iceberg. Large successful products are difficult to come by and it might be correct to assume that smaller teams have it easy because of lesser dependencies. It is imperative that you draw realistic expectations to limit your disappointments. Define those wins for yourself. It could be as small as convincing your product team to take more time to ship the concept rather than a half baked MVP due to the technical limitations in the team at that moment.

In conclusion, large enterprise products can be a very difficult challenge in themselves because you are not only dealing with complexity in your product but also your team. User experience could take a back seat due to a variety of reasons. As a designer in the enterprise world, I would say take pride in what you do and remember that not many can do what you are accomplishing. You might also have a need to evangelize your work, process and often go out of your way to manage and win the trust of your team. Remember you are one among many who can steer this gigantic ship and take it to new shores.