What is UX and why do I need it?
My name is Michał Dziedziniewicz and since March this year I have been supporting Expansio in UX Design issues with a chatbot project for learning programming: CodeAll (you can read more about the beginning of the project here). And what does that mean ? Well, that’s what I was going to tell you in a few words what this UX design is all about.
UX Design, or User Experience Design is designing the user experience of a service or a digital product. In other words, it is a collective concept of many threads that need to be dealt with in order for the user – flesh and blood functioning in 3D space – to have the sense of certainty, direction, security and the sense of agency when using a digital interface.
For those unfamiliar, the word “interfejs” comes for the English “interface” and means the point of contact – that is the way of communication – between a human being and a computer, another digital device or a service that we have accessed through these devices. For example, Siri is the interface to support the phone and the services offered by Apple, and your bank’s website is the interface of the services offered by that bank.
A lot of words here, but to put it simple, my task is to make sure that with the available technology and resources, the user will not be unnecessarily frustrated when he tries to perform a task with a computer mouse or on the screen of a mobile device, a task that (probably) until the mid-20th century had to be done by hand or with the participation of other people.
We can observe the importance of the task by looking at our grandparents, who often find it difficult to adapt to technologies, that are natural for younger generations. This is what a UX designer will do (among other things) to make us feel relatively comfortable with it; that we are able to learn how to use the latest application easily and quickly.
A successful interface consists of many factors starting from the selection of words/ language, the messages it contains, the arrangement and size of its elements, the choice of colors and grouping of functions and the like. Overall, the user is supposed to have the sense of agency, consistency and harmony in what he or she does. He needs feedback on the progress and effectiveness of actions taken.
UX Designer “predicts” and solves problems, that the user will encounter while using the product, before the product is delivered, thus saving the time of all interested parties – including programmers who therefore have much fewer corrections to implement. Let’s look at CodeAll as an example.
UX x CodeAll
UX design is a great value already at the conceptual stage of the project. The reason is simple. Between the birth of the initial idea and the start of work and ,finally, implementation the ideas and needs can multiply uncontrollably… Moreover ,they must be allowed to do so .
The functionalities necessary for the project suggest or even require further application functions to make a usable product. For example, if we can write computer programs, it would be good to save them in the memory of the device, and if so , there must be a place somewhere in the application where we can find these programs and where we can load them.
At the same time, ideas from external sources and inspirations flow into the project. For example, there is already an application on the market for learning programming without a chatbot or a chatbot, that does not teach programming… For the good of the project it is necessary to get to know these solutions and “watch”, “borrow”, “take” what you can… to finally choose such a set of ideas, that will be “nothing more, nothing less” for our product.
[magicthumb id=”2″]
A simplified diagram of multiplication and ordering of ideas in the product development process.
In the case of CodeAll, the ideas borrowed from the competition and which ultimately had to be abandoned or postponed (at least at the initial implementation stage) included, among others, the CodeAll user’s progress ranking compared to other users and the menu of projects to be performed. Although, we do not rule out that one day some of the solutions will return to CodeAll, we have decided that they are not necessary for the application to fulfill its role and constitute the closed whole ( they would therefore increase costs unnecessarily and postpone market entry). Others may simply not fit the business model.
[magicthumb id=”3″]
Everything we would like, but maybe not right away… or maybe not this time:)
One of the important factors to include in CodeAll are sensors, i.e. physical component, that affects both the way the content is presented (lessons should intuitively guide both the user who uses the sensors and the user who uses CodeAll in the freemium version – without sensors), as well as the application interface itself, where there must be a place to add sensors, find them, plan the reaction of the application to connecting the central unit (which in turn controls the sensors).
One of the important factotrs to inlude in CodeAll are sensors, i.e. physical component, that affects both content formatting (it should be attractive both to users who have access and those who do not have access to the CodeAll sensor set), as well as the application interface itself, where there must be a place to add sensors, find them, plan the reaction of the application to connecting the central unit (which in turn controls the sensors)and so on.
[magicthumb id=”4″]
CodeAll sensors
Moreover, the sensors and associated limitations also influenced the structure of content taught and the functioning of the code editor, which can be clearly seen on the example of two simple programs, that we want the user to be able to write. Program number one – let’s call it A – is “measure the temperature”. Program number two – let’s call it B – is “If the temperature rises above 30 degrees Celsius, turn on the LED” (i.e. the LED light – Light Emitting Diode).
[magicthumb id=”5″]
The user of the application should learn quickly how to write both of the above programs , but the B program is a problem, because it “really” means, that we want the program to check the temperature until we terminate it, and not in a split of a second, quickly check the temperature once and happily finish running. On one hand, we must therefore introduce the concept of a loop in programming language early in the curriculum. On the other hand, there must be a button in the interface to terminate looped programs. Otherwise , the program could run forever, without the user being able to interrupt it.
[magicthumb id=”6″]
We run the program in the same way but the interface must adapt to possible differences in its behavior
Let’s establish the MVP, i.e. Minimum Viable Product…
I hope I was able to show how in the CodeAll size project (and with some technological complexity) entities are able to multiply left and right. Thus , this is the best time to write a few words about Minimal Viable Product (MVP), the smallest version of the product, that would be usable and give the feeling of fullness (which – of course – can be developed later).
As a rule, the UX designer, in such a situation – based on market research, user target group research, customer consultation – creates user personas and proposes the paths of their interaction with the product. How will a teenager use CodeAll, and how will a person in their 30s, who decided to change their minds and learn more about programming? How can CodeAll be a tool for a user who will use sensors for educational purposes only, and what will be necessary for someone who will create a Smart Home installation from the sensors?
The so called “User flows” become the key, thanks to which we can plan product development paths (what is possible today, and what in half a year/ year time?), but also find the minimum possible version of the product, which can be a way to meet key expectations 95% of our target group of users. I am writing about 95% because by definition we do not want and are not able to create a harvester for picking cherries (something that would be used to do a bit of everything… and therefore nothing to the end).
The MVP is important because it allows you to develop an action plan for the next six months/a year/two years and realistically estimate the costs and time frames of the application launch. At the same time for such an MVP we can finally make a simple Product Map – user manual and define the purpose of operation of all involved teams in the form of illustration. Such 1000 words in a picture, where, faster than on 30 pages of documents, together we can see the overall product and the contexts of all the screens on which we will be moving.
[magicthumb id=”7″]
This is what the map for CodeAll MPV looked like at some point
It is worth remembering that, as a UX Designer, I play the role of a midwife in my own way and all these diagrams are intended to make the whole thing consistent and guarantee efficient communication to the rest of the team, i.e.. what we do, what does it look like and what are the consequences for the rest of the project if we introduce a change “right here”. My task is to make sure that we can see everything in black and white (and sometimes in color:)) .
Time for a prototype – a few words about mock-ups)…
We already know how our product should function. It is time to define its shape with as “wide a brush” as possible , i.e. start prototyping application screens. In order to maintain a high level of generality, we draw functions not the appearance (or the “feel”) of the solution. Clickable mock-ups are drawn – the so-called Wireframes – which have a neutral appearance and allow you to judge without a debate about “color theme” whether the interface is working properly.
[magicthumb id=”8″]
A network of connections between screens for extremely complex clickable mock-ups, prepared for the CodeAll chatbot tests.
In the case of CodeAll, mocking-up was a very big challenge, because I joined an already mature product with a lot of visually developed materials – i.e. a consistent presentation of the project was more important than the simplicity of the mock-ups (the tester should not be distracted by the question of why sometimes the mock-up looks like a finished product, and sometimes like a sketch on a napkin), and because the mock-ups had to simulate the chatbot’s behavior – load text and scroll automatically.
This was a simulation of a chatbot and the scrolling screen…
Clickable mock-ups allow you to search for internal and external testers, thanks to them you can collect feedback and see what we have missed; what we can learn from the clash of our perception of a working product with reality. Sometimes the so-called “paper prototyping” is done. The user from the target group clicks and describes what he is doing on the paper, and the person conducting the test places “subsequent screens” in response to the tester’s actions.
[magicthumb id=”9″]
An example of preparation for paper prototyping for one of my previous projects.
Details, details, details… and user’s expectations
The very preparation of mock-ups for the tests was a source of information about CodeAll. It quickly turned out that in some places the content of scenarios will have to be edited because the fragments of the lessons spoken by the chatbot are too long (!). When we talk with another person via instant messaging “tapeworms”, that extend the entire height of the screen, are difficult to understand. Similarly, when dealing with didactic content.
We were also able to confirm some of our expectations, for example, that the format of a conversation as information carrier does not exempt us from one of the oldest truths of education: when we teach new concepts or give simple examples of a computer program, using graphics and simple animations remains an indispensable tool.
[magicthumb id=”10″]
The text wall is “difficult” to read compared to smaller bubbles and chatbot questions/ requests for response from the chatbot.
Some of the design decisions, like the examples above, will always be related to building on the expectations and habits of the users. A recognizable and understandable operating environment reduces stress and frees the computing power of the brain to act on a specific goal (less “what’s going on”). Why breach an already open door?
[magicthumb id=”11″]
[magicthumb id=”12″]
Let’s not reinvent EVERYTHING. We “always” close the windows by clicking on the corner.
… and the cases in which we build “from scratch”
The CodeAll size design is a sea of details “to handle”: multi-dimensional and multi-size puzzle. Because this is a unique solution – at least one of the first solutions of its kind – it also presents us with problems, that are unprecedented among existing solutions. The analysis of the chatbot market, which we carried out on the occasion of Huawei Startup Challenge clearly showed that among the competitors we have solutions for learning programming, that are not based on chatbots… and chatbots with non-educational applications.
[magicthumb id=”13″]
Being in the know on the chatbot market
The lack of direct competition did not stop us from trying to learn everything we can from someone else’s solutions. We paid attention to the therapeutic chatbot – WYSA, which we chose as a benchmark for the fluency of conversation with a chatbot and as part of the Huawei Startup Challenge, we made a series of the analyzes of a manner in which the conversation was conducted. We compared them with User Flow, which will require conversation interrupted by writing short tasks – programs, that CodeAll will analyze and based on them will give further instructions.
[magicthumb id=”14″]
[magicthumb id=”14″]
On the left, a conversation with WYSA. On the right, a conversation/learning with CodeAll.
The details of the interaction with CodeAll will be crucial to the product success. A sense of freedom, comfort of conversation, agency may appear when the user is not distracted by unnecessary details. We continue to develop new variants of interaction with the chatbot and make design decision taking into account their consequences.
[magicthumb id=”16″]
In “Option B” we test the User Flow of the application, if the programming could take place in the context of a chatbot conversation screen..
In the picture above we can see two options of performing short programming tasks during the conversation with the chatbot, which well illustrates the role of the UX Designer in the design process. In option A, we always leave the conversation screen when we have to write a program. In this case the chat icon inside the editor takes the role of a hint on what the task should be (i.e.. I don’t have to leave the editor context to make sure I remember everything). The implementation of this solution will take a certain amount of man-hours. In option B I can “scroll” over the code editor and read all of the previous conversation and then go back to program writing. In this case, clicking on a chat icon will close the editor and provoke the chatbot to ask me if I understood everything, because I interrupted the task without writing a single line. This option also comes with certain technical and cost constrains.
With properly prepared documentation we are able to efficiently discuss what exactly we are talking about, what challenges the development team sees here and finally how these solutions relate to the broader vision of the product. Do we want the user to quickly get used to spending time in the context of the editor? How can these two variants affect the quality of communication with the chatbot? All in all, I started writing with the intention of telling a few words about chatbots, so maybe I will tell you about them now.
Tentative ending…
More about chatbots
Chatbots do not surprise anyone anymore, and we can all agree that in recent years the advance in this technology has been clearly felt. The progress is measured by the illusion of a real person “on the other side” (measured by the speed at which we realize it’s just a chatbot) and the effectiveness of communication. The measure of the latter is whether, as a result of the interaction, I will be able to obtained the desired information/intended effect.
The technology that dominates so far is a chatbot based on so-called intents. This is a technology of collecting possible answers that match the user’s questions in a given context, that is, taking into account information that, for example, we have been talking about the weather so far. Armed with the information that the context of the conversation is the weather and asked “How will it be tomorrow?” the chatbot will look at the list of responses and see if there are any tagged (marked with category) “weather”. From them , perhaps, it will choose “Who knows? I hope, it won’t rain”. In another context perhaps it would say “There will be fur tomorrow”. An example of the operation scheme is illustrated below:
[magicthumb id=”17″]
This is how the intent ” chatbot thinks”.
A well-designed intent system determines the success of a chatbot. It is easy to imagine mistakes that will lead the user to quickly realize that chatbot can only say “three sentences crosswise”. You can just easily imagine how much work it costs to plan and prepare the intents, that will keep the conversation flowing. Here, as a benchmark, I highly recommend trying the WYSA mentioned earlier in this post.
[magicthumb id=”18″]
The course of a sample conversation with WYSA.
Chatbots of the future i.e. what is a GPT-3?
CodeAll proposes a new form of education via chatbot as an additional thread for the current ways of acquiring knowledge – inspiration, alternative source, supplement for the information that we take and will take from school… Part of our motivation is that in five to ten years, it will be an obvious solution to all of us… just as no one is surprised anymore that AI can beat humans in chess (starting from Deep Blue in 1997 ) and in go (Alpha Go 2017).
[magicthumb id=”19″]
Kasparov vs Deep Blues (source)
Although, intentional chatbots with the right amount of energy can already effectively create the illusion of, for example, a technical support team, we already see how new technologies – based on Machine Learning – will bring the quality of communication with artificial intelligence (AI) to the level, where not using chatbots will be an attempt of an ineffective struggle with the spirit of the times (just as we prefer to go on an hour-long flight than a two-week trip in a carriage).
The first swallow is GPT-3, that is Generative Pre-trained Transformer 3: OpenAi artificial intelligence model (by Elon Muska), used for automatic content creation based on a neural network, which was actually “fed” by the Internet. This will not be a post about the way neutral networks work, but enough to say that the result of the network training is to predict what should be added now. A bit like each of us, based on a set of parameters (e.g.. “I’m writing a letter to a friend of mine on a subject…”) the model selects the next best matching word to the ones already crossed out and this is how , step by step, the finished text is created, often not distinguishable from man-made content.
Although at the moment we are still operating – like most of the market – on intentional chatbots, soon we will be able to start building our own engine based on artificial intelligence and GPT-3 proves that there is something to fight for; We are already able to efficiently build simple websites automatically, write codes, poems, blog posts, etc. Other tech-giants are also not passive and develop their own chatbots for example Google LaMDA. As the market develops, the quality of a chatbot-based products will only increase, and a feeling of a real conversation will be easier to obtain. This is key to CodeAll’s success, but also proof that we are moving with the times, while at the same time trying to offer users a well-edited knowledge and a sense of agency and understanding of the technology around us.
We are on the verge of technological possibilities to adjust the level of knowledge and the very selection of words to the user’s needs. Soon, we will be able to make the conversation with the chatbot fun and enjoyable… and by building on the CodeAll solution, complement and make knowledge available to the wider community, also from disciplines other than programming… and in every living(and dead?) language on Earth. Such times:). With a bit of luck the readers will soon be able to judge to what extent the work model proposed by CodeAll meets their expectations.