Multi languages design can be tricky at times. This is because of the way how natural languages are structured. In some cases, you may have to design to group the languages or separate the design. This are some considerations and impact you may face while developing for multi language support.
Careful of your Layout
A common but annoying issue from multi languages support is the length of text. This can totally screw up your layout design. There will come a stage you may have to css for a specific language due to the long text. Another common occurrence is the font size and type. The type of languages used will impact the selection of font size and types. As a rule of thumb, go for simple layout and standard font type and size.
Defaultor User Specific Language Locale
Another consideration is to determine if you are going to allow default or user specific languages setting. Majority of application captured user language preference to individual users. However, this may be applicable to secured applications. For public settings, you may consider to use browser language locale or allow a one time setup. These preferences are usually the options you can configure or develop. So, you should select the options that suits best.
Multi languages development will incur additional efforts and considerations to layout and user preferences. It is best to setup multi languages from start. This way, you could determine if your support for multi languages are sufficient.
Self service technologies are getting popular with COVID-19 pandemic. This is due to a demand on contactless services. Imagine calling customer service and being put on hold for a long time “Customer service is busy…”. This brings a lot of dissatisfaction to customers. This is why many business are moving towards a self service approach using Chatbot.
How to Self Service with Chatbot
In face to face customer service, there are usually a few types of intentions. Enquiries, service requests and complaints are the key ones. Thus, you can implement such intents into your Chatbot. FAQ (Frequently Asked Questions) can be supplemented for enquiries. Preliminary input gathering can be done for services requests and complaints before engaging live chat.
Chat application is user friendly and intuitive for all groups of users. You can reduce costly complaints page and focus on developing complaint Chatbot. Subsequently, majority of common enquiries can be handled by your FAQ Chatbot. This improve your customer service responses with specific requests.
The time is ripe to invest in your Chatbot and reduce reliance in your old complaint web page or feedback form. The Chatbot will enhance your customer service with self service. Overall, this will greatly improve your customer satisfaction.
If you have done many application projects, it is common to find that exceptions are often being provided as a rule by users. This is a key reason for major scope creep when you try to cater to exception. Is exception a rule? Can this be considered as a rule?
Exception is a Process
The first approach to exception handling is educate users that exception is a process to be managed. It is not a rule that system is able to followed. A rule existed from known set of variables. On the other hand, exception represent special scenarios and unknown variants. Thus, this distinguish exception from a being rule.
Exception is Unpredictable
The second key characteristic of exception is the nature of occurrence. It is unpredictable and sporadic. In fact, some exceptions break the established rules. This is where users demand that exception be made as a rule. That exception will conflict with existing rules. If you attempt to fit the exception as a rule, scope creep will occur.
User education is important to distinguish exception from a rule. Exception often break existing rule and must be handled as a process. Usually, users cannot determine the frequency of exception. After all, exception is not a rule!
Many users or sales have the misconception of pleasing customer with promise of customisation to your system. However, this is not true as some services are better to be standardised and cost efficient. There is also a limit to please your customer without hurting your bottomline. What are the guidelines to avoid customising your system?
A Product View
Moving your business towards a product view is the first step to understand your customer base. A key reason of customisation is the fit of your product to customer needs. A poorly fit product will result up in a lot of customisation. You must adapt your product to fit the your targetted customer base. A well designed product should have a deviation of 10% customisation and 10% localisation.
Know your Customers
When you have decide to establish your application as a product, it it time to categorise your customer base. Your understanding of customers are important to refine your product into various types. High-end and well-paying customers can be provided with all the bells and whistles in applications. In contrast, you may not want an economic customers to be using your full featured product.
The basic guideline to stop the customisation trend for your application is to start thinking like a product. With a product view, you can position your application to each customer base. This will reduce your cost and increase your customer satisfaction with a better fit of product at valued pricing.
Standardisation is taking shape in place of cusomisation as organisation move to reduce exponentially cost in technologies. The mindset to customise is outdated and not cost effective. Digital Transformation is driving these standard approach in the form of Agile Templates.
Resistance is Futile
The efforts to standardise will be met with a lot of user resistance. This is a normal human behaviour that must be taken into consideration for all standardisation project. There will be a lot of comparison between customised featues and the standard ones. Often, lots of behavioral efforts will be expected to resist and lament against standard features. Ultimately, benefits outweighs customisation in terms of cost and maintainability. Users must be educated or be realised that resistance is futile.
Tips to Standardise
There are a few tips to smoothen your standardisation project easier. Many of the tips will involve mindset and behavioural acceptance.
Find a strong sponsor and champion to drive the user acceptance.
Remove or deny users as key stakeholders if they are too negative or unsupportive for standardisation project.
Assign a SME (subject matter expert) with deep knowledge of change management and business process re-engineering.
Standardisation projects are not technically challenging but more on change management and business process changes to accommodate customised features. Strong user resistance must be broken down or removed as a key critical success factor for such projects. Good champions can help drive the success and gain management confidence in your standardisation approach.
Digital Supply Chain (DSC) will be gaining a big leap due to COVID-19. As part of social distancing, there is a huge reduction in physical transfer of goods. This leads to various digitalisation outcome. Many of goods and services emerge and evolves into Digital Supply Chain. These industries are involves high touchpoints like media, publishing and education.
Parts of DSC
Digital Supply Chain have similarities to Supply Chain. The key parts will be the focus on digital components. These main parts comes together to form the Digital Supply Chain.
What it Means for Consumers
Goods that can be provided in digital format can be sold quickly via online platform. Consumers will need somewhere to store and access their digital goods securely. Suppliers can extend its reach to get digital goods via supply chain network. A major breakthrough is the usage of NFT (non-fungible token) for Digital Arts, games, music or even collectibles.
We will see more of digital supply chain as I look forward to buying more digital goods. This helps save physics storage space and digital goods can be easily shared to my family.
Transportation rate model is becoming an automation for many TMS (Transportation Management System). However, rate model is not commonly adopted in Asia countries. One reason is the different transportation rating methods in each Asia countries. This leads to many customisation.
Common Transport Rate Model
These are some of the most common rate models you can design for your TMS.
City to City
Zip to Zip
Volumetric, weight or volume
Duration e.g daily, monthly
Equipment e.g. truck, chassis
Why Rating Model
Rating model goes beyond system design. Sadly, many rates by sales team are done in isolation with consideration to TMS. Using rating model have many advantages like cost reduction from operational efficiency, automated computation and financial settlement. This model are proven is eCommerce and eLogistics companies who are pure play digital.
Many traditional logistics providers remains entrenched in paper rates while their digital counterparts enter the logistics with rates digitalisation. The digital transformation of rate model remains a constant challenges for many. A major reason is due to user resistance to digitalise and mindset to change. Do realise that rates is no longer an IT or sales task but a collaborative efforts.
Today, I encounter another interesting requirements which state “depends on customer”. Being in project implementation for so long, I am still amused by this response. Why are there such requirements? Do not be surprised as such response is actually very common in Asian countries.
关系 as requirements
Asia cultures plays a big part in influencing the customer requirements. The “关系” aka as customer relationship is an unseen and very strong force. This practice is much prevalent in China, Japan and South Korea. It is no surprise that requirements can change upon customer requests. Naturally, it create challenges for the organisation as system is driven consumer customisation.
Customer is King
“Customer is King” is very common in Asia. With lower switching cost and labour cost, customers tend to be more fickle minded in Asia than American or EU countries. With the differences of leverages, organisations tends to accommodate customers for quick wins. Digital transformation also make it easier for customers to migrate their data across different platforms.
In Asia, requirements are driven largely by cultures. Power is a common play by customers to get what they wanted and as requested. You will usually need local help to elicit and mitigate such requirements. Only then, you can satisfy your customers and gain their trust.
Have you ever meet user who like to ask if this or that can be done to change the system? That someone will also like make recommendations to the system. An age old answers to them is always “Time Scope and Cost”. It is usually easy to make suggestions or recommendations without such constraints or understanding of the system. So, how should we deal with it?
The Ignorant User
Some user will always be ignorant and oblivious to the basic of “Time scope and Cost”. For such user, the best way to handle is a detailed SOP (Standard Operating Procedure). With SOP, everything is documented with full transparency. If it is a product constraint, you can also state it clearly. All communication will need to formalise to prevent repetitive explanation with the ignorant user.
The “Want It All” User
There is another set of user who wants every features and yet having non existent scenario or test cases. This is the dreaded scope creep where development team waste valuable time designing for non existent requirments. I often apply Agile and scalable solution to handle such user. Agile allows your solution to scale if the “said” scenario occurs.
In every projects or production support, there will always be users who falls under the above categories. They usually have no understanding of time, scope or cost. You can easily be transparent and show your SOP. Do also consider applying Agile and design your solution to scale easily.
Localisation is a key component of TMS (Transportation Management System). Legacy system suffers from language localisation partly due to database design which forces the implementation to be encode in certain locales. Globalisation of application creates new solution architecture which default localisation. One of such settings is the configuration of languages and display text.
One may think languages in system is pretty straightforward. However, to a system, English does not literally mean English? Due to complexity of languages, we seek some sanity to classify languages in system. One of such classification is ISO 639. However, this is not the standard adopted by system due to different computer organisations. For instance, Windows language encoding will vary from that in Linux. The application SME (Subject Matter Expert) must be familiar with language localisation encoding across various platforms.
Future Language localisation
At present and in near future, we will see NLP (Natural Language Processing) gaining popularity like Chatbot. There will be focus for system to localise naturally from user behaviour and geolocation. Translation are real time and ML (machine learning) driven. Data locales are no longer required as data can be stored as what it is and translated as such.