Key Factors while Designing Enterprise Platforms - for Product Owners

Working on an enterprise level application has its own set of complexity and mammoth problems to solve. There in no better feeling than the “peacefulness that ascends”🧘🏽‍♀️when the product goes Live, and out of nowhere comes an astroid knocking us out (an email at 3AM Saturday with list of production issues). The features we least expect gets into trouble. There goes your peace of mind, flying out of the window along with that your weekend plans!!

Let me quote one such instance,

1. we had designed the email templates it in accordance with the brand theme & brand font (preset by the Branding Team)
2. we had defined all the scenarios that required email templates
3. we had the content vetted by the Product Team for each scenario
4. we had converted them to HTML Templates
5. we had tested and iterated accordingly

all went well until, we hit the soft launch. The same email templates looked different in few specific systems. The first thing the customer sees after sign-up is this email (verification/OTP) and you don’t want it to look haphazard.

What went wrong?

We found out the paid font was not pre-installed in systems was the root-cause [in this case it was Myriad Pro]. Also it looked different in Mac vs Windows even if installed, the letter spacing was different. In cases where it was not pre-installed it was showing us in “Arial”

The mitigation in this scenarios was to have a fallback font which ticks all the conditions below:

1. a font which doesn’t have licensing issues [Open Source Fonts]
2. looks similar across OS [Windows, Mac, Linux or Android]
3. looks legible to read and simple to understand
4. a sign-off from the internal brand team

Lessons Learnt!

Key Factors

The key factors for Enterprise Platform Design from my knowledge gathering and personal experience

1. Understanding the Domain

The foremost factor in Enterprise Platform Design is to understand the domain as throughly as possible. Yes, a designer may not be an Subject Matter Expert (SME), yet it is required for us to don the hat of an SME to ensure the design solutioning covers the entire 360° gamet. Most of the functional discussion from the client are filled with jagons; just a sample for you

eNACH, FDS, EFT…

after 15 minutes of meeting the client for a brief, we are lost in wilderness. If you don’t want to be lost, next time try to understand the domain before the requirement gathering phase, in some case when you don’t understand do not hesitate to stop and ask even the silliest question. Ask Away, Clear the Air, that definitely saves 1–2 production issues for which you and your team may not spend time on Fish Bone Analysis with a pot of coffee on the side; yes you may thank me later for my hard earned lessons.

2. Liaising with Internal team

The chances of having more than 10 integrated systems are always high in legacy products; some of which does certain part of the flow silently, which no one mentions in the initial brief. So always make it a point to ask,

• what are the systems current used?
• what frequency are connecting, i.e batches, DB syncronisations etc
• where does the data get archived?
• how frequently are the notifications sent?
• what are the mediums of communication with the end user?
• how does the manual data current get added to the system?
• whom do we connect to understand those?

3. Seeking help from Old Timers

The last question of the previous segment is quite important, coz there is always a guy who has been there in the process for a long time. He/she knows in & out of the system. FIND THEM, your requirement gathering work is half done.

4. Frequent Reviews with Stakeholders & Business Teams

Never wait for the design to get polished (visual design) to be shown to the clients. Start colloborating as early as Task Flow/Journey Maps/Rough Sketches, there are lots of insights that can be derived in the early stages of discussion that brings the refinement and clarity. It is okay not to have clarity on next step during the early stages. Only with multiple discussions do we gainfiner inputs that were not part of the requirement document. Believe me the requirement document is never complete till the product goes live…. its a vicious cycle 🫣

5. Technical Details

Never shy away from technical details, for instance, put yourself even in the Database Architecture discussions. The insights that I have gained from involving myself are endless, it gives and over all view of how the data derived from the end-user gets translated in each stage — and how is it consumed by other system.

How many decimals does the lat & long require to precisely bring the address for the user or how it translates to accurate pricing is not something you understand seeing the visual design or screenshot of existing system. GET TO THE ROOTS!! roll your sleeves and dive deep.

You are warmly welcome to share your experience with enterprise product designing in comments!!

For queries or business collaboration you can reach out to us at hello@uxmint.in or visit our website www.uxmint.design we are happy to connect.