My Top 10 learnings from Designing Conversational Systems and Chatbots

My Top 10 learnings from Designing Conversational Systems and Chatbots


”In the old days, we didn’t write the way we talk because there was no mechanism to reproduce the speed of conversation. But texting and instant messaging changed that—and a revolution has begun.”


The truth is that conversational systems and AI have shaken the marketing and technology worlds because they brought the focus back to the customer. Adoption of these systems may be difficult but, in most cases, it is necessary.

Why? … Because, through a conversational system, we get a unique opportunity to design a highly personalised user experience which is available in very few other user-facing systems.

Designing such a system involves automation, personalisation, and ideation of the experience and expertise of the domain to make the system powerful.

Below are my top 10 learnings which must be kept in mind while designing a conversational system:

1. Decide the Journey of the chatbot:

The journey of the bot is key to a successful conversation – It must be intelligent, intuitive, flexible and easy for the user. The message structure, sentences, questions, and compliments must be planned in the flow with a deep understanding of the user problem that the bot is supposed to solve. Plan both guided as well as free flows throughout the journey. Differentiate your conversation experience by designing it to fit your customer’s journey.

2. Remembering the User Context:

This is actually one of the most important aspects of conversational design. Try not to lose user’s context throughout the conversation and be able to refer to it at any point later on – the user will fall in love instantly if you can deliver on this one. The underlying platform architecture and deep knowledge of the industry domain are the two critical success factors that decides how easy or how difficult this can be during implementation.

3. Align to the User:

Bot should be smart enough to align itself to the user’s style. This is key to personalisation. For example, if user sends emojis, the bot should respond with emojis; If user is using exclamation a lot, the bot should also use exclamations. This is a bit difficult if one attempts it at the beginning itself but with time it can be achieved.

4. Give a Personality:

As Vittorio Banfi from Botsoceity puts it – “The personality of your chatbot is like the colour of your website. You can NOT pick a colour”. A common problem in giving personality to the chatbot is that a company always has more than one customer avatars. Does that mean you will have two completely different chatbots within one company? It would be a better idea to ask the users who they are or where they came from and thereby adjusting their experience accordingly. The truth is, like every customer and all human beings, chatbot too needs a distinct personality.

5. Learn and Adjust:

There is no perfect conversation in this world because the “perfection” varies with perception. There is always scope to learn from misunderstandings and adjust the conversational system. The key to a good conversation is how your bot learns and fixes it’s mistakes. Train your bot how to self learn and adjust by building it into various dialogs and providing a dependable knowledge base on which it can fall back on. Using ‘disambiguation’ to train the bot can help a lot in building a successful conversational system.

6. Design with Scale in mind:

Make sure the code base, the conversation flow, messages, and personalisation are built for the future. Think about how the same system can be used by another set of users and different languages in various markets.

7. Switch to human:

Whilst AI is still in its infancy, the chatbots will undoubtedly have problems. Thus, having a fallback to real people can help and delight you and your customers at the same time.

8. UI smooth as butter:

The face of your bot is the UI. Any experience you design for your system is heavily dependent on the user interface it is presented on. The UI for your bot must be clean, fast, interactive and easy to work with. Ease of use may be invisible, but its absence surely isn’t.

9. Fail fast:

In a conversational system, failing fast is very important. Failing in this system will not be the technical errors or bugs but any unexpected flows which leads to an abrupt end that must be adjusted instantly.

10. Design for multiple channels:

keep in mind that messaging platforms are proliferating at a rapid pace. You have Facebook messenger, Skype, web that supports bot technology today and surely Whatsapp, WeChat and many more will follow soon. Your conversation design should be such that when you switch to new channels, you don’t need to rewrite the code or redesign the conversation experience.

In summary, Want your users to fall in love with your bot? Make your bot fall in love with your users.
Curious to know more about how we do things at Reach out to me at and lets start a conversation…

Author: Puneet Joshi (

10 Tips for becoming a better Software Engineer

10 Tips for becoming a better Software Engineer


!!Programmer, Developer, and Software Engineer!!

Below are the commonly associated definitions with the terms Programmer, Developer, and Software Engineer.

1. Programmers turn clearly defined solutions into the code, and all beginners start out with the aim to become a programmer. As the saying goes: everyone can become a programmer.
2. Developers take this further – they can code and design solutions and mostly focus on solving real-world problems. All developers are programmers, but not all programmers are developers.
3. Software engineers, on the other hand, see the big picture and have a deep understanding of how code and programming languages work, so they specialise in designing good solutions that are scalable. Suffice to say, all software engineers are developers, but not all developers are software engineers.

My TEN (10) tips to become a better Software Engineer

1. Write it out before you code

Keep a habit of scribbling out the algorithm/pseudo-code before you actually convert the solution into code. Writing by hand can also help you plan your code before you move it to the computer. You can save a lot of time if you write out which functions and classes you will need, as well as how they will interact. Although more time consuming, this restriction will mold you into a more fundamentally sound developer.

2. Keep a checklist of tasks

When you are implementing a feature, its always good to split the bigger tasks into smaller and clearer tasks which are individual logical units and can be tested individually. Keep a list of such small achievable tasks and keep ticking against them once you complete it. This will give you a boost and motivate you to keep ticking more boxes. The checklist can be either in a book or in any software (like Google Keep).

3. Follow proper version control techniques

Follow a proper version control strategy by creating develop, feature, master branches and having proper access policies set-up. Discuss this with your mentors if this has not been set-up. Whenever you start coding make sure you pull the latest version of the codebase and then start. Keep committing/pushing your code after a logical piece or functionality is complete. Don’t keep your codebase in an uncommitted state for a long time. Always test your code in the local machine before committing it to version control. However small the change may be, at the time of pushing code make it a habit to check the diff of the modified files, this will help you track changes that you had not anticipated and will avoid unnecessary bugs.

4. Constant Refactoring

Code refactoring is the process of changing the source code without modifying it’s functional behaviour, in order to improve the code readability and improve the maintainability by reducing the complexity of the code, as well as improving the code extensibility. Failure to perform refactoring can result in the accumulation of technical debt which the developer has to pay at a later point in time. Trust me, no developer would like to be in that situation. Developers often shy away from touching the code that is already working for a long time. The problem arises when a requirement comes to enhance the existing feature. If the code is not in the proper form for it to be easily extended then its a developer hell. So, to avoid such situations, the pro-tip is to always look for areas in your code which can be improved. If you cannot find it yourself then reach out for help in your team.

5. The code does not self-document

Feel free to leave comments in your code giving explanations why you made certain choices. This will help future learners since not everyone will know why you wrote your code in a particular manner. Do not leave comments that explain obvious coding behavior as they might become irrelevant. Proper code comments will improve the maintainability of the codebase.

6. Ask Google

Not all the problems you encounter will have an obvious solution. Always ask Google, there are probably millions of developers who have come across the same problem that you are in and they also have found out a solution for it. So, do not spend too much time looking out for the solution all by yourself. A lot of developers under-appreciate the degree which googling things is a part of a programmer’s job. Sometimes my job is more about knowing how to search for something than actual programming.

7. Always reach out for help

Programming is actually a social activity. I would not be as good of a programmer as I am now if I didn’t have other’s help. Each of my friends are good in certain areas so whenever I have a problem, I know which friend to ask. I also help them out in return when they have a problem. This is really the only way to get things done. What may seem like an immovable bug or an unlearnable topic could be quickly alleviated by a fresh pair of eyes or a new interpretation of the subject. So do not program in silos, always discuss and progress.
You can also follow Pair Programming technique at times. Pair programming is a technique that involves two developers working on one computer to complete a task. The two developers switch between being the “driver” and the “navigator.” The “driver” writes the code, while the “navigator” helps guide the problem solving and reviews the code as it is written. Switch frequently to get the benefit of both sides. Pair programming has many benefits, it gives you a chance to not only have someone review your code, but also see how someone else might be thinking about a problem. Being exposed to multiple ideas and ways of thinking will help you in problem-solving when you got back to coding on your own.

8. Remember that Technology Always Changes

I like to think of myself as a programmer first and a language-ist second since there will be a day when all of the programming languages we use right now won’t be used anymore. For example, if I started in the 80s, I would be using certain forms of assembly code that are all gone now for the most part. This will happen to all technologies no matter how good or bad. There will be a day when no one uses Java anymore. That said, there is a broad paradigm that programming languages fall into, and there’s sort of a family tree for programming languages.

So, if you know a language that is similar to another one, it can be very easy to pick that language up. For example, Python and Ruby are almost the same programming language. It’s true that, culturally, there are huge differences. However, other than that, they’re almost the exact same thing, so learning one when you know the other is very easy. So do not associate yourself to any technology or programming language and treat them as just tools that will help you in solving a problem at hand.

9. Remember that it is OK to have bugs in your code

We often see a lot of bugs reported in the functionality that we developed, which means most of the time, we’re failing. If all of our programs were feature complete and we didn’t have any bugs, programming wouldn’t even be a thing. Just the fact that we are programming means we either don’t have many features yet, or our software has problems. So, in some ways, you’re always failing as a programmer. This is a weird mindset to get into, but you just have to be okay with things not being perfect and not working; it’s literally our job. Programming is long-term process and in the journey, you will face new obstacles all the time. Keep a habit to record the mistakes that were committed so that you do not commit the same going forward, following which shows you are constantly learning and upgrading yourself as a developer.

10. Always find out ways to automate repetitive tasks

There will often be tasks which you do on a more frequent basis. Like running a set of commands or performing certain activities, which involve you switching between multiple applications/programs/screens, which eat up most of your time. It is advisable to convert these time taking daily activities to be automated in some way either through scripts or simple programs which can be run with a single click or command. This will save your time and you can focus on more interesting tasks and not worry about the routine and mundane tasks.

You definitely should have the mindset that is commonly associated with that of a software engineer and start thinking big.

Curious Much? Let me know your thoughts at and let’s start a conversation.

Author: Nitish Deshpande (