On Journeys & AI
Probably since I was back from being sick for about 24 hours and had my first coffee after about 36 hours, I got this realisation that we (the team building the Live Support app and the team providing the Live Support service) need to focus, from an app & service design perspective, on journeys.
While we are devoting some time up front this year to build screens for Admin so that we can do on boarding faster, better, we do need to look at the journeys of the Associates (employees), Agents (in house team providing assistance to users of our corporate apps), Supervisors and Management to figure out how to build out our MVP into a more rounded app/product, not to mention the whole service.
We need to find their JTBD and desired outcomes so that we can track the success of our app & service, but we need to understand their journeys to build AI.
AI, not as in Artificial Intelligence. As our little research has proved, thanks to the team's efforts in building a stillborn POC with RiveScript, we are a far way away from using chatbots in our service. And even if we do, it'll be a Narrow AI, a closed domain rules driven automation rather than a natural language processing and generating plus machine learning algorithmic automation.
Rather, AI as in (as I tweeted out a few hours back):
A = Astute (perceptive of user) + I = Intuitive (easy to figure out how to use/make use of).
I thought it up when I was reading this article on how everybody claims of AI in their smartphones: https://www.xda-developers.com/ai-in-smartphones-separating-fact-from-fiction-and-looking-ahead/
And while thinking about it, or rather trying to figure out what word would fit "A" if "I" were for "Intuitive", somehow "Astute" came to mind. Out of the blue.
I did, by habit, check its dictionary meaning and one of them said it meant "Perceptive". And then it hit me why I wasn't 100% satisfied with the word "Predictive" in our Design Philosophy slide (Simple. Intuitive. Predictive) in the deck we presented for our nomination into our department's Annual Awards 2016 under the "Impactful Design" category.
Did we really try to "predict" the user needs or wants, or were we only trying to be "perceptive" by knowing the app they were in when they clicked on the chat widget? Of course, it gets murkier the more I think about it, since it's not completely wrong to say that we are trying to predict what FAQ the user might be looking for when we rank the FAQs based on ticket volumes and chat requests and display them accordingly. But there's no "personalisation" there. We lack that. We show the same list, in the same order, to all the associates.
To do that we would need to be "perceptive" which means we can get more information about the associate from other sources too. Like the employee records, to know if the user is just a normal employee or a manager too. If the user is from India or other location. If there are any requests made by or pending with the associate. So many other things that we can get only by integrating with other systems.
More threads of thoughts were flying zip zap zoom in my coffee fuelled brain along these lines and I knew that Astute does fit the bill with what we are attempting to do.
Intuitive, I guess you all understand what I mean by that word. When the end user doesn't have to figure out how to use our application, because it uses familiar elements (send button in the chat box) or movements (more to do with touch devices, like pinch to zoom out, etc.), the app feels intuitive. It didn't take long for our users to figure out that they needed to read *any* FAQ to be able to see the chat icon and talk to the agent. Even though we hid the icon behind FAQs we built a very intuitive interface for the FAQs. It's kind of cheating the end user and the management, but we will eventually meet the expectations of both stakeholders. We will make it easier for the end user to get solutions. And we will reduce the requests reaching agents.
Anyways, coming back to Intuitive Design, you must read this article about it by Jared Pool titled "What Makes a Design Seem ‘Intuitive’?" where he talks about Current Knowledge and Target Knowledge of the end user and how to either bring the Knowledge Gap to zero or help the user close that gap without being conscious about it much.
And hence my insistence on keeping the chat messages from oneself to the right, from the others to the left and from the system to the centre. There’s no other reason for this other than the fact that most chatting apps use this convention. (Zero knowledge gap.)
And hence my insistence on adding a tool tip for the button to raise a ticket shown during after business hours instead of the chat button. (User is not spending too much effort in getting "trained" by reading the tool tip to use the ticket button.)
So, the way I look at it, for now, we need to make the UI more Intuitive and the backend more Astute.
Thus we make our app AI (Astute + Intuitive), without using AI (Artificial Intelligence).
But, going back to the subject line, where do journeys fit in here? While I could go on about building customer journey maps, service blueprinting, etc. it is very important for us to understand that for any user, be they Associates, Agents, Supervisors, Management or Admins, they are not living only within our app. They lived outside of it before coming to our app/service and they will get back to living outside of it after using our app/service. And it is very important to understand the before and the ever after parts of the journey while we give particular focus to the journey they have inside of our app/service.
While not written in stone or proven by repeatable double blind studies, I intuit that probably the before and after parts of the journey could lend much into our app/service being Astute while studying the part of the journey spent in our app/service can help us make it Intuitive.
And don't mistake. There's a lot to be designed for even during the chat. Lots of scenarios to take care of from the perspective of SignalR timeline events. And that's where we need to probably dedicate an iteration or two. We will definitely need some detailed flow charts, some subroutines that can be expanded into detailed flows themselves, various triggers like time and system in addition to the users, and so many more aspects like transfers, continuity over days, etc. And thus my insistence on BPMN for depicting these various scenarios.
I understand that the main task of creating these documents - JTBD/ODI, CJM, Wireframes, BPMN - are with our UX designer and business analyst, but it is our collective responsibility to give each one of our views to them as well as help in talking to different users of each type. We are a truly interdisciplinary team with visual designer, content writers, UI/frontend and backend developers, testers and the agents who give support to our associates. We have very young and dynamic members just about out of colleges at one end of the spectrum to very seasoned members with more than a dozen years of experience in enterprise and corporate app development at the other side of the spectrum. And we need to leverage the strengths of all and learn from each other.
We have a great job cut out for us and this is all new territory for just about anybody in our organization, not just our department. So let's drop all notions of already "knowing" what needs to be done and learn while trying out these new things. It's not wrong to fail. It's wrong not to learn from failure.