tag:blogger.com,1999:blog-47513175027000262492024-03-05T05:50:12.581+01:00Thinker TajaBoth IT and psychology are interesting fields of expertise. What would happen if you would merge them into one taking best of both?Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-4751317502700026249.post-8827847304461963042019-04-20T10:51:00.001+02:002019-04-20T10:51:26.459+02:00Importance of face-to-face communication<p>We started to organize by-monthly UX meetups a year ago. In that time, we tried many channels of communication. I learned that keeping it remote for way too long can backfire horribly.</p>
<a name='more'></a>
<p>We started the whole project with couple of meetings in a coffee shops and tea houses. We discussed our vision, strategy, roles in the team. We prepared ourselves for the work ahead of us. Despite the challenging road that was waiting for us, we were all motivated and standing tall.</p>
<h4>Remote channels</h4>
<p>At the time I found a job in a different country, therefore, I eventually had to move away. To continue talking about our tasks and obstacles, we set up couple of channels. We used Slack for day to day communication about various topics. We also created Trello board with tasks and due dates. And we also had Messenger chat which we sometimes used just for fun.</p>
<p>Each team works differently. Hell, each person works differently. We quickly learned that some of these channels were problematic for some of us while others loved them. This required iteration and we tried to find different ways of handling communication. Trello board was all but abandoned. Slack started to wither away. Messenger was the only of our old channels that prevailed.</p>
<p>The one thing that we all lacked, was a personal touch. We wanted to meet face to face and talk as we talked at the beginning. But with me living elsewhere, it became a huge problem. As a last result we started to have calls. Whether it was with video or just voice, it helped to have a real-time conversation and hear each other talk. It was better. But it still had its issues.</p>
<h4>Handling conflicts</h4>
<p>One and the most important things I have learned during this time, is that it is not possible to handle conflicts remotely.</p>
<p>Conflicts are bound to happen sooner or later. Resolving them is necessary for healthy team. Yet, with channels such as Trello, Slack and Messenger it became impossible. Conflict resolution requires meeting face to face or at least have that video call where you can talk freely and with emotions clearly visible.</p>
<p>Written language is prone to be misleading. The emotions are understood not based on what the author is feeling but based on what the one reading is feeling. Conveying emotions via chat is a mess. Therefore, seeing the emotions on your partners face, hearing them in their voice, feeling them in the atmosphere in the room, those are a must to be able to properly understand and empathize.</p>
<p>I failed at this. I believed I will succeed using written language. And I failed because of it. The conflict brew into misery and disaster, eventually leading to me losing a good friend and the team losing an awesome member who was very much needed.</p>
<h4>Conclusion</h4>
<p>I cannot say I learned well from this mistake. I still suck at leading people. But I hope this lesson will resonate with me next time similar situation occurs and I will be able to approach it correctly – sit down with the person and talk it out over cop of tea.</p>Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-63476103343067911512018-08-28T10:39:00.000+02:002018-08-28T10:39:02.409+02:00Facilitating UX workshop<p>A group of four people facing an extremely sped up process of ideation based on a research document – that was the setting I found myself in. I did my best to take charge and lead us towards a common goal.</p>
<a name='more'></a>
<p>It all took place at one of the workshops that are being organised in Bratislava. Even though, this workshop belonged to an ongoing series, it was the first one of a new season, which also brought new approach and structure to the program.</p>
<p>As all the times before, we were separated into groups of roughly 4 to 5 people. I was part of a 4-member group. The huge difference from previous events was in the focus and outcome. While other workshops were focusing on one specific aspect such as creating wireframe, writing a copy or brainstorming ideas, this one took us through bigger chunk of the process.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgslWRREkufN40C0FBHSSwRhPKp2IyBdCfu_M79V_iFKeVoqLyJVX9BKBgST4W7guJpul18IzOioL29Dx_9k2VKPJenHu_WIM58lpFUw5CKhEBikhieh2vkbgLuTbOIeoo6rl1CuTYmogI/s1600/ui04.jpg" data-original-width="1600" data-original-height="1067" class="full" style="margin-bottom: 1em;" />
<h4>Task</h4>
<p>We were handed a paper containing research outputs done by a researcher. It was a very basic description of the task and the problem space. We were given approximately hour and a half to prepare a presentation of our solution which would be showed to others. This included brainstorming features, creating layout and some basic copy, going through the design and making sure it is covering the use cases of the users that were described in the document.</p>
<p>As I was sitting there already halfway through my second beer, I looked around the table and realized the composition of our team:</p>
<ul>
<li>a student without experience or knowledge, who is interested in UX, attending his first workshop on the subject</li>
<li>junior copywriter who is also interested in UX but lacks experience</li>
<li>senior project manager who is very progressive in his methods and is slowly transitioning towards becoming UX designer</li>
<li>and me as UX researcher, who will soon be too drunk to be productive</li>
</ul>
<p>I knew that two members of my team will need a lot of guidance and that the third one will be of a huge assistance – if heading in the right direction. Sitting there, thinking and taking a sip from the cold beer, I decided to facilitate our little mini-workshop and propose ways to reach the goal.</p>
<h4>Ideation</h4>
<p>The student started coming up with ideas right off the bet. I had to stop him to prevent him from boxing himself into a specific idea. We needed to first understand the problem space. Therefore, to start this journey, we wrote down all the problems there could be in our problem space. We were just brainstorming things that could be a problem for the users. I received a huge help and support from the most senior of my teammates in this activity. I believe it helped me get more comfortable and actually pull through as a facilitator.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiddRreZOlnuvVSki1OwxENWG6ZYwOHHYOEGpJoxMNCRZvzw1Q-FF5ujrb74kGDQZ1dlU8ymF4xu7Ihw17ZW5-Q3LqOow3AOYOoOCz0-OCMsND-u4iM1aelBtc_mr8DsQ7xjUToUZaLl-4/s1600/ui01.jpg" data-original-width="1600" data-original-height="1067" class="full" style="margin-bottom: 1em;" />
<p>When we had all the problems on the whiteboard, we picked 3 to solved. These 3 were pretty much the same ones that were in the research document. Even though, the exercise did not yield much in different outputs, it made us think about the obstacles users face a little bit more.</p>
<p>Knowing exactly what problems we will be solving and which we will not be solving, I gave everybody post-its and asked them to make up at least 5 ways how we could approach the problems. I made it clear we are not really looking for designs or concepts of how things should look like, but on how they should behave. Once again, we needed to understand what we were solving for and what kind of ideas we could come up with before we start boxing ourselves into specific design. I set a timer to 5 minutes and we began to draw on our stickies.</p>
<p>We had a round of explaining the ideas we came up with. There was no judging or criticising. The point was only to introduce different ideas and explain them to people. Anybody could ask clarifying questions, however, we were not to evaluate the ideas at all just yet.</p>
<p>Under normal circumstances we would vote on the ideas after explaining all of them. These were different times though. We had deadline to hit and after grouping of similar ideas, there were chunks that included stickies from all of us. Assuming the ideas we all came up with undependably on each other will be the best bet to move with – we picked those.</p>
<p>Once we had few approaches we could take and technologies we would want to use in our make-believe application, it was time to start thinking about the design and how it will look. This time I asked for a big A4 format papers from organizer and separated it into 6 parts. I gave one of these papers to each of us and set timer to 6 minutes. We were once again thinking on our own, but this time we were supposed to draw the interface.</p>
<p>Each of us received only one colour as to make the wireframe very simple and low fidelity. This prevented us from spending too much time on detail during drawing and also during evaluating phase. Despite my attempts, I did not succeed in making it clear that we have limited time and therefore the wireframe can be very crude – some people just love to make things pretty.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyBmuiq-LIGZbvWushHjJSUUAXtMjoPF2K3-TagxdOt6dOmKiAz5lV2LdeSaoKsItu32N3yWT-_3gNK4s2lSb9y8OT_ybxH6bjeh-nn-NDDEMt3L5_fED-tZon2OqteCB1_gwvNJrUKmw/s1600/ui02.jpg" data-original-width="1600" data-original-height="1067" class="full" style="margin-bottom: 1em;" />
<p>We held another round of explaining our ideas – this time in a form of wireframes. At this point I was getting way too tipsy for my own good and I knew my team member, who works as a project manager, does not really need to practice the following part. On the other hand, student and copywriter were doing pretty good job and I believed it would be beneficial for them to take the lead at our next activity.</p>
<p>Since it would be too much to have 4 voices deciding how the final design should look like, I appointed the student to be a researcher, since he was already thinking about the solutions and the problems. And due to the fact that the copywriter had a need to draw the most beautiful shapes, I appointed her a designer. The researcher and the designer duo were to gather our designs and make the final one.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6nx2yHbPziCfhcE0FbsMocRLxTkiJC-P5Fr_-0CgqNE2GBpSftz2l91QiTns7EyAyFMJVCMb6oR51c6NhNmnROBCTiwukDtGRxDZF4gKOvANyguREdw2xi51cPqbWjvl8hFXMQQA0zZg/s1600/ui06.jpg" data-original-width="1600" data-original-height="1067" class="full" style="margin-bottom: 1em;" />
<p>They could merge the designs, they could get inspired, they could absolutely ignore them and make something new – it was up to them. Even though I was hoping they would pay attention to what was made so far. And luckily, they did. I suggested creating click flows – drawing layout of each view and connecting them with lines depending on what element would trigger transition to another view.</p>
<p>Fast forward 20 minutes, our team had click-flow diagram drawn on whiteboard and our researcher was ready to showcase it to the other teams.</p>
<p>We were first to present. I occasionally intervened when my presenting teammate had trouble, or I felt the question he was given was little too much to handle. I did not need to do it often, he was pretty much nailing it with his answers.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXuTNAlNbjRRpopgo8-ojAeU2cKKnjIqas2nAhm6OJU1JZIYEsh1paoXCejGGXqm-kNyo-yxPopt1BOgg4w4sWrrqS3KtKhplA6u9JKok1lzPpM5WHOe0zNBtADOw6y1ZmxC-pmQ2wacw/s1600/ui05.jpg" data-original-width="1600" data-original-height="1067" class="full" style="margin-bottom: 1em;" />
<h4>Conclusion</h4>
<p>Later that week, I received a positive feedback about this approach. Apparently, we were organized, focused on the problem and a solution, listened to each other and equal in our opinions. The more junior members of our team gained interesting experience and felt very safe while swimming in these unknown waters.</p>
<p>By following practices learned from Design Thinking and Design Sprints, we were constantly paying attention to what we were doing. We did not bias each other, we did not criticize each other, we worked as a team with common vision and goal to get to.</p>
<p>Even though at the end, our design was not the winning one, we were close second with our competition having one less view in their flow. It became very clear that the design which was simpler, was also the winning one. Solving for more problems, adding more technology – that would only add complexity.</p>
<p>We were happy with the experience we gained, and I can say for myself – I am looking forward to another workshop with this awesome team.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpAcYD8H72ldDP3Eqje84G-hZCF69ocNiVnxI69rJPrJ81l3zITKDs4X6qPHT1Zif4DIHRxE_uYe1LRTfN16sP6nYMP9OBcNDvauKAIifosWPZlDs4eJdo5CveSnR9kzeRThRLmQBNW1M/s1600/ui03.jpg" data-original-width="1600" data-original-height="1067" class="full" style="margin-bottom: 1em;" />
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-78489090650864746992018-08-22T13:12:00.000+02:002018-08-28T11:34:38.752+02:00Organising UX meet-up<p>Attending meet-ups, workshops and conferences is a brilliant way to absorb new knowledge and gain different perspective. There are times though, when you feel the community is lacking these kinds of events. This is a story about how my friends and I started to organise a series of meet-ups – the obstacles we faced and how we overcame them.</p>
<a name='more'></a>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglGmFT9EaRX24A1T04fVbtOtQM39cxE1G2bT4_10xD7dsR0v-Z94UdIZEUV49mK-fjthGU09Rr8RBWNup_WoRHXUoltkG6sEoN4t4CH6CF8FJ2OQP9IfzBC4yHPk7RDVvpHikuAOJMdNk/s1600/uxforum_fb-cover-pic_done.png" data-original-width="852" data-original-height="316" class="full" style="margin-bottom: 1em;" />
<h4>How it all started</h4>
<p>Couple of years ago, a community of UXers in Slovakia was created. It started off as simple Facebook group. The owner of this idea started to organise meet-ups with talks. She would invite various people from different fields to talk about subjects that matter to UX oriented people. These meet-ups would repeat on a bi-monthly basis.</p>
<p>I enjoyed attending these events. They were always filled with interesting information and it made me realize there is a community of people caring about the same thing I am. Even though I sucked at networking, it was good to learn from more experience people in the field.</p>
<p>Since all good things must come to an end, these meet-ups were over not long after I started paying attention to them. The organiser left the country to travel a bit and explore the world. She asked if there was anybody who wanted to take over, but there was nobody. At that very moment an idea was seeded in my mind – I wanted to continue these talks. I had no experience in organising anything, I had no connections and because of it I lacked the proper drive to take over.</p>
<p>Some time later, others have started working on events of different nature. There was a big survey filled with all the people working with UX in the whole country. The numbers of total replies were pretty low – the UX community was small. Another event was a workshop taking place in a coffee house. It was simply amazing. Quality of the talks, the interesting exercises, the beautiful photos, the casual atmosphere, the thought-through branding – it was all amazing and it inspired me to start thinking about my previous idea to resurrect the talks.</p>
<h4>Forming a team</h4>
<p>It took time and lots of meetings. I grew few contacts somehow – I honestly have no idea how. I simply wrote to people and once they replied, we had a nice chat and I learned they are mortals just like me. I talked about the idea to organise meet-ups similar to the ones that happened before, but this time I would also apply all the inspirations I gained from the mentioned workshops. I gained support.</p>
<p>But that was not enough to start this enterprise. I had my vision and my goal, now I needed others onboard. I set out to pitch the idea to my former colleagues who I knew would be interested. And they were. We had lots of discussion, gathered our mutual visions and goals and shaped them into a strategy. We used the survey that was done before to make informed decisions.</p>
<p>We decided to focus on expanding the community and sharing the knowledge inside it. We were a team of 4 and we had roughly 4 months to prepare for the very first meet-up. We set the deadline for February. That was the month we wanted to reveal the fruits of our effort to people.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilb0q-rMSKCsn_7NpHwtH-zxakWE_zogRI6kni3p8nBFJBEIrJy56IoIlkYW0ILUNKAgNBibh5ZYqykS05z8X3pzB51cI3DRtjHLVBFT0lXWari8-03_2OVeFbtiOZvmb3RfqIdluQjNE/s1600/uxforum.jpg" data-original-width="1200" data-original-height="1409" class="full" style="margin-bottom: 1em;" />
<h4>Branding</h4>
<p>When we had a strategy in place, we started to work on a branding. We had an excellent graphic designer that created the whole identity of the project. She spend month picking a font that would suit the needs based on dozens of parameters. After that, the icon was iterated on and made. Once that was done, the colour scheme was proposed.</p>
<p>The branding was so agile, it could have been be used with any colour, on any background, at any size. It was truly a masterpiece.</p>
<p>We understood that brand is not just about visuals – huge part of it is how you communicate. That is where second member of our team came in. As a copywriter, she created the tone of voice, the posts, the language that we used. It felt different from all the other similar projects, it felt unique and caring. A very personal approach was used. We wanted the people to have a great time – it was a User Experience meet-up after all.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEif-NA7vhK8u0aFu6yXgv2lpZcMKFmji6tXwHAJUxWUyBjErMwjMOJ61VtoEktSOGjEnSCUzTN3PK26eh_Qml4so6TQOsEV48_PaeDdD2Q_nvMzc2SAmzzJOnoB6EJ7F2WTRrhx_-yc_K4/s1600/_DSC7977.jpg" data-original-width="1600" data-original-height="1060" class="full" style="margin-bottom: 1em;" />
<h4>Problems</h4>
<p>It would not be fair to omit the problems we faced. We were mostly inexperienced in the roles we held. I had very little experience leading, organising or managing people. Our graphic designer had great potential, knowledge and ability, nevertheless, it was the first project of such a scale for her as a graphic designer. Our copywriter was an enthusiast and not yet professional in the field either. The forth member was a Project manager who was very good in managing development projects and helping people in his team.</p>
<p>There were points of high stress and there were times I made some bad calls that snowballed into bigger problems. I cannot speak for others, I can only admit the mistakes I made. There was time when it looked like we are not going to make it, so I started looking into different ways of approaching the branding. It did not pay off and it angered our designer – a friend of mine. It created big tension and proved to be a problem.</p>
<p>There were many small hustles and disputes that we had to overcome. We were trying to be proactive as much as possible and nitpick every single thing. We were trying to anticipate the problems just to be surprised by them at the end. But such is life, we learned and adapted.</p>
<h4>Going LIVE</h4>
<p>Even though the meet-ups were for free and we wanted them to be for free, we needed to get people interested and bring them there. We prepared for a three-week-long marketing campaign. Once the event got published it took 3 days to be completely booked out. Our three-week-long campaign was not needed and we swiftly had to shift towards explaining to people that not all hope is lost.</p>
<p>With support from our sponsors, we were preparing to record videos of the talks, so that they will be available after the event as well. It proved to be the right call as the videos received positive feedback.</p>
<p>With three weeks to go, we started preparing for the event itself.</p>
<h4>The big day</h4>
<p>With help of another supporter, we baked huge amount of cakes, we prepared for every little thing we could possible think off. We checked the weather and realized how shitty it was. It was snowing, it was windy, it was bad.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEink9l3ul3-wAPBdXLdPO9SOMw4mJ-WoPTSsq9q0vT_GUBHKgj8zKcCXHdtypIjHA2I2bPglmrNgRMcPBMChxZNphbXTa7V0ucOvRbJIjTtN-UBWI6vl4JzddmEqUbxJYR7w8usB_piyNI/s1600/_DSC6146.jpg" data-original-width="1600" data-original-height="1060" class="full" style="margin-bottom: 1em;" />
<p>We came to the venue and waited. It was empty. I was standing there watching the snow fall outside the window and wondered if any people turn up.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRXRJD2E9p8g7TIVF_h0q9icBGfX4GxozgJESor4gDl_U0BVJ63wzINX8GuJ65hzgq0V0dLx6bHQQWyM3qfKa1d5Iz0kGNJRa8pxKVtUqGqOjJh6ig1KBDQBEmVACI4cSYQdONVSq3PfY/s1600/_DSC6148.jpg" data-original-width="1600" data-original-height="1028" class="full" style="margin-bottom: 1em;" />
<p>Time was passing by and some people started showing up. They were mostly my friends who came there to support me. It was 20 minutes before the event and I started being extremely nervous.</p>
<p>Skip forward 20 minutes – the room was full. People were not only sitting in front of the stage, they were sitting beside it. The whole place was packed. We introduced the event and gave word to the speakers.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZUJtxFbdwaLIVPo64jKWkzPVrRmQZz2_aS0GVRaF3iDjnIzcFXuT30b_sLdxEv7fjlQOV6a2bNHt_Jxk5dOYjeiB4AA99wo5wNIFtVrtrRFnTmOOPVbhrxm0j5J-Ceu__xytGfJo3ozM/s1600/_DSC6254.jpg" data-original-width="1600" data-original-height="915" class="full" style="margin-bottom: 1em;" />
<p>After the talks, there was networking with catering, cakes and tons of actual chatter. At some point the lights went off. The only source of light in the room was the moon. It might sound romantic but it is not an optimal setting for a meet-up. Then something amazing had happened – nobody cared about the lights. People did not even twitch, they were involved in an interesting discussions, they did not need the lights, they were having a fun.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9TJqykX9Sz5yyjevv8Y0nPD9j5lUTdQE8qjHwqJztxTqpv9Ubtb5QP3bQ4BQ70a8XWMj3LYo0IWimBIGO410XfALCAdUUU66VRnL8P43Ur7bEC2xlfIbhvVJ_r3c-ssXzpt4MLEwMd9k/s1600/_DSC6302.jpg" data-original-width="1600" data-original-height="1022" class="full" style="margin-bottom: 1em;" />
<h4>Conclusion</h4>
<p>We received very positive feedback. The talks were successful and the event was praised heavily. The meet-up was even mentioned by the attendees giving talks at other events as a good source of knowledge. It was amazing feeling hearing about our own meet-up being talked described as such by people who were genuinely happy.</p>
<p>We all learned a lot. We all went from participants and bystanders to organisers. And most importantly, we all worked as a team.</p>
<p>With all the problems, all the stress, all the sleepless nights, I realized one thing – we were successful because we were a team. Every time there was some problem, we dealt with it. We supported each other. We brainstormed together. We relied on one another.</p>
<p>If I were to do this alone, it would have never have happened – and I would most likely go insane trying.</p>
<p>I learned that the most important thing when it comes to successful project is to have a brilliant team of people who all care and help each other.</p>
<p>I would like to thank all of them and everyone else who helped with this initiative – it happened and exists because of you. The audience and community attending the event also shape it. I am grateful for all of those who come to attend the talks and networking, and for all the feedback they provided.</p>
<p>The UX Forum lives on and we are organizing new talks in Bratislava almost every second month.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com8tag:blogger.com,1999:blog-4751317502700026249.post-66781399919947299622018-07-05T11:48:00.000+02:002018-07-05T11:48:28.138+02:00Having absolute control over the User Experience<p>Once your perfect software is published, you can finally take a break from checking all the details needed to provide flawless experience for your users. Well, at least up to the moment any change needs to be made and you do not want them to cause any imperfections.</p>
<a name='more'></a>
<p>I had spent months working on a website before I attended Typo Berlin 2018 in May of this year. I tweaked every pixel, addressed every possible shortcoming. I kept checking it on all the screen sizes that exist. I wanted a webpage that would be extraordinary on mobile, on 4K screen and also everywhere in between. I was going for perfection. I had the time and the will to do it.</p>
<p>Although I was looking for perfect user experience, I was also going for perfect development experience. I tapped into my inner backend personality and decided to populate all repetitive content with PHP. I created templates in HTML and CSS and adjusted them to all the screen sizes. After that the PHP would use these templates to fill in the blanks.</p>
<p>This approach was used for everything on the page. It was all dynamic, generated by PHP, very little text was static. The benefit of this was easy maintenance and updating of the content. I did not really need to go into code to add new content or remove old one. The page reflected any changes on its own. I can safely say the experience of developing the page from there on has been a breeze.</p>
<h4>Control over typography</h4>
<p>During my stay in Berlin I attended a great talk by Frank Rausch, who talked about New Typography. It was inspiring speech that introduced me to so many great ideas.</p>
<p>He described how typographers should control the system as opposed to controlling the documents. He argued that if you check each individual document and fix the typographic errors, incorrect line breaks, and so on, those things will break down if any changes are made or if the document is ever displayed differently – for example on differently sized screen. It will also mean you will have to check every single document.</p>
<p>In his presentation, he described his application that took content from Wikipedia API and displayed it in corrected fashion. Wikipedia has millions of articles, checking each one of them would be impossible. What he did to overcome this obstacle was truly genius solution – he coded rules into his application that would adapt the typography in content when the article was pulled from web. This way he did not have control over specific documents, he had control over the whole system and therefore over all of the documents.</p>
<p>He went few steps ahead and added automation to some of the design decisions as well. Every time there was a picture of person he would use API to find face of that person and make sure the picture was aligned in such a way that the face was shown. It is way too often on Wikipedia pages that famous kings and queens get decapacitated because of incorrect picture alignment. He also automated some of the colours in his app that were based on the most prominent colours of the unique headline images, different for each article. This created incredible consistency and helped with legibility.</p>
<p>He gave different examples of Regex rules he used to fix some of the typographical errors. He mentioned 8 different existing characters for whitespace – yes, it is not just space. It was amazing to watch what astonishing outcomes can be obtained with just few lines of code.</p>
<p>According to his opinion, designers, typographers and all folks alike, should take up coding courses so that they can control parts of the system. It would be unreasonable to assume that engineers will have the same knowledge, experience and keen eye on details when for example using specific colours, typographical characters or applying very precise size of whitespace to interface. Therefore, he said, it is up to us to handle those tasks, as we are the ones who truly understand them.</p>
<h4>Control over user experience</h4>
<p>The talk was amazing. It influenced me more than I dared to admit. I came back from it and started coding rules for typography that would be applied to my webpage. Automatic corrections of characters without a need for me to go over every single copy and hope it will be ideal on all the screens – that became the dream.</p>
<p>But it did not end there. I started looking at column layout and text alignment. Why couldn’t that also be influenced by the content? Why should I fit the content to a specific layout instead of having dynamic layout that would embrace the content within it.</p>
<p>I already had PHP controlling majority of the page, why not give it control over the layout as well. I could give it a powerful relationship with CSS and adapt the content based on itself and the screen of the user. So I set out to give it a shot.</p>
<p>I identified few paragraphs that were suboptimal. My page is mostly aligned to centre and therefore short texts look better aligned to centre. If they are long though, it gets problematic to read them. On the other hand, even short texts can get longer if displayed on small screen and long texts can get rather short when looked at on 4K screen.</p>
<p>I added CSS classes that would handle the screen size and I added simple PHP calculation that would decide what CSS class would be used. The text is now changing based on its length and the screen the user is on. If its optimal to centre it, it gets centred. If it is too long for that, it gets aligned to left. This solution drives solid balance between aesthetically pleasing design and easily-usable one.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizL_aMLAZ7V758fFgxY3kOnNzpih1gfDqsZQ-fUNjqLJuXyQRJ12qodhbG-DksCZdmQ_9Syd7BSrUj-HDEbBVnyUigvTsY7qSZ9DhYfsFupQJNe89GyIm7fMlDIgnlhSiURgEZMDD8o8o/s1600/dynamic+alignment.jpg" data-original-width="1037" data-original-height="1600" class="full" style="margin-bottom: 1em;" />
<p>After this was done I went over to column layout and started doing the same. I wanted the page to still have the same major grid size but also have the perfect amount of white space between elements. If there is few elements, move them closer to middle instead of driving huge gaps between them. If there is more and they still easily fit, put them next to each other. And so depending on the amount of elements the columns were adjusted to provide best fit for all screen sizes.</p>
<p>Here is a very crude sketch of one screen size (mostly used by tablets). Of course, the layout would change on bigger screens that could have 4 elements in a row. And it would change on smaller that could hold only one or two per each row. Important thing to point out here is that the number of items was known during the loading of the page. It is not possible to have both 2 and 3 elements at the same time. It would always pick the layout that would correspond to real state of the content. Hence it would be consistent for the user as the changes are not done that often.</p>
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhaB3h1xu3E1EKVbNxRCoUdp2V5tqq0sJL19G8g2U86VTcPSAE8kEne0PBt4CPJ0tJ3kM-P_xdXIDqglzTP9iutvywXUn1SDp504vyJYey8AI-iTNsw1bDhxsJCmv8Mzr1TntCuCK-Ocg/s1600/dynamic+layout.jpg" data-original-width="527" data-original-height="1600" class="full" style="margin-bottom: 1em;" />
<p>Another great idea sparked by this approach was to change the CTA based on circumstances. The webpage is about meetups and therefore, it is important to have Call To Action buttons enabling easy registration. But what if the meetup already started or is about to start in just a few minutes. In such a case, it is far more likely that people are looking to find live stream of the event rather than to register for it. Hence in those situations, the webpage will display CTA calling the user to watch the livestream of the current session.</p>
<p>With the same logic in mind, the event that already ended – even if it was just minutes ago – would be automatically moved to archive, leaving behind a message informing the user about the event being over. Users can then find all the events in the archive. And even though archive has slightly different template used, all the content is the same and PHP can populate it from the same source as it did before when the meetup was still in section for upcoming events.</p>
<h4>The beginning</h4>
<p>This is just a beginning of what is possible. But having this idea in mind, I believe that typographers, UX researchers, designers, copywriters, and many more, can have more control over the aspects of product they are responsible for.</p>
<p>This will let us provide the ultimate experience for our users. It will negate the negative effects of different browsers, screen sizes, devices, situations users can find themselves in, changes in content, and so much more. The system will simple take all of this into account and provide the best experience for the given situation, tweaking the subtle obstacles in typography, usability, design, etc.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-25289640333142898302018-07-02T15:17:00.001+02:002018-07-02T15:27:46.866+02:00Looking for problems, finding solutions<p>Do you know the feeling when you have a new idea and you start thinking about how it could look, what features it could have, what kind of impact on the market it could leave? I think it is common mindset to be eager to get all the answers before we start asking the questions.</p>
<a name='more'></a>
<p>This happens to me very often as well. I think of some cool new innovation, start feeling the rush, making up the possible features, thinking of different problems that could happen and so on. It takes some time for me to stop, take a deep breath and actually start asking questions.</p>
<p>There are always important aspects to consider such as: Who is the target audience? Who is the competition and what are the differences of our product? Why is it useful? Not knowing the problem space is like throwing darts blindfolded. You can only hope you are even facing the right direction.</p>
<h4>King asking the right questions</h4>
<p>One has to know what questions to ask. The trick here is to not let yourself believe that you have all the right answers. As I have written in my <a href="http://thinker.taja.sk/2018/06/there-is-nothing-wrong-with-losing.html">previous blog</a>, it can be complicated to deeply believe in outcome when you are doing research.</p>
<p>It is way better approach to teach yourself to be skeptical and curious about the world around you. Instead of starting with idea, start with a question. Why is it that…? Make WHY your most fundamental starting point.</p>
<p>Once you have the question, go research it. Find out the true facts and not just opinions or assumptions. Use thorough research methods to remove biases that would otherwise invalidate your outcomes. This is a job for a researcher – person who is there to “find the problems”.</p>
<h4>The wizard with all the answers</h4>
<p>To make something successful, you have to resolve issues that are plaguing others – your users. Therefore, it is next logical step to use the problems you have uncovered and build potential solutions for those problems. It is important that this is not done the other way around. You should never look for problems to your solutions.</p>
<p>Yet, so often the solutions precede the problems. There can be multiple reasons for that, such as micromanaging leaders who think they know better than anybody else, incorrectly distributed responsibilities within team or even improperly handled project.</p>
<p>Either way, I believe that the time to look for answers in a form of solutions is the moment you need designers. And that is where I see the main difference between researchers and designers. While researchers gather the questions and problems, designers have skillset that enables them to provide answers and find solutions.</p>
<h4>A happy kingdom</h4>
<p>These two categories of people have different mindsets. Researchers are there to find problems, designers are there to find solutions. If you allow researcher too much control, there will be infinite problems with no resolution. If you allow designer too much control, there will be brilliant solutions to non-existing problems. A balance is needed between looking for facts and building up on them.</p>
<p>From my experience, the best way to handle the responsibilities is to first let the researcher do her part and after that gradually transfer that power to designer who will work her magic on creating the best design.</p>
<p>It is important that these two are constantly communicating. Designers should be aware of the research and the problems as they are uncovered. Researcher on the other hand should still be present when designer is working to guide her through the research outcomes and provide feedback.</p>
<p>These two mindsets are rather different, each serving a unique purpose, both being equally important. Do not mix them up in incorrect way.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-48383158537657281662018-06-21T15:51:00.004+02:002018-07-02T15:25:48.358+02:00There is nothing wrong with losing<p>So many people expect specific outcomes before conducting research. And then they feel as if they lost when the results of their tests do not match the expectations they had. While it might be tough to handle, disproving your own idea can be part of successful research.</p>
<a name='more'></a>
<p>Let me give you a short explanation of why you do not lose if you prove the opposite of what you originally thought. To do this, I will describe two real-life scenarios that highlight the problem and incorrect approach towards it.</p>
<h4>Proving the opposite</h4>
<p>When you are starting an experiment, you have a question you want answered. This can be done in a form of having a hypothesis. You can create a statement that you test to see whether it is valid one.</p>
<p>One of my friends decided to write a thesis about people’s behaviour when playing games. He wanted to map personality traits to differences in controlling a game using a mouse. This experiment had three parts.</p>
<p>The first step was determining person’s traits. He used a personality test to get this data. The second step was creating a simple game that could be controlled in multiple ways. Third step was evaluating the data and finding a correlation.</p>
<p>He found non. And it was a major problem for him. He could not see a single connection between people’s traits and their behaviour when controlling a game. He tried everything. He even ran the experiment again. And still nothing.</p>
<p>All in all, he decided to wait a year to look at it again. And he still did not find a correlation. He has never finished the thesis. But in reality, the valid outcome has been there the whole time – there is no correlation between the measured variables.</p>
<p>His experiment proved that personality traits do not affect how people use mouse when playing a specific genre of games that he prepared. And who knows, maybe this extends to all games. And yet, he did not see that as a success. He eventually gave up and never published the results.</p>
<h4>Forcing the outcome</h4>
<p>I had a luck of being interviewed in a guerrilla interview at a central station in Berlin. Two young people – who appeared to be students – walked up to me and wanted to ask me a couple of questions. As an UX Researcher, I was thrilled with this opportunity and so I agreed to participate.</p>
<p>The very first question stated their goal – prove that advertisement boards on the station were useful. Apparently, there was a new feature and from time to time the ads boards also showed news sites and their articles. I personally see all those ads as spam and ignore them. Therefore, I did not notice the news either. The two young students became visibly unpleased by my opinion and experience the very moment I stated it.</p>
<p>They kept asking leading questions, trying to force me to find any kind of a value in those news. All in vein, as I kept saying I did not notice it. So, they started asking hypothetical questions and became interested in knowing if I would google the news or visit displayed news sites. I must admit, they almost swayed me to start questioning myself and actually say I might google it.</p>
<p>Luckily, I am a researcher and an asshole, and I know that since I have not notice those ads nor news, I would have not taken any action. I was simply not interested in it. Even if I knew about the news, they were in different language and I already have my own way of getting news, I do not want or need more. So, I kept saying no. They tried to persuade me and I became quite amused by it.</p>
<p>I bet though, that majority of people would believe – even if not consciously – that they can find value in mentioned news, just based on how the questions were structured and because it was so painfully obvious the students wanted to hear it. That would mean they would gather biased and incorrect data.</p>
<h4>Conclusion</h4>
<p>Take a step back. Do not rely on your hypothesis to be the absolutely valid one. After all, you are there to research the idea and find out the real truth. Research done to prove a thing at all costs is a horrible approach, not even worthy of being called a research.</p>
<p>Do not influence your research participants, otherwise you will have incorrect data. Do not give up on correctly gathered results just because they did not match your expectations of how things work. Embrace those results and show it to your superiors and the world.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com1tag:blogger.com,1999:blog-4751317502700026249.post-644000245483916342017-11-04T08:49:00.001+01:002017-11-10T16:33:16.764+01:00Problems and regrets of my survey project<p>Even the best looking projects that succeed on the outside, might suffer from internal problems and struggles. Sometimes these are hard to spot, sometimes somebody else will take care of it. Either way it is always important to address them.</p>
<a name='more'></a>
<p>I spoke about this <a href="http://thinker.taja.sk/2017/11/masking-flaws-of-ai-as-benefits.html">amazing success in designing survey with AI and gamification</a>. But it was not all flowers and sunshine, there were some problems.</p>
<h4>Project management – agile vs waterfall</h4>
<p>Working on our survey project, we had very strict timetable for development. But with pixel-perfect mockups for our project approved the development could start. PM assembled the team, made sure everybody understood their job and the project in general. Timetable was problematic and he had to leave for 3 days. To address his absence he completely handled the bureaucracy needed for overtimes, found mentors in case there were some hiccups and made sure everything technical was prepared. We had everything we needed and he could go away knowing we will finish it on our own.</p>
<p>This all happened around time when I had conflict with management so I decided to play by their rules and not consider anything my responsibility as per my instruction from above.</p>
<p>Second day into PMs unavailability a question arose. We were supposed to support multiple languages but some of the texts were missing and some were altered. We needed to update the translated texts. After that another question appeared. Are backend and frontend teams well coordinated? There is so little time and if there is issue with missing texts, is there no other unexpected surprise that might get unveiled on release day?</p>
<p>Under normal circumstances I would sort it out instead of PM. I would ask backend and frontend developers if they are synced and have everything planned out. I would also write clients about translating the text they approved. After all I spend 3 weeks discussing design with them, I was more involved than PM himself.</p>
<p>But these were not normal circumstances. I was told by my superiors to back off from anything outside my direct UX responsibility – that entailed backing off from project management however small my part it would be.</p>
<p>So I asked my superiors, what should I do? There are questions and some small management is needed. PM is unavailable and there is no stand-in appointed.</p>
<p>I was told to find leader of PM team, explain the problem (again) and ask for someone to handle it. In my foresight I included bunch of people on cc. It was those people who showed effort in solving the problem. A point for me I guess.</p>
<p>I was pointed to another person but not connected with him – I needed to explain the whole problem again. The person was stand-in for my unavailable PM, but only on ordinary projects. This project was classified as special, so it was a no-go there.</p>
<p>I was asked to give him my phone number so that the unavailable PM can call me with instructions how to settle the situation. But this would only mean it would be delegated onto me and I would be doing something my superiors told me not to do.</p>
<p>At the end, the PM had to come online during his unavailability to deal with the situation he had no knowledge about. That regrettably prompted the communication to include errors which needed to be remedied by someone available and not instructed to do nothing.</p>
<p>Instead of simply sorting it in 30 minutes tops I was asked to spend hours explaining problem multiple times. I was to look for somebody with a role of project manager who would had information about project that I had already and watch as it proved to be inconvenience for everybody. Eventually it did not even get solved using this approach.</p>
<p>It was a nice example of how trusting your team, spreading the responsibility and ownership will always be better solution than waterfall where everybody has clear set of responsibility, where if one important person leaves, the team will fall apart like house of cards.</p>
<h4>My regrets – lack of research</h4>
<p>I do not regret pulling that stunt with project management nor consider it my mistake. I regret that the people who praise agile as the next thing we all must strive for, failed to even start thinking in terms of agile and still live in waterfall world.</p>
<p>What I regret was not having or making enough time for testing. This would be the perfect opportunity to perform some guerrilla testing with co-workers, spreading the UX culture little bit more by getting people interested in some fun activity.</p>
<p>I had plan to create a prototype which I would put on tablet and went around the office to test it with random people. Somebody walking to them and handing them tablet with black and white prototype asking for their input and how they would use it – that would surely distract them from the daily routine and show them the fun part of UX.</p>
<p>I made the prototype and put it on tablet. But I had other project to focus on – one that was more important to me even if it was way more painful one to deal with. And so I have never found the time to test it with people outside of my team. It made for an interesting showcase inside the team but that was it.</p>
<h4>Conclusion</h4>
<p>It was shameful to watch these problems unfold and play role in them. But I sincerely believed that a wakeup call was necessary. Nevertheless, the message did not get through. Once again, the clueless people were saved by someone else. I was also blamed for not handling it despite the fact I was told not to. Sometimes you just cannot win.</p>
<p>As for my dream of guerrilla testing in the office, it was painful but I will find other opportunities. When it happens again, I will find the time.</p>Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-49338599574770842332017-11-04T08:47:00.000+01:002017-11-04T08:50:57.672+01:00Masking flaws of AI as benefits<p>AI is turning into a big boom that will soon become the next thing. Before that happens it is important to help it and hold its hand to hide the obvious imperfections that are yet to be solved.</p>
<a name='more'></a>
<p>Chatbots, analytics tools, androids – they all are possible to make but insanely hard to perfect. The more AI needs to interact with humans, the more it can fail in the eyes of its audience. Speech, shape recognition and empathy are easy for us as humans because they come in naturally to us. This is not the case with computers.</p>
<p>Consider how weird online language translators can translate some sentences. Add understanding of previous context to the mix and the complexity grows exponentially. No wonder chatbots are hard to pull off. For that reason many try to find other means to solve the problems:</p>
<ul>
<li>make chatbots stupid on purpose</li>
<li>prepare scenarios and turn chatbot into long series of condition</li>
<li>focus only on one very specific feature or topic</li>
<li>use humans as Wizards of Oz to pretend to be an AI</li>
</ul>
<h4>Basic concept – Simple yet complex survey</h4>
<p>A challenge somewhat accidentally landed on my desk. I was tasked with looking at simple survey gathering feedback about AI conference. The design was little bit off, some of the features were clunky and the flow was not as clear as it could be.</p>
<p>Objective of the survey was to gather feedback from users and put it into NPS values. Anything beyond that was no longer primary business goal.</p>
<p>The whole flow for users started with picking a language. Once it was selected, first question would appear in selected language. There were multiple text boxes, icons, buttons and other elements present in the view. Each question was in separate view.</p>
<p>View with first question looked like this:</p>
<ul>
<li>an introduction to survey on top</li>
<li>unlabelled icons working as buttons – one started recording, other stopped it</li>
<li>a box where recorded voice of user appeared as text</li>
<li>a text of first question</li>
<li>a button that let AI analyse the answer</li>
<li>an input with NPS value</li>
<li>a button that let user proceed to another question</li>
</ul>
<p>Pressing the button to analyse the response in text input, put NPS value deduced by AI into the NPS input and displayed text informing user of the analysis and decision – showing the same value as was put into input. The NPS value could be changed or filled by user from the very beginning and thus this whole analysing could be skipped.</p>
<p>Another views – questions – followed similar template, but since intro was not needed again, the question took place of the intro and therefore the question was located in different location on other views than the first one.</p>
<p>Users could ignore AI and only pick NPS value. Or they could ignore speech-to-text functionality and type their answer which would then be analysed. If they wanted to use all of the features, they would listen the AI to read question from paragraph, answer with voice using clunky interface, wait for answer to be analysed, correct the NPS value or keep it as it was, and moved to another question.</p>
<p>To make it even less consistent, some questions had these features and some did not. Right the second question was read out by AI, but user could no longer reply with voice or have their text answer analysed and parsed into number. This could be problematic. As the moment users understood the system during the first question, this newly found toy of theirs was taken away from them as they moved to next question. There, the users were left with half of the features and big pile of confusion.</p>
<p>It was not just the interface that suffered. The AIs method of analysing text was imperfect. Stating a number from NPS scale would make the AI pick different number. Stating different phrases such as “good” and “awesome” would be both translated into the same value – rather extremely positive value. Same for “bad” and “horrible” as they both represented extremely low and equal value according to AI.</p>
<p>AI did not comprehend context and therefore questions “how likely would you…” would not have correctly analysed “very likely” as an answer. The AI would simply translate it into default average value despite being pretty good if context would be taken into account.</p>
<p>Upon chat with engineers it became clear that the strength of the AI was in long answers where it could attach emotions to words and phrases. And yet even that would still be imperfect.</p>
<p>With all this mess it seemed weird to even use these features. They were not needed to fill the survey, could be skipped and were pretty much in the way. But they could be salvaged and put to use if done right.</p>
<p>So lets recap:</p>
<ul>
<li>numbers were evaluated as different NPS value (fun fact – number written as word and the same one written as a digit would be evaluated differently)</li>
<li>short phrases and words were either one of the extremes or average should the AI not understand it (e.g. “hfjfhfjfjfhhf”)</li>
<li>long sentences were stronger point but still weak compared to expectations</li>
<li>there was clear inconsistency between available features per each question</li>
<li>features did not really have any reason for being there</li>
<li>interface was hard to understand and unintuitive</li>
<li>there were lots of cool features, they just lacked structure and reason for being used</li>
</ul>
<h4>New approach – make it a game</h4>
<p>To make the task even harder for me, clients were actually not sure about how, where and when the survey will be filled. This became the first major question we needed to settle. It become imperative to learn what device and platform will be used, when will the users use the survey, who will the users be, what's the goal of the survey, etc. I was also curious why NPS was chose as the form of the evaluation of feedback.</p>
<p>I got in touch with clients and after some back and forth we mutually agreed that survey will be primarily filled by attendees during the conference. Plan was to have hostesses carrying tablets asking attendees to fill the survey. There was also secondary way – sending survey via mail after the conference for additional feedback.</p>
<p>The second struggle was the structure – the logic of the user experience. This was AI conference and therefore using AI in survey sounded fitting, but with so many problems it lacked proper justification. Why is this bad AI doing something in my survey? What’s its purpose?</p>
<p>If I was not sitting down when it hit me I would have lost my footing and fallen. The key problem with AI is that people expect too much from it. They rarely understand that AI needs to learn on millions of examples before it is even useful. Why not present this and use this crucial detail? After all, it is AI conference, some will understand it and others came to learn it. As for us, it was the break we needed.</p>
<p>“Hello, I am AI and I want to learn new things. I can help you fill in the survey, will you help me as well?” That was a dumb draft of the intro. Users no longer had to use bad AI, they were teaching new AI how to improve. The feature of random talking and listening was replaced with simulation of chat. Users were actually communicating with this AI in a controlled environment as if it was their friend.</p>
<p>To make the users feel more motivated and thrilled there were supposed to be small elements of gamification to provide extrinsic motivation for the users. Few stats telling people they are the first filling the survey – the first to build this community of players – or informing them how many people filled it before them to let them know they belong to a big community of other attendees who filled the survey. There were also other stats related to each question.</p>
<p>Badges were introduced to reward people for making it easier for AI. They never knew how important it was for the analysis feature to have long sentences. What they knew is that there is shiny badge for them if they answer with genuine and longer answer and not just a word.</p>
<p>Beside helping the computer, badges were also there to let users get familiar with the concepts of gamification and to reward them for filling the survey. At first I was thinking about making them visible from the start to let people know what they can achieve. Later on my teammate on the project proposed to show the badges and stats after the answer of a first question. This new solution would gradually reveal gamification aspect of the survey so that users are eased into it and not overwhelmed by it from the start.</p>
<p>Few questions did not have this analysis in old version due to time restrictions as it needed to be coded for each specific question. But this would no longer be a problem in the new version, therefore, we could enable the feature even for those questions. Users were not relying on AI, they were helping it learn. If the AI took a bad guess or even admitted that it is not sure and asked the user to help it pick a value, it would be absolutely reasonable situation. The expectations have shifted massively.</p>
<p>The premise of user experience moved from simple survey to opportunity for users to teach AI something new, talk with it, be part of community with other attendees and play a game – all at the same time.</p>
<p>But there were still use cases when all these fancy features were useless. So instead of letting people choose during each question, we divided them right at the beginning. On the screen with intro they were asked if they want to use AI and help it learn or fill simple survey without AI. Questions were same for both options. The difference was that one had no additional gimmicks while the other one had chatting with AI and gamification.</p>
<p>This was an interesting concept to toy with. As it was being discussed we were also solving a third struggle – content and copy. Some of the questions were redundant, duplicated or just way too long, requiring explanation for what they are actually asking for. So we sat down with team and clients to rethink the questions, their purpose in higher scheme of things and the correct way to ask them.</p>
<h4>Collaboration and designing UI</h4>
<p>The masterplan was formulated and approved. Next step was putting it on paper as user interface. How to make it look, how to enforce the flow and make it great and intuitive experience for users?</p>
<p>I called a meeting with designers, PMs, frontend developers. Goal was to brainstorm some designs and small design features that would enhance the overall feel. I was open to suggestions not only about layout but also gamification elements, animations and ways of interacting with the survey. It was incredible session with dozen of ideas as an outcome.</p>
<p>After our big session, a visual designer and I sat down to pick a way to go and polish it. We had multiple sessions – brainstorming, rethinking, analysing.</p>
<p>We created drafts. We sent them for approval. We created black and white prototype. And after careful studying of visual standards and branding for the AI, the designer carefully crafted stunning pixel-perfect mockups and turned them into a prototype.</p>
<p>There were some worries about the default branding for chatbot of our specific AI not really looking like chatbot. But we were not here to do branding strategy, we came to create epic experience for users filling the survey. So we trusted the branding and adjusted the bits we could to make it fit our needs.</p>
<h4>Conclusion</h4>
<p>Project was well received by the clients, the users and the management. There was even an initiative to do something similar in other surveys – to start thinking about them in different way than just surveys. We all received praise for our work, responsiveness, proactivity and creativity. And yet I could not stop hearing the irony of this success as I was aware of <a href="http://thinker.taja.sk/2017/11/problems-and-regrets-of-my-survey.html">the problems that occurred and the regrets I held about this very project</a>.</p>Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-91545168395449514402017-10-17T23:16:00.001+02:002017-10-17T23:17:32.834+02:00Letting non-designers and amateurs create features<p>It is dangerous to give control over an idea or already existing product to non-designers or amateurs. Despite their disbelief and even with best intentions in mind, they lack the skill and knowledge to design features and changes.</p>
<a name='more'></a>
<p>I have noticed this on so many projects. Whether it was because of programmers, project managers or global leaders pretending to be designers, or sloppy and amateurish work – even mine at times – the project always suffered. Sometimes just slightly and sometimes so much it became a disaster that needed to be taken off and hidden from sight of all users.</p>
<h4>Clean slate is an opportunity</h4>
<p>In one of my previous posts I addressed <a href="http://thinker.taja.sk/2017/05/minimal-viable-product.html">minimal viable product</a>. It is topic I will touch on.</p>
<p>Even though it should be standard to simplify products over time, it is not realistic. There comes a point when you have to take what you learned from old, overcrowded version with no place to add new updates and simply start over. A clean slate – in a sense – where you can use all the accomplishments and positive feedback you gained, incorporate solutions to negative feedback and most importantly, don't repeat the same mistakes.</p>
<p>Every product goes through this stage once in a while. It usually takes years to arrive at this moment. As you are working from scratch to rebuild the old thing into a new thing, you must be ready to support the old solution as you are building a better one until it is ready to see the light of day.</p>
<p>This is something many people tend to miss. It requires implementing a change and that comes with possibility of failure. Some are scared, some just think using legacy product and cramming as many features in as possible, is a way to go. This thinking prevents innovation and improvement.</p>
<p>Last time I was redesigning a product which was literally flooded with mistakes and bad decisions, I had the luxury of working in a team of people who understood the need for minimalistic design. And even though we had full control over the direction, there were “the others” watching over us, waiting to strike.</p>
<p>We made minimizing the tool and reducing the clutter our job. We wanted to implement only useful features and leave behind everything that was there only to stand in the way. While we were reducing volume of the tool by more than a half, we made it actually joyful to use and capable of performing every task it was expected to. The others from outside our team wanted to add features that would solve no problem and bring absolutely no benefit.</p>
<p>We endured and our tool received positive feedback. It was simple, yet powerful and it was fun to use. But we eventually had to end maintaining it. We took new projects and this one was handed to the next team, a team without UX designer.</p>
<h4>New release with no problem to solve</h4>
<p>When we lost control over the tool we tried to at least remain as consultants to be able to shape the decisions and direction of the new updates. It was good call considering the first design of a new version made no sense.</p>
<p>There was a clear problem to solve – a fact that surprised me. Their strategy was clear and the benefit of requested solution was reasonable and worthwhile. Yet, the design did not solve the problem. Instead it went ahead creating more problems. The working parts that were good were to be redesigned in a horrific way while the bugs plaguing users tasks were not supposed to be fixed.</p>
<p>The new features that were to be added were not only useless but already tested and found out to be useless in the old generation of the tool. The problem which was the sole reason for the new release was never addressed in the design of the release.</p>
<p>Despite our best efforts to explain this – suggesting pixel perfect mockups of an actual solution that was always part of the overall strategy of the tool and therefore prepared to be implemented – the new nothing-solving design was chosen.</p>
<p>Instead of releasing a version that would comply with the strategy for the tool and process, would take 2 days to develop and would actually improve the tool, the new leaders of the project decided to spend 2 months of development to make the tool worse – keep the same bugs, implement useless features, ignore requested features and destroy already well working features.</p>
<p>And so the tool is pain to use now. It goes back in the direction of the old legacy tool by introducing useless features, maintaining all the bugs, worsening what works.</p>
<h4>The disaster with no strategy</h4>
<p>I already addressed <a href="http://thinker.taja.sk/2017/05/tech-experts-and-users.html">technical experts messing with design</a>, but lot of times it is not developers or tech leads, it can also be managers and leaders.</p>
<p>The worst thing that can happen to a badly designed product is being taken down, swept under a rug and then be resurrected with the same problems and mind-set expecting different outcome.</p>
<p>Another tool I had the luck to come across was one that needed to be done immediately, or yesterday, if you wish. We spent Friday evening and night in the office because of the great importance of it.</p>
<p>The first red flag – among many that emerged – was the claim that it is important because of big strategy that was to be implemented across the company and this tool was essential to it. Ok, so why was it not requested beforehand and actually done properly instead of rushing it in a day. It spoke a lot about the so called strategy.</p>
<p>Another red flags were visible right as we looked at the premise of the tool. The outcome was not clear, the users were no clear, the numbers we were supposed to use in the tool were flawed and the best part of this was the communication with clients.</p>
<p>I realized an issue in the current process, issue that constantly needed to have workarounds. The new tool was of course not solving this issue but building on top of it. So I asked the clients about it, told them about it and the of workarounds, suggested different approach based on research – although limited due to time restrictions – and the reply I was given was a rhetorical question: “Does the current process allow that flawed course of action? Yes. So we will use it.”</p>
<p>I was astonished. Of course current process allows a flaw in the current process. Its the most ridiculous thing I have heard. If you asked that every time something needed to be fixed, nothing would ever got fixed. It just ensured me that there was no intention to improve anything, there was no strategy, no plan.</p>
<p>Tool was later found lacking in certain areas:</p>
<ul>
<li>It was visible to users for whom it was created and approved – that was evaluated as a mistake as those users were not supposed to see it.</li>
<li>The incorrect numbers which were communicated to the clients and approved anyhow were found to be incorrect.</li>
<li>The tool was criticised by the clients for being rushed and done too quickly by us and therefore very minimalistic and using incorrect numbers.</li>
</ul>
<p>For these reasons it was removed, hidden, destroyed and never spoke of again. Until month later when it needed to be done in 3 days as it was part of big strategy across the company. The users who were supposed to use this new tool in the mere 3 days were not aware of anything happening, the features and numbers were kind of a guess and the process “allowed for flaws”.</p>
<h4>Conclusion</h4>
<p>It is important to use opportunity to minimize product, start over and not be afraid of it. Legacy software is usually riddled with things that are not supposed to be there anymore even if they once served a purpose.</p>
<p>When designing new version, do not add features that are not needed. Focus on solutions to real problems. Your tool will remain good and will live longer in long run.</p>
<p>Strategy and design are tied together. If one is not present, the other will not save it. Having perfect tool with bullshit goal is going to end up a failure. Expecting different outcomes with same inputs will also go sideways. For that reason it is important to work on foundation before moving to walls and roof.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-37282497688323319482017-10-08T22:10:00.000+02:002017-10-17T23:12:30.495+02:00Project management in waterfall environment<p>With the current hype to use agile methodology in software development it is easy to forget that it is not always possible. Let's look at those moments and the experience of being a project manager in waterfall environment.</p>
<a name='more'></a>
<p>Whether it is caused by project conditions or situation in company, there are times where waterfall simply is the necessary solution. You can try to make use of values and principles taken from agile methodologies, but you may fall short due to reality you live in.</p>
<p>I had limited exposure to this world but I dare to say it was rather extreme one. Everything was on fire, there was not enough time, budget, leadership, knowledge and skill. It was harsh and thankless job. It taught me that work of PM is way more difficult than I imagined.</p>
<h4>The beginning</h4>
<p>It all started with a project that was rather lengthy. It spanned across roughly 9 months and was part of major PR (public relations) campaign. Failure on our side as designers and developers would result in failure across entire company. Shamefully, leadership did not agree and therefore questionable people got on board with major responsibilities.</p>
<p>It did not take long for everything to go horribly wrong. Signing a deal without knowing what was part of it, agreeing on budget without having estimations or knowing the scope, promising miracles without realising it is not possible to deliver them.</p>
<p>There were red flags all over the place, but they were too hard to spot so soon into the contract. Minor slips in due date here, miscommunication there. It was suboptimal but doable. Although I tried to help with some of the issues I noticed, I was not in a position to do that, I was just some random designer.</p>
<p>I have had my screw-ups as well. Whether it was insofficient documentation and preparation for all possible scenarios of user journeys, and tool error messages. Many of these were at first caused by lack of time and later on by the need to handle other aspects of the project. I became a senior technical consultant with expertize on writing optimal backend and frontend code.</p>
<p>My involvement in technical development became neccessary after realizing that the website that was developed took minutes to load, reloaded after rendering and afterwards loaded completely differently. And so I became spread thin saving the product, because what is the point of having a good design when the end product is just unusable due to horrible code.</p>
<h4>The explosion</h4>
<p>It was not the perfect example of how to develop products, but it was kinda moving forward. And then it exploded. Not even halfway through the requirements of initial release that was supposed to be followed by 7 more, the budget ran out. Yep. Work was not finished, there were 7 more releases besides the unfinished one and there was no more money.</p>
<p>It was around this time I started to be ignored by leaders of the project. Luckily it did not last long. Leadership was soon replaced attempting to salvage the situation and turn it into a win. A new PM was assigned to handle the whole campaign. Shamefully, not enough resources were committed and so the situation remained dire.</p>
<p>Mistakes continued happening as it naturally is when your foundation is crumbling. And so despite objections, warnings and tons of whining, not much improved. Situation stabilized at unwanted levels of failure. Even though we started delivering, we did so slowly and costly. 7 releases were no longer a possibility.</p>
<p>One thing that kept me bugging was the lack of will to fix things. The more I pushed for improvements, the more I was told to let it be. There was fear that if we tried then it could fail. If its broken, let it be broken.</p>
<p>Luckily there was one person willing to settle the situation, a PM with skills and knowledge who either realized I need help or simply could not listen to my whining anymore. Either way he started to stir the water which enabled me to push for more.</p>
<h4>The replacement</h4>
<p>I was forced to leave the project for couple of weeks, but before that I became determined to save the situation.</p>
<p>First step was to find the correct people. So I tasked one of the best frontend developers with refactoring the code. With this deed she managed to reduce the file size of code by about 70% to 80%. The result was astonishing so I asked her to remain in team as lead frontend developer.</p>
<p>Second step was to find replacement for myself. I worked with very talented and smart mentee for half a year at that point, so even though it was on the last notice, I asked her to look over the project and put her in charge of a new major release.</p>
<p>Lastly I found a PM who had enough skills and knowledge to oversee the situation. It was the one who helped me stir some water before, so this whole enterprise could even become a possibility.</p>
<p>I did not engage him directly but I involved him in the project hoping he will step in if it became needed. And it did. He played major role in coordinating the team, even helped out with design and development.</p>
<p>Building the team was essential for a success. The fact some members of the old team, like the designers, could be relied on, helped a lot, as I did not need to assemble completely new group of people.</p>
<p>I gave out instructions and let the leaders handle the rest. I have soon found out that was a mistake. It turned out that assembling team of experts, giving out all tasks and trusting the leadership to oversee the situation, was not enough. I forgot to appoint someone who would hold hands of the old core team who was still very much in charge.</p>
<h4>Overthrowing the old team</h4>
<p>After I became available again, I noticed work is not yet finished but definitely on the right track. It became my strategy to help but keep the distance if possible. This still-not-so-well oiled machine was making progress that the old team simply could not.</p>
<p>It was important to me to thank each of those new people to make sure their understand their contribution in saving a project that would have failed otherwise, a project they could refuse so easily and yet they did not.</p>
<p>Although, despite the obvious improvement in progress of the project, it was not enough. I was asked by the new PM sent before to salvage the project to be his stand-in during his sickness. I accepted and took over, consulting with the PM who helped me stir water before my period of unavailability.</p>
<p>We had people, we had resources, skills, experts and will. Next we needed a plan – schedule of releases, list of all the features and their deadlines. Something that should have been there from the very start.</p>
<p>One meeting with clients and our goals were aligned. It was time to set out to work and for the first time in almost 9 months, actually deliver on time.</p>
<h4>The stressful management</h4>
<p>Even though I am tempted to call it a leadership, it wasn't. It was management. I was doing my best to remove obstacles, keep taps on the situation, keep everyone in the loop, discuss with the clients, discuss with the team. I was never leading them, I was managing them.</p>
<p>Looking back I do not believe anything else was possible. I tried to take on every responsibility that was not covered by someone from the team. I became coordinator, focal point for clients and major pain in the arse for the team.</p>
<p>I realized that I need to trust them and their judgement, that they need to work together and must not have any obstacles like missing information from clients or projects to work on from other PMs.</p>
<p>I have to say I am proud of the work they have done. They pulled overtimes I did not ask for because they believed in the project. I am happy to say the deadlines were met for the very first time. And not just one deadline. All of them.</p>
<p>We were truly successfully delivering on our promises for the first time in the whole lifetime of that project. And it would feel great, only if it was not for the stress.</p>
<h4>The unhappy ending</h4>
<p>The stress started taking toll. People started getting sick and emotionally unstable, me included. It eventually forced me to restructure the team – decision that was extremely difficult. I evaluated that stressed people can no longer work under such conditions and pulled them out. It was one of the most difficult things I have ever had to do.</p>
<p>I could have analysed it incorrectly, I could have doomed the project, I could have lost friends and colleagues who could potentially help me with other projects. It was painful. Nevertheless, I believed it was necessary if we wanted to continue successfully working on the project. One angry person exploding at the wrong moment can destabilize the whole team and that can quickly turn into a disaster.</p>
<p>With all the stress being constantly present I felt the need for some help or at least acknowledgement of the work I was doing. What I received was precise opposite. I was escalated to my superiors for not managing my time properly, focusing on responsibilities I was not meant to focus on, being sloppy and negative.</p>
<p>All of the sacrifices, hard work, sleepless nights, all ignored. It was at that moment I realized that this is a thankless job at times. The people who failed to act the whole time suddenly came out of woodworks to judge me and be generals once the war was won, providing hindsight advices on how it should have been done and how they would do it even despite the fact their ideas were contradicting themselves.</p>
<h4>The lesson</h4>
<p>My team was composed of the best people I could have hoped for. I am grateful to each and everyone of them for all they have done and the heart they put into their work.</p>
<p>I have learned a great deal about management, its downfalls, obstacles and challenges. I understand the need for usage of agile methodologies but I also understand it is not possible unless the situation supports it.</p>
<p>And for those people on top who decided not to have my back for saving their reputation and name, well, it was the last time I helped them. It became a time for me to embark on a new journey to find the next promise land. But that is a story for another time.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-62478710776531097862017-06-27T17:57:00.000+02:002017-12-24T16:03:26.860+01:00Workshops for students of primary school<p>I find presenting UX and Design Thinking to adult audience quite challenging and rewarding experience. Having audience made of teenagers can be even more of a challenge. Last week my audience were 5th graders and 7th graders from primary school – children. What were the obstacles, the approach and the result?</p>
<a name='more'></a>
<p>Our organization <span class="emph">Nation of Technical Excellance</span> (NTE) was cooperating with another school to provide presentations and workshops for students. This time we were asked to come see our youngest audience yet. My colleague spoke about facts and critical thinking, while my topic was <span class="emph">design.</span></p>
<p>To get ready for this task I firstly set out to accumulate some knowledge about whom am I going to be speaking with, what are they like and what can I expect from them. In short, I started with <span class="emph">research of the target audience</span>.</p>
<p>Originally, the plan was to only make this workshop for 7th graders, but it was such a success I was asked to do it again for the 5th graders.</p>
<h4>Research and strategy</h4>
<p>Age of the audience was ranging from 10 to 13 years. That proved to be quite a difference from what I was used to. <span class="emph">Their communication skills, interests and goals were all different from those of my peers</span>.</p>
<p>Children like to play, draw, be creative. So I used that. They are also less worried about real world around them. But they were of age where they are starting to be competent and aware of their surroundings enough to understand certain principles.</p>
<p>I build my strategy around <span class="emph">playfulness and interaction</span>, trying to keep theory to a necessary minimum. Most of the time was allocated for simple tasks revolving around drawing and discussion.</p>
<p>Worrying variable was their imagination. I needed to be prepared for logic I do not understand anymore. Their creativity could go wild so I needed some guidelines. On the other side, they are children and therefore I could not limit their creativity, I had to work with it.</p>
<p><span class="emph">Communication barrier</span> was another aspect I had to consider. No English words, no technical words, no expressions that a child would not understand. Keep it simple but be able to express myself.</p>
<h4>First impression</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFtKkEuK3IRp4NJvU2jRrNvtq4TjsPU_Sul3ho59IIVGXUiFklE2v0JWtIwHeOvfpIiLsfoxMTkAeVEIh4Wc3focRPjqrAlfPxEZ_u2kgLj5qm1x9Zhy6oi_mBR6o5-eO4jw1YRghm_Ic/s1600/bystricany_2017_04.jpg" class="full" />
<p>Before the workshop started, I needed to <span class="emph">make a good first impression</span>. For these children I was another old dude who came to talk about boring stuff. And so as they started gathering I started addressing them.</p>
<p>I did not want to ask generic "how are you doing" questions or questions other teachers might ask. On the other hand I had to keep it on the level of small talk, not going too deep nor too technical. So I asked what class they are skipping by being here, whether they liked that class.</p>
<p>Since my starting pitch used art, I asked about exactly that. If they paint, model, animate, etc. I tried to keep the conversation going while <span class="emph">slowly getting them comfortable discussing the topic of the workshop</span>.</p>
<h4>Introduction</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcOkcZbuxujhQ6mEZmAoCyU9zPq1qUfKHMD0rUSyzaRDzO7XC-jogCYnlndSIspY6trRqaGTDRuAP7JXO6flhb2M6iLVHcktHCmMzwJMiuSbtfMkzvSTTUdAKEyaig6ibfr2s7eFDeUxU/s1600/2017-06-21+07.55.54.jpg" class="full" />
<p>I needed to react based on their knowledge, as it may vary greatly. I wanted to <span class="emph">get them curious</span> to know the truth, to listen to theory. To do this I focused on asking questions that students might not have answer to. They just had to be easy enough for them to understand.</p>
<p>To slowly ease the students into the topic I decided to open up with something they might be familiar with – I choose art. I showed the students some pictures of art and some pictures depicting design, and asked them to decide whether the pictures are art or design.</p>
<p>Next step was to give them some background into art and design, to explain the difference. It was time for theory. I carefully made sure it is short not to bore them. In just two slides I named couple of <span class="emph">main differences between art and design</span>, focusing on the functionality aspect of design vs aesthetics of art.</p>
<p>I included photos from corridors of the school in between art vs design explanation. I wanted them to <span class="emph">connect with the topic</span> and let them know that <span class="emph">what I am talking about is right outside the class door</span>, in corridors they walk almost every day.</p>
<h4>Core – Problem</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitk8dZyTyXcbtNBNkL7QKhwmJPiWinXyOgnoa4CFZN4BnblVwyrzcjxqsswcEvVzoT6IhrcTkNCZg_OsxUyc04N4pxVPBUdd7j0RNZJhknjsduBjWebhadm8XBAm1ozK599WnS4pYkJX4/s1600/bystricany_2017_01.jpg" class="full" />
<p>Intro into topic was followed by tasks. I wanted my young audience to have fun, to play around, and to experience designing on their own. That is the best way to get people to remember what they have learned.</p>
<p>First task was to think about a product they could create. I emphasized that it is supposed to <span class="emph">solve some problem</span>. This was a straight-forward beginning. I wanted the students to form their thoughts before we truly started designing.</p>
<p>The 7th graders had no problem. They were sticking to reality and solving rather real problems. Some of them were already solved, some of them were little extreme but fun, all of them were doable though. There were ideas such as food ordering app, sports app, machinery for building structures.</p>
<p>The 5th graders were on loose chain. Their imagination made it impossible to stick to reality and so I let them run wild. There was always a way to pull back a little so I simply waited to see if that becomes necessary. Their ideas here included suit that changes you to whatever animal you select, pen that can write instead of you, robot that checks whether store is open, and others.</p>
<p>Those who did not come up with anything could still work on this task during the time for the second task. This was done on purpose because the second task was all about the <span class="emph">problem and a solution</span>.</p>
<h4>Core – Story</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-BWJQPDru1-CQviPQ0jeQE5KU_1IC4nDSBfJXos5fXNP_RoDvfPT5oYCJ3U6yLXip8tpIdFJbqruqTOz76VVDSbKh-pJYdcDj2IsszZIwbrKyPlqVzXRGtN_KR624fQcq9F2awUEb5T8/s1600/bystricany_2017_05.jpg" class="full" />
<p>I asked the students to <span class="emph">draw comics depicting their users struggling with a problem</span> and solving it using product designed by students. 4 panels were enough:</p>
<ul>
<li>Problem – image showing the problem user is facing</li>
<li>Idea – user gets an idea how to solve the problem</li>
<li>Execution – user uses product to solve the problem</li>
<li>Satisfaction – happy user and solved problem</li>
</ul>
<p><span class="emph">An easy and yet powerful story that forced the students to think about the meaning of the product</span>. It was no longer only about making something random, now it needed to make sense. It needed to be useful. This was difficult with the 5th graders, but it was still fun.</p>
<p>Those who struggled with creating an idea or their idea for a product was too broad, now had to specify a problem and a solution.</p>
<p>Some of the students enjoyed the drawing and went for quality. Some of them kept it uncomplicated. I pointed out multiple times it was okay to <span class="emph">keep it simple</span>. After all, design is not art.</p>
<h4>Core – Wireframe</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgugzWvpo_w6JFkK78f2wBWYVBswv_c3NVMJ5KbR_A1KDFa7NfdW5EjHTarFhe7irayAXmLyiufgow3q73-lZuHAH0SpPlTWs93Abqi-oaiKfhWpSy_zpZ8GB91zBXdn9TJuh1sh7dU6gU/s1600/bystricany_2017_03.jpg" class="full" />
<p>Wireframes are a core concept when trying to explain <span class="emph">structure and logic</span>. And since I wanted to encode the thought of structure and logic into the brains of my audience, I choose to let them create wireframes of their product as a next step.</p>
<p>Just one simple black and white view was enough. Although I tried to get the majority of the students to focus on displays, some worked on sketching a hardware.</p>
<p>One of the 5th graders was so natural at this, he also created multiple views and interaction between them. It was inspiring to see someone so young with so much talent. And it all made sense!</p>
<h4>Core – Testing</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEircXOoIqPJbsmHJFxkfWCEa90IrlCFiTwWEqDAt7lHTHR8Cy9zRZJeuT7RdDhz3LUDghRH0pNbUMoOBqBqDBiyrgnb2MjJHmHZidWPLidFiyJVtqZA2i-yzp5Eu8J5DiAVCpDkvXv7nd4/s1600/bystricany_2017_02.jpg" class="full" />
<p>I have to admit that this was my trump card. I was not fully planning on doing this activity unless there was enough time. And with 7th graders there was enough time.</p>
<p>I improvised and asked my colleague and the principal to walk among the students and try to guess what the products are and how they could be used. <span class="emph">I wanted for the students to see that people might misunderstand their design</span> or ask questions about them.</p>
<h4>Ending</h4>
<p>I ended summarising all of what happened there. The meaning of design and the ways of doing some of it.</p>
<p>What followed was a massive applause from the students. It caught me by surprise and I had to take a sip of water to hide that I had no casual emotional response to it.</p>
<p>Principal came to the front of the class and started showing individual slides as he was explaining how to do a good presentation. He stopped on my slide about research, which has been visible during the first task when the students needed to think of a product they wanted to design.</p>
<p>The research slide became a symbol of every activity. When you want to create presentation, you need to do research. When you want to throw a birthday party, you need to do research. Research is crucial first step for every designing. And the principal understood this.</p>
<p>Second applause occurred alongside a second sip of water. And the workshop was finished.</p>
<h4>Evaluation of the experience</h4>
<p>It was important to move in between the students and <span class="emph">talk with them</span>, try to help them, make them all feel special but also equal, provide feedback to let those best improve even more without criticizing too hard and creating hostility.</p>
<p>Majority of the students were extremely active. I cannot tell for sure whether it was my way of making first impression or the culture of the children, but they all started talking with me without being afraid or even feeling the need to raise a hand. They were <span class="emph">having a discussion instead of being shy</span>, which is something very uncommon in Slovakia.</p>
<p>I found out that I felt <span class="emph">less stressed interacting and improvising</span> than to be presenting something I had prepared. By opening up to students I not only relieved their stress levels, I also relieved mine.</p>
<p>This workshop helped me <span class="emph">realize many things about younger students and about myself</span>. It helped me think differently about workshops and gain some of the soft skills I lacked.</p>
<p>I can safely say, I am not done yet. I will continue learning and teaching others. But from now on though, I will try to be lot more interactive when possible.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-5058516586642348872017-05-23T11:16:00.000+02:002017-05-23T11:16:15.538+02:00Tech experts and users<p>The more specialized a person is at one thing, the less she can see into other fields. Experts opinion must be valued but it tends to happen that it is hard to get them to value other opinions as well.</p>
<a name='more'></a>
<p>After all, they are the experts, how dare you even to suggest they might be wrong. It is equally challenging to explain that they might not be wrong at all, it is just that other people see problems differently and all of these views, including theirs are valid.</p>
<p>There are couple of scenarios where I noticed the "they think differently, therefore they are wrong and stupid" mindset coming from real specialists in their respective fields. And as a UX Designer I shook my head in all of those situations.</p>
<h4>Usability for newcomers</h4>
<p>One of our most important tools was getting major overhaul. I was not part of the project as the developers decided to do UX on their own. Later on they were forced by management to get UX designer involved.</p>
<p>It was very strange situation since there was not much for me to do. Tool was already on the way to be done so I had nothing to design. On the other hand it was not done yet and there were no proper sketches or wireframes so I could not give any proper suggestion.</p>
<p>It all spiraled towards conversation with lead developer who assured me that they have taken all the steps to assure that the tool is tailored to users needs. It initially sounded very positive.</p>
<p>Since the tool was very different from existing one I was wondering if users coming from existing tool and new users will both have the same ease of working with the tool. What I got as response was the look of disgust and the reply: "Whether the users can use the tool is not my problem."</p>
<p>He was right. It was not his problem. He was lead developer – technical expert. He focused on the technology. He wanted the code to be good.</p>
<p>This tool was truly tailored to the needs of the users. But it was tailored by the developers. And the more you work in IT the more you realize that developers think differently. Totally differently.</p>
<p>It the eyes of the development team, the tool might have been the marvelously perfect solution to all the problems. But it failed to take the users view into consideration. Will they be able to use it? Will they think the same way as the developers who made it were?</p>
<p>I am not going to deny the expertise of the lead developer when it came to leading other developers, making though technical decisions or coding, but when it came to users, the approach was lacking.</p>
<h4>Software framework</h4>
<p>Another example was a team of gurus working on a framework that very junior developers were supposed to be using to build software. These junior developers were in matter of fact so junior they rarely needed any previous experience or good knowledge of programming languages.</p>
<p>These juniors were quitting job left and right, being replaced immediately by new people who were educated into the role in extremely short amount of time. And they were all using this framework.</p>
<p>For such a specific group of newbie developers, it was really hard work to create framework they could understand and use. And of course the framework had to be technically optimal as well so that the software using it would not suffer.</p>
<p>After some time the gurus found a bug in their code and decided to fix it. The interesting thing was that huge number of the juniors were accidentally using the bug because they thought it is the correct way to use the framework.</p>
<p>It made sense to them when they looked at the documentation. The correct way to use the framework was slightly inconsistent with similar functions but the bugged way was always following the same logic.</p>
<p>With their limited knowledge, the juniors were analogically trying to use plain common sense – at least from their point of view – and it worked. Well, up until the gurus fixed the bug.</p>
<p>The software started having issues due to the bug fix. And the situation quickly got to stalemate. The juniors were not aware that they were doing it the wrong way since it made enough sense. And the gurus blamed the juniors for not understanding their framework enough.</p>
<p>Once again a similar situation where the experts knew what they were doing and they were doing good job. It is just that some of the users failed to grasp it the same way as they did. They did not think the same way. They had different mindset.</p>
<h4>How we think</h4>
<p>The UX field is important because normally we are rarely the users of the product we create. And therefore we have no idea how the users think. What motivates them, what they expect, what previous experiences they have, what they can and cannot do – how do they think? UX is there to answer these.</p>
<p>Even when we are the users of our own products it is important to realize that we are the ones who made it. We wrote it from scratch. Of course we understand it. We spend hours and hours making it. We made it in our own image.</p>
<p>Expert of each field view the problem little bit differently and it is by nature that we have problems interpreting other fields. "It takes one to know one". It takes one expert to recognize the other. But how can expert recognize a user and help her?</p>
<p>Cpt. Picard from Star Trek once said: "It is possible to make no mistakes and still lose. That is not weakness, that is life." It is not weakness that we all experience the world differently. In matter of fact it can be a strength, but only as long as we can still communicate and learn from one another.</p>
<p>Don't be that guy who knows everything and all those who do not are stupid. Don't think that being expert in one field automatically qualifies you in everything. Share your expertise and learn to understand your users or get someone who can help you with that.</p>
<h4>Tools are for the users</h4>
<p>Whether it was the major tool or the framework, both of them were meant to be used by the users. Therefore it was important for the users to know how to use them.</p>
<p>You can call them stupid, you can call them irrational, you can hate them, but at the end of the day, it is those people who use your products. And it is them who you make your products for.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-57635160291640917602017-05-15T11:43:00.001+02:002017-05-15T11:43:38.006+02:00Multiple stakeholders<p>Dealing with multiple stakeholders can bring unexpected problems. Their opinion about solution might not be unified, their very views on the problem could be different and dealing with all of them at the same time can be a rather messy situation.</p>
<a name='more'></a>
<p>Majority of projects I work on have multiple stakeholders. Some projects are simpler, some are more complex. One thing they all have in common is that each has its own traps to look out for.</p>
<h4>Complex tools – individual points of view</h4>
<p>Huge tools with lots of users and different roles will need to have more features to accommodate all of the tasks needed to be done. It gets even worse when there is tons of bureaucracy involved.</p>
<p>Lets imagine that you need to design a tool for hiring employees in big corporation. Here are the steps in the process that need to be followed:</p>
<ol>
<li>Fill a request for a role you need to fill. This is most likely done by very low positioned manager or project manager.</li>
<li>Superiors need to approve this request.</li>
<li>HR needs to approve this request.</li>
<li>Budget must be allocated by finance department.</li>
<li>Other internal tools must be synced with this tool to reflect the changes.</li>
<li>Reports from database must be generated for higher positioned managers.</li>
</ol>
<p>There is quite some steps and many roles involved in the process that this tool needs to follow. There is also possibility that some of the tools cannot be synced together and the data will need to be inputted manually by someone. Now this is horrible situation, but it is not so uncommon in corporations.</p>
<p>If you would have a stakeholder from HR, stakeholder from higher management, stakeholder from finance department and some technical architect acting as another stakeholder then you can be sure each of them will have completely different view on the whole concept.</p>
<p>HR will not care about financing the resource, finance will not care about strategy, management will not care about database size and architect will not care about soft skills and hard skills of new candidate.</p>
<p>Each stakeholder will of course believe that their point of view is the most important one. And yet all of them are important and completely unique. It will be up to you to align all of them and design a solution that would tackle all of them.</p>
<p>Things can get out of hand and there can be more dominant stakeholder overshadowing the others and neglecting to listen to their opinions. In this case you will not only need to listen to them all, you will need to persuade this one to do the same thing – to acknowledge others in the process as equals.</p>
<p>I recommend talking to each of them individually and getting their points of view without others interrupting. Gather everything you learn and then present it to the group. Prepare some solutions and arguments for it. At the end of the day, it will be beneficial for them all, if it is not botched work just because they refuse to play ball with others.</p>
<h4>Simple tool – distinct implementations</h4>
<p>Even simple tool can create problems when you are dealing with multiple stakeholders. It all depends on dominance of the involved parties. When you are just starting and are not as confident as seniors would be, it is easier for stakeholders to take the lead and start designing your product.</p>
<p>Stakeholders designing a product is bad for multiple reasons. The lack the knowledge needed, they are most likely not the users and they will most likely fight over how to design it if there is more of them.</p>
<p>What I can say is that you should always listen to your stakeholders, but that does not mean you have to implement what they want and how they want it without proper reasoning. That part is your job, your responsibility and eventually can be your problem if done improperly.</p>
<p>Present multiple solutions, discuss with stakeholders, but always keep the lead on the design process. If you are not confident enough, get a mentor, ask project manager to help you during presentation. Always keep your feet on the ground.</p>
<h4>Meeting with all stakeholders</h4>
<p>Meeting can turn into a war zone if it is not managed and equally balanced. This happened to me once when I was facing about 5 stakeholders completely alone and rather unprepared against so overwhelming odds.</p>
<p>Unless you are an expert, do not go into meeting alone against multiple stakeholders. Always make sure you are or have someone who can moderate the discussion. Balance the amount of people who are involved in the discussion.</p>
<p>If you do not have other option than to go into the meeting alone, make sure you can manage the number of stakeholders that will be present. Meet with only one if you are unsure because if you meet with them all, they will destroy you. They will. They like to do that.</p>
<p>As a matter of fairness I recommend following the same rules in opposite situation. Do not bring your entire team to meeting with just one stakeholder. It will be easy to lose control and start picking on the lonely stakeholder.</p>
<h4>Conclusion</h4>
<p>Even though the art of dealing with stakeholders is something that needs to be practiced over way longer period of time, here were some basic problems I encountered in my first year when I was dealing with multiple stakeholders.</p>
<p>Try to align their views, keep equality in their opinions and expertise, talk to them in private to get all the individual and unique information from them.</p>
<p>Do not let them hijack your design process and start arguing about how to implement it. That is your job. The implementing part, not the arguing part x) Ask for help if you need it.</p>
<p>Your team and stakeholders can be facing against each other when it comes to design and software development. Even the numbers of attendees for each team to not sparkle a conflict where one side will be overwhelmed by the other.</p>
<p>Keep these in mind and it will be easier to deal with more stakeholders. Just do not forget, there are other problems awaiting. The journey is just beginning.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com1tag:blogger.com,1999:blog-4751317502700026249.post-37489978755488568522017-05-11T11:25:00.000+02:002017-05-11T11:25:25.769+02:00Research interviews – Reality and practicing<p>One thing is to have the theoretical knowledge, the other is to have the practical experience. This time we dive into the reality of Research interviews: how it looks, what can go wrong, how to react in unpredictable situations.</p>
<a name='more'></a>
<p>In the <a href="http://thinker.taja.sk/search/label/Research%20interviews">previous posts</a> I already discussed some theory behind Research interviews. I gave the same intro to my mentees and with it they were sent into action.</p>
<p>The beginning was not painless so let us look at some troubles that complicated it:</p>
<h4>Wordiness vs shyness</h4>
<p>There are shy people and there are the unstoppable people. These are personality traits you have to count with. If you are talking to people you have never met before, you might not know what kind of person you are going to meet.</p>
<p>If the person is shy, you will have to make them comfortable, let them take their time. Break the ice as much as possible, just do not overdo it. You have to be ready to ask more questions and pay attention to what they say, get the subtle hints and react to them.</p>
<p>Talkative people are harder to stop than to persuade to talk. Give them the space to voice their opinions and give you what you need, but if they keep saying the same thing or they go too far off topic, do not be afraid to take the lead and guide them back to meaningful conversation.</p>
<p>People you know will also react differently than complete strangers. People who are stressed will react differently than calm people. There are lots of variables. So always try to keep your mind open and be empathic to the person you are speaking with.</p>
<p>Research interviews are private. Do not bring someones superior or colleague to it. I hope it is clear that it will completely mess up the atmosphere in the room.</p>
<h4>Bad start</h4>
<p>Mainly if you do something for the first time, you will mess up some things. You will be stressed yourself. Important thing is not to worry. You will get better. Just take a deep breath and start slowly. Prepare notes so you always have a backup plan to go to.</p>
<p>Even if the start is bad, you can salvage the entire situation by not panicking and just continuing calmly. If you forget to mention something important, decide if it is important. If it is, say it, otherwise let it be. You will mention it next time.</p>
<p>It is good to come with someone more senior or your friend who can help you out in case you get stuck. At least until you become confident on your own. But it is also important to become confident eventually and not always seek help.</p>
<h4>Cooperation with assistant</h4>
<p>Whenever you are working with your colleague or friend together on Research interview, it is essential to that you work together. Do not interrupt each other, do not fight for authority, etc.</p>
<p>Interrupting each other does not help anyone, even if you do not agree with the question your co-interviewer is asking, let her finish – unless it is very inappropriate question. Even if you are unsure, make it appear like you two are rolling together and you both have done this million times before.</p>
<p>Try to stay in the topic. Let your co-interviewer finish all her questions regarding certain topic or subtopic before moving on. Once something is said you can always go back to it when you finish the idea that prompted the new topic in the first place.</p>
<p>Respect each other and do not fight for authority. Work as a team. And if you feel there is issue, clear it out after the interview. Do not lecture each other during an interview.</p>
<h4>Practice makes perfect</h4>
<p>Doing something for the first times can be difficult. Even doing it for the second time. They say it takes 10 thousand hours of doing something to become expert at it.</p>
<p>Use <a href="http://thinker.taja.sk/search/label/Research%20interviews">these tips</a> to learn more about Research interviews. Read about them on the web. Do not worry about failures, they only make you better if you learn from them.</p>
<p>I am proud to say that my mentees completed quite the amount of interviews and improved drastically. And so can anybody else if they try hard enough.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com1tag:blogger.com,1999:blog-4751317502700026249.post-8529046725941446092017-05-09T11:54:00.002+02:002017-05-09T11:54:28.163+02:00What is not Agile<p>The newest old buzzword floating around businesses, making huge impact on either success of a business or sanity of its employers – Agile. Instead of explaining what Agile is, lets show some examples of what it is not.</p>
<a name='more'></a>
<p>I encounter all of these examples of misunderstandings on regular basis. Speaking to people from other companies and reading other blogs on the internet, it is more than obvious that these problems are common.</p>
<h4>Misuse of the word</h4>
<p>People in my surrounding tend to use Agile as description of everything. Agile rooms, Agile tools, Agile talks. I am personally waiting for Agile toilets to make an appearance.</p>
<p>Even though there are tools out there created to be used in Agile software development environment, it gets rather extreme when that is the entire reason behind using them, when it gets forced on people who have no idea what to do with them.</p>
<p>For some reason management believes that it only takes a tool to "be Agile". That you do not need to change anything else, just the tool you use to track your work or distribute tasks in team.</p>
<p>Soccer newbie will not become a pro the moment he buys a pro soccer ball. It is not just about the tool. There is so much more that is needed.</p>
<p>Agile Talks are another great example. If these talks were about Agile methodologies, then maybe. But they are not. They are normal presentations formatted like TED talks. The topics can be anything from generic psychology to specific programming language. And yet they get the Agile label to make them appear more buzzword-ish, more important.</p>
<p>Not to mention that it is not just tools or presentation, it sometimes gets so out of hand that the word Agile becomes a verb or an adjective. In order to describe how this works I will demonstrate it.</p>
<h4>Misunderstanding of the principles</h4>
<p>Beside just labeling everything as Agile without understanding that the tools do not make people Agile, there is another huge issue. Sets and principles of Agile software development get completely twisted by people on management level.</p>
<p>There are reasons why Agile development has its benefits. It is taking psychology and biology of people into account. It is taking business and users into account. It is tested and it is researched.</p>
<p>There are people who mistake it with the ability to adapt to anything. They completely disregard the positives and do the precise opposite. Let me give you an example:</p>
<p>Developers having just one project can focus better on it than if they had multiple projects and needed to shift their thinking all the time. It is important to focus on one thing and get it done before moving on to something totally different. It is worse to rotate between multiple projects, leaving one just to come back moments later.</p>
<p>What managers like to do is to come and say: "Hey, lets work on this totally new project now." To objection that you already have project you need to finish, they play the "you outta be agile, you outta adapt" card. Which is total nonsense.</p>
<p>Accepting multiple projects and worsening the focus of all people involved goes against the principles of Agile development.</p>
<h4>Applying it everywhere</h4>
<p>Agile software development. It sounds good, right? Lets apply that to HR department, Finance and Accounting department and also the department filled with advocates.</p>
<p>The real example of taking it into extreme and applying Agile methodologies everywhere. Even in places where it has no purpose or benefit. But hey, you outta be agile, you outta adapt.</p>
<p>But this can truly happen, people can lose the ability to use common sense and start forcing something "new" everywhere without thinking if it is optimal or even possible.</p>
<h4>Lack of change</h4>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSQBFxEym86yw7-y6hetLVPVNr0peMHj2IaGAcshB5utUaELNZQFMY4oymxv7WjU5LDx7rVRf63smdRzCQgDsXMMu4o9OgzgqwJ5nxf34A8bdblbT4pMI_iOsXtBSM4w4Aid0E4ki_P48/s1600/change.png" class="full" />
<p>I think the biggest issue comes from the fact nobody wants to change, yet everybody wants a change. Instead of using all the positives, benefits and thought out principles people just prefer to remain the same and pretend they are better.</p>
<p>And what is easier than to just call yourself, your tools, your presentations and your toilet as Agile. It is the problem of today's age, people loath the change, even if it is for the better. So instead of taking the good from Agile and applying to the bad in their companies, they take the bad they do and transform Agile to be as bad as they already are.</p>
<p>It almost starts to feel like a cult. Priests floating in the corridors of huge open offices, preaching their ideas, teaching us prayers we are supposed to repeat. Using the word Agile to get what they want whether it actually makes sense or not.</p>
<p>Shame is that the people who preach it the most know the least about it. And the fact they put Agile everywhere helps in their own personal make-believe that they are the masters of it.</p>
<h4>It is more than just a word</h4>
<p>The set of values and principles of Agile software development are not about how you write the name of the development method, they are about how to behave, how to act, how to plan, how to work, how to coordinate and so much more.</p>
<p>If you take this huge idea filled with suggestions on how to improve your business, backed by the data showing that it works in situations it is meant for,... Well if you take this and reduce it to one word you are going to repeat over and over, and over again without ever learning what the hell it truly means, then – let me put it in language you might understand – You are not agile.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-24877533372433858952017-05-05T17:14:00.000+02:002017-05-05T17:14:32.263+02:00Minimal Viable Product<p>"You don't deliver features, you deliver solutions to problems." Very truthful quote when it comes to successful design. Since the real world is not always filled with successful environments, lets analyze potential pain points and reasons why delivering pointless features is still a common pattern.</p>
<a name='more'></a>
<p>I do not know the source of said quote but I appreciate the meaning behind it. People nowadays just create things just for the sake of creating things. They think it might be cool to have that while in reality they are just making assumptions based on their opinions and very little if any data.</p>
<p>I encountered this behaviour numerous times in my career so far. I do not believe there is ultimate solution and I do not have any, what I have is my observations and suggestions on how to fight the specific issues and situations I have noticed.</p>
<h4>MVP – Minimal Viable Product</h4>
<p>Minimal Viable Product represents the smallest set of features that are absolutely essential for the product to be useful in some manner. Any features that can be done later are done later.</p>
<p>Lets be honest, this is tricky part for majority of the people. Almost every stakeholder and stakeholder wannabe I work with wants to have everything immediately. No patience, no double guessing, no objectivity. They want it because they think it is essential. No compromises allowed.</p>
<p>It is very difficult to determine what is essential and what can be added later, even if it is really high priority. And yet the outcome of a brainstorming should be the MVP set of features that will be implemented next. So how come people do not filter it and leave everything in the development right from the start?</p>
<p>It is a must to educate people on MVP and the reason behind it, while adjusting the processes to not only allow it but incorporate it and endorse it.</p>
<h4>Presenting to managers</h4>
<p>Another group of people I deal with do not roll with MVP because of their managers. Kinda. The problem is that to have budget for something, idea of it has to be sold to the managers who hold the budget. And how better to sell an idea than to oversell it.</p>
<p>Multiple times now I was approached by stakeholders with a tool designed by them – people with no design background – stating that all the features must be there because they already presented it to managers and managers approved it. Brilliant! I presented my sketch of an alien in kindergarten to entire class, does not mean it was not horrible.</p>
<p>There are cultures and environments where for some reason people are afraid of adapting, learning, growing. Once you present an idea, that's it. The idea is perfect in your mind and no change will be made. It does not work like that. Every good design evolves. It is important to realize that.</p>
<p>For those afraid to stand up to your managers: It is as simple as this, instead of saying how bad your idea was at the beginning and that you had to redone it, take more positive approach by stating that you found even better way of doing the already good thing you were after.</p>
<p>And for those on top: Encourage your employees to adjust or even completely rework their ideas once they proved to be incorrect or lacking. The final products will be way better and you will feel the success in the long run even if it takes little longer to get there.</p>
<h4>Delivering solutions to problems</h4>
<p>Successful business build solutions to problems people have. They do not build useless features. And they all start small. But instead of treating it like weakness, they treat it like an advantage.</p>
<p>Small things can be easier updated, modified, improved. Big things are harder to change. And if you spend effort and time listening to your users and clients you will know that the changes you are making are the best ones you can. You will be building product for your users based on your users and not yourself.</p>
<p>Start small, release in small community and listen to feedback. Gather it, nourish it, learn the real problems and implement solutions to them. Grow the product and with it the community of users.</p>
<p>Do not come up with big plans that you present to managers based only on assumptions or so limited data it is basically still assumptions. Do not try to implement everything immediately.</p>
<p>You have time – every giant started small.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-37613596576633818412017-04-24T16:10:00.000+02:002017-04-24T16:10:28.837+02:00Prejudice and judging people before you meet them<p>It is easy to make first impression. It takes only couple of seconds for people to box others into groups and make uninformed decisions. It gets even worse when people unconsciously change their attitude based on these first impressions. It is hard to control because it is encoded deep in who we are and yet it can do so much harm.</p>
<a name='more'></a>
<p>I have talked about prejudice before. I have put forth research about biases. Now I would like to reopen this topic due to my personal experience in work.</p>
<h4>The CV</h4>
<p>I have received a mail from one of my colleagues containing CV of one of the candidates for an open position. CV is a personal information and is not to be shared like that, but for some reason this mail traveled to my inbox. Actually, I was not even supposed to get it, it was a mistake. The mail was meant for someone else. Someone else who also was also not supposed to receive that kind of information.</p>
<p>It was sent to the whole bunch of people. The purpose was so that they could check the CV and see who will be the newest newcomer. So they could make an opinion about the person before he even arrives. Oh, and they did.</p>
<p>They have not met him yet, but knew already they dislike him. All that based on a piece of document summarizing some previous experience. Don't get me wrong, CV is important, but is it enough to know everything about the person? And I mean everything? Enough to know you dislike him?</p>
<p>CV is one of the first layers of filtering, afterwards you have lots of interviews and tests. So why are people so hellbent on making assumptions based on minimal amount of information?</p>
<h4>Give them a shot</h4>
<p>I have noticed this problem far too often among many other employees from different companies. They all take this little piece of paper and cast an extreme judgement on the person whom it is about.</p>
<p>As an interviewer you are taught that in first couple of seconds your opinion is formed subconsciously whether you like it or not. But you are also taught to take this into consideration and overcome it. The person in front of you could be stressed out and stumble, but that does not mean she is incompetent and cannot walk. You have to give her the benefit of a doubt.</p>
<p>The same skill is lacking among people who do not do interviews. And it is a shame. Because once this new person comes to your team, even if she is the best person ever, you will be undermining her and not giving her the chance to prove herself. Its lose-lose situation for you and the person.</p>
<p>Instead, try taking different approach. It sounds simple but it is very complicating and difficult. And the approach is this: Do not judge people without proper information. Mainly if what you have is just first impression that might not even be made by meeting them.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-57993893231150109152017-04-24T14:02:00.000+02:002017-04-24T14:06:42.164+02:00A day in life – Experience over shadowing<p>Our department held day in life for the teams inside so that everyone could get to know each other. We spend some time thinking about how we want to describe our team but we could not come up with any solid description that would summarize all that we do in a way we would like to. Eventually we decided that being able to experience something gives you more than just hearing about it.</p>
<a name='more'></a>
<p>Each team was supposed to have an hour long shadowing session used to present themselves and their way of working. This sounded great but the implementation turned out to be quite worrisome for us.</p>
<h4>Let me show you</h4>
<p>All the teams prepared something informative about them. They described what they do, showed some projects, gave some examples. It worked. People spent time at each team, learned about them and what they do.</p>
<p>But this wasn't good enough for us. Although we are not a big team, we do rather unique things when it comes to our department. We do innovations. That is the simplest way of putting it. What does it mean though? What kind of innovations? And how do we do them? Everybody in here is creating something new, what makes us so special?</p>
<p>We did not want to just show what we do, we wanted to show how we do it. And not only that. We wanted to let people experience it themselves. It seemed like the best way to describe ourselves was not to tell people what we do, it was to let them tell us what we do.</p>
<h4>I will let you show me</h4>
<p>When the first wave of people came we were sitting in a circle in front of a whiteboard. We told them to sit down with us.</p>
<p>As we were all staring at the whiteboard I waited for the latecomers to arrive and as they did I started explaining a brand new project we received. I described the basic idea of it, defined the targeted audience (users) and goals we wanted to fulfill with the tool. All of these things were written on top of the whiteboard.</p>
<p>Once this was done I turned to the people and said that we are going to brainstorm ideas and features. Explaining the rules of brainstorming some people were little bit confused that we expected them to do something. But that was all part of the plan.</p>
<p>It was difficult at the beginning but eventually they got the grasp of it and started coming up with some ideas. People struggled with not criticizing their own ideas even though it was explained that no idea can be a bad one. They felt shy and afraid they might say something wrong.</p>
<p>After we had filled entire whiteboard with ideas we needed to select the essential ones – the ideas that would make it into MVP. Now came the second extreme. People were suddenly very "trigger happy" and wanted to put everything in to the tool. Took some time to convince them that having snow on the background is not really the most needed feature. Eventually we succeeded in picking just few most important features.</p>
<p>Hour passed and people were still interested as we started drawing some wireframes. Or better said – this time around, they were the one doing all the heavy lifting.</p>
<h4>Experience above all else</h4>
<p>It took almost two hours to end our hour long session as people seemed to enjoy the experience. Not only they learned what we do and how we do it, they also had the opportunity to try it out themselves.</p>
<p>We heard some good feedback about our approach and it made us more visible.</p>
<p>I have used this same approach with students during open doors. The activities were different but the notion of letting them experience it was the same. And it worked miracles. Teenagers hating the world, refusing to pay attention to anything suddenly came together and started cooperating and being interested in what they were doing.</p>
<p>I can safely say that whenever I am put into similar position, I found it that letting people experience something is always more valuable than to just tell them.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-89703576048806343132017-04-23T13:14:00.000+02:002017-04-23T13:14:08.699+02:00My UX fall – The day I lost all hope<p>Combination of stress, prejudice and brooding is evil. Being firm believer of hope and speaker for patience to deal with clients does not make me immune to reality. And the day when it hit me hard has came. I succumbed and I have lost all hope.</p>
<a name='more'></a>
<p>New year started off with big disappointment over the past years lack of success and lots of work to do to on new fronts. I was stressed due to high amount of expectations I put on myself. It was around this time when new initiation was born.</p>
<h4>Hackathon</h4>
<p>I was not the only one swarmed by unfinished projects and ideas for improvements. One of departments decided to throw a hackathon to get some closure on their dreams for brighter future. It sounded good, but the more I heard about it, the less I liked it.</p>
<p>Every bit of information screamed the same ol' story I have heard so many times the year before. The statements I read between the lines can be summed up to this list:</p>
<ul>
<li>we know what is best</li>
<li>no research is required</li>
<li>we care about users but do not want to learn anything about them or hear from them</li>
<li>as people with no technical skills, we took the liberty of creating estimates for all technical tasks</li>
<li>Minimal Viable Product (MVP) is nonsense – everything must be done immediately and to the full extend</li>
<li>we like buzzwords</li>
<li>we answer only to our managers so everything we make will please them even at the expense of users</li>
</ul>
<p>Fed up with this attitude I struggled against my conscience. I wanted to help but I did not want to help. I like being involved in innovative projects but I could not handle any more of this nonsense. I was on the edge of breaking apart. Eventually, I was not part of this initiation until later on.<p>
<h4>Changing peoples attitudes</h4>
<p>I tried to make it work but I simply was not fit for it at the time. I had no hope and no motivation. Luckily my colleague stepped in and handled the situation by:</p>
<ul>
<li>having a call with stakeholders about the correct approach</li>
<li>advocated research and kept asking question while explaining that without answers it will be difficult to proceed properly</li>
<li>repeating that the stakeholders are not the users and that they do not understand them as they should</li>
<li>going over the estimations which were totally unreal and defining the importance of MVP</li>
<li>noting that buzzwords hold very little meaning</li>
<li>rebuking the need to create solutions only to present them to managers who have nothing in common with the users</li>
</ul>
<h4>Next steps</h4>
<p>Hackathon spawned some good projects which were still suffering a little bit with the problems described above, but it was better. The teams decided to continue on their respective projects while adding more experts into the mix to deliver useful products.</p>
<p>I joined one of these projects later on and helped bring the vision to life. Even though the vision might have been distorted by the initial issues, it was too late to try to make huge difference about those. But it was not too late to show the importance of good analysis and planning.</p>
<h4>Taking a break</h4>
<p>I was happy my colleague took charge during the hackathon because it meant that the stakeholders got someone they could rely on while I could rest and get back on my feet.</p>
<p>Chilling for few days and finishing my previous work let me caught up with my plans. It proved to be the right thing to do as without it I would have suffered from burnout.</p>
<p>I recommend people taking a break. It is one of the best ways of getting something done. Burnout decreases your motivation, creativity and attention to details. It does not matter how many hours you work in such a state, you will not get anything done.</p>
<p>Sometimes it is necessary to take a step back and just relax. When you come back, it will be easier.</p>Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com2tag:blogger.com,1999:blog-4751317502700026249.post-69007573164772775222017-02-16T16:46:00.001+01:002017-04-23T13:02:54.759+02:00Research interviews – Questions and technicalities <p>Research interview can be bigger beast than people expect. Let's delve into the subject once more. How do you get the most truthful answers, what can you expect from your interviewees and what are the most common mistakes beginning interviewers make?</p>
<a name='more'></a>
<p>Research interviews can be difficult and require lots of adapting. <a href="http://thinker.taja.sk/2017/02/research-interviews-leading-discussion.html">Leading a discussion</a> is helpful but it also is not everything. There are rules to the questions asked, guidelines to follow and mistakes that can be made.</p>
<h4>Getting the truth</h4>
<p>Asking "Do you exercise?" will give you very biased answer. People tend to say yes. What are you asking though? What is the definition of exercising? Is once a week enough? How about once a month? Or is four times a week the lower limit? This question is wrong for two reasons: It is too generic and it allows biases.</p>
<p>The generic part will be addressed later. But lets look into the biases. People like to believe that they are better than they are in reality. That is simply how we are as human beings. You need to be counting with this. Therefore, lets try to ask said questions differently, for example: "How many times have you exercised this week?"</p>
<p>Asking about past gives you more precise answer than asking about future. Asking about specific and not very far past gives you even more precise answer. This is because asking about certain time interval they can remember does not require them to fill in the blanks and guess what interval you are referring to.</p>
<p>If people lie to the second version of the question, there is not much you can do about that, but at least they won't be biased and pretend they are hardworking gymnasts if the last time they went to gym was 3 weeks ago. And yes, that still counts as exercising.</p>
<h4>Interview is a puzzle</h4>
<p>You want answers to specific questions but during an interview you need to be careful about asking too generic questions. Just as it could cause bias described in previous section, you can also get very incomplete answers.</p>
<p>Example: "How was the workflow of you work this week?". Questions asking about specific past doesn't give the interviewee lots of possibilities for biased answers, or does it? Even here they can say various things. I find it better to ask questions surrounding specific problem and then connect all the answers like a puzzle.</p>
<p>"What was the biggest workflow problem you faced this week? How long did this situation lasted? Was there other similar or completely opposite situation?" These questions are lot more specific and from answers you can put together a picture of what was truly happening with the workflow that week.</p>
<p>I will also state that there are times when specific questions are not so good. Before you delve into deep discussion you first need to cover the foundations, the basics of the problem. If you start asking specific questions right away, you might miss the real issue because it simply never comes up.</p>
<p>It is completely possible that even though workflow in the example above is viewed as problematic, people might actually be experiencing way bigger issues with client communication. And solving that would have way bigger impact than solving workflow. Therefore asking only about workflow will make you blind to the reality of the situation.</p>
<p>Alternate more generic questions to get the overview of the situation and then start asking more specific questions to get to the bottom of the situation.</p>
<h4>Lets imagine</h4>
<p>Lets imagine you are in situation where... It doesn't matter what continues, question like this should raise a red flag for you. The moment you are force or even let people imagine something you are once again getting into the biased waters.</p>
<p>People are very bad at predicting future. Really bad. Its just another part of us we have to account for. The moment you are asking if they used a tool in certain situation in the future or if they would like to get certain information, you are pretty much gambling. They can answer anything and you won't really know if it would be truth if such situation ever arisen.</p>
<p>Example: When you are hiring new manager and you ask her how she would react if she needed to kick someone, her response can be different than what she would really react like in such a situation. The rush of emotion suddenly changes her view in the heat of moment. The reality and the predictions are always different.</p>
<h4>Users are not designers</h4>
<p>Design is more than just creativity. It requires mind set, skill set and some other sets. On the serious note, designing is not as easy as people consider it to be.</p>
<p>Letting people design something has two problems:</p>
<ul>
<li>They only know their side of the view. They know their problems, not the problems other people are facing.</li>
<li>They will implement solutions that help them and only them. As limited as their view is, they limit the ideas even more by making them worthwhile only for limited audience.</li>
</ul>
<p>Be careful about asking people to design something. You can ask if you deem it important or useful, but do not treat it as must have features or ideas.</p>
<h4>Blue sky question</h4>
<p>On the other hand, there is practice of allowing blue sky thinking. Therefore creating ideas not limited by current possibilities or beliefs.</p>
<p>I prefer to do this at the very end when we already discussed everything there is. I lay out a situation in which the person has infinite amount of money, possibilities and no one to limit them. I ask what is that they would do? Of course I guide the question to the topic we are talking about the whole time.</p>
<p>This might result in people trying to design solutions, but if you pay attention and read between the lines, you will notice what is bothering them. It can confirm all you learned beforehand from that person. Alternatively it can tell you what they think is bothering them, what they feel to be the problem and you can compare this to what truly seems to be the problem.</p>
<h4>Psychology is for experts</h4>
<p>Some people in UX branch of study have IT backgrounds, some have psychology backgrounds, some have artistic background, etc. Therefore there are different skills you yourself have and you can use.</p>
<p>Understanding body language can be useful. It could also be downright necessary if you want to be the biggest expert on the scene. But for the starters it is not required. Its nice to have, but it ends there for beginners.</p>
<p>If you are really not satisfied with your ability to comprehend body language, try to get someone who is little better at it. I will note here that women are in average better at reading and understanding body language than men.</p>
<h4>Taking notes</h4>
<p>Lastly, taking notes. It is difficult to listen, speak and also take notes. For that reason, it is suggested to always come in pair. One person is the main facilitator, who is leading the conversation, while the other person is taking notes and occasionally entering the discussion.</p>
<p>Having too many people there can be intimidating, so pay attention to that aspect. Also make sure that if you are not alone, you are not undermining each other with your colleagues. You need some synergy to pull this off.</p>
<h4>Most common mistakes</h4>
<p>Beginners tend to guide the interview in a direction they would like it to go. People tend to come up with some ideas for solution before they know problem and then they try to fit the problem the solution instead of the other way around. It is one of the biggest mistakes since it undermines the whole point of doing research interviews.</p>
<p>Arguing, persuading, being judgmental, etc. Also not good. You are there to listen and learn. Not to judge. Even if you do not agree with something, try to keep your cool and maintain smile or at least poker face.</p>
<p>Asking people about their ideas, their solutions. Not good since their view is limited and they may very well lack the skills necessary to be a designer.</p>
<p>Incorrect balance of generic and specific questions. There are times people come so focused on one thing, they tunnel vision. And there are times people can't get deep into the issue and leave with unsatisfactory information.</p>
<p>Forcing interviewees to imagine and asking them unclear questions. Unclear question and pretending or imagining something that has not happened or how it could happen in the future results in very imprecise answer.</p>
<p>Jumping from topic to topic. There are times you are forced to do this, but it should never be overdone otherwise it will create chaos in conversation.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-43014528059692453272017-02-15T17:55:00.000+01:002017-04-23T13:03:02.141+02:00Research interviews – Leading a discussion<p>Understanding the true problem is necessary step towards fixing it. Often you are trying to improve experience of your users to increase company revenue in case of external products or employee efficiency if internal products are in question. Let's look at one method to further this understanding - Research Interviews.</p>
<a name='more'></a>
<p>I was recently approached by a colleague to provide some advice in his quest to create the "perfect" product that would help internal process of our department. The very first point on the journey is to understand what is the problem. What is chocking the people, what are the pain points.</p>
<p>One of the ways to gain this information is to perform Research Interviews. Sit down with the potential users and talk "one on one" style. Have a discussion about their work, what they do, how the do it, how do they react in various situations, what skills they have, etc. Learn about them and the things they do. That's how you gain the necessary insight into the problems they face.</p>
<p>Of course there are other methods. For example shadowing. But for this specific project, we are putting other methods aside for now and we will focus on interviews.</p>
<h4>The beginning</h4>
<p>You meet the person who you are conducting interview with, what do you do? Polite gestures like handshakes are a good start. But what then?</p>
<p>Small talk, even though hated by introverts, is actually reliable way to quickly gain some trust from the other person. Small talk is so important part of our lives that people who do not engage in it, are often seen as rude or cold. Some question about the day so far, maybe a joke, can go long way to establishing friendly and warm atmosphere for the discussion to come.</p>
<p>Majority of the people don't know what research interview is. They might confuse it with ordinary interview, which is not that good. It is important to state what this session is about. Explain that you are not there to judge them or evaluate them, you are there to talk, to gather information about them and their work.</p>
<p>In case you want to record the session, you should ask them if its okay as otherwise it is not very polite to record them or could actually be illegal in some countries.</p>
<p>Ask if there are any questions, clear out misunderstandings or comments that can arise and when both sides are ready, begin the interview itself.</p>
<h4>Easing in</h4>
<p>It is important to remember that this is not hiring interview. This is supposed to be a discussion. You want people to open up to you and to tell you about themselves. Therefore you must let them know you are listening and that you are interested.</p>
<p>Don't start with the deep questions right off the bet. Hold your horses till later time. The first questions should be simple, very open. Ask your interviewee to introduce herself, describe what is she doing. Of course don't make her repeat what you already know. But let her start at the beginning.</p>
<p>There will be plenty of time for deep debate once you lay down the basics. Basics that will aid you tremendously. Do try to remember them as they are important.</p>
<h4>Reason for asking</h4>
<p>You will have certain draft of questions you want to ask. They might be group into specific units based on some pattern. If you want to lead a discussion you have to insert the questions into already existing dialogue.</p>
<p>This is why it is good to have those basics on the table. It is good to be able to expand on something your interviewee has already mentioned. Imagine example where you want to learn more about Project A. When the person naturally mentioned Project A, you can now use that and ask for more information. Otherwise you would need to artificially bring that topic into the discussion.</p>
<p>I am not saying that it is wrong to change subjects. There are some restrictions to it though. Plus, naturally flowing discussion is simply better. It shows that you are listening, that you pay attention and actually care.</p>
<h4>Changing subjects</h4>
<p>There will be certain subjects you will be covering during the interview. As I already mentioned it is good to expand upon already mentioned subjects. But there is other side of the coin here.</p>
<p>Let's say you want to cover subject A, B and C. You are talking about subject A and your interviewee mentions subject B. If you are done with the old subject A, you can take this opportunity for fluid shift towards subject B. But if you are not satisfied yet, don't change the subject.</p>
<p>Going back and forth between two subjects is not good. It makes a mess and feels as very chaotic experience. If you are not ready to change subject, stay with the old one. And when you are ready, then you can use the fact that subject B was already mentioned and ask more about it.</p>
<p>Another thing is not be afraid of changing order of subjects. If the situation presents you with opportunity to move from A to C, take it. Fluid conversation is important.</p>
<p>Just keep in mind to never have multiple active subjects. Stick to one. It usually doesn't matter in which order you talk about them, unless they are dependent on each other in some manner.</p>
<p>Same goes for questions. Transition according to what was already said. Don't make unnecessary jumps back and forth.</p>
<h4>Lead a discussion</h4>
<p>Making your interviewees understand why they are present and making them feel helpful will aid you. Prove to them you are interested by listening and leading a discussion, not an interrogation.</p>
<p>In some occasions you can joke, in some you have to be serious. It is up to you to judge that. Soft skills are required for this activity. Making people as open as possibly while not overstaying your welcome is a fine balance you have to find on your own during every single session.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-4728645417287575652016-12-31T11:24:00.000+01:002016-12-31T18:22:24.931+01:00Things we take for granted<p>Have you ever thought about people who had enough misfortune in their life and never had the chance to learn something that comes so natural to the rest of us like shopping for clothes or basic social skills? How about people who have never found their role models who would motivate them into following their dreams or even having any dreams?</p>
<a name='more'></a>
<p>There are certain skills that are known by so many people, they are rarely seen as something that needs to be learned. Being able to communicate with others, beeing able to go shop for clothes. These seem completely natural but the true deal breaker is that there are people who did not have the opportunity in their life to learn these.</p>
<p>You most likely went to shop with your parents when you were a kid. You most likely hated it as majority of kids, but it taught you something. It prepared you for the experience. Did you know that there are people who simply never had this preparation in their life?</p>
<p>How about people from very bad families who lack social skills in their adult lives? These could be the best engineers in the world but nobody is going to employ them because they cannot even handle an interview or writing a CV.</p>
<p>How about people who have never admired anybody as a role model, never had any goals for the future? It is possible to just live your life like that. But at some point you will be left behind your peers who have visions and dreams, peers who felt the light of having someone to look up to.</p>
<h4>Teachers play big role</h4>
<p>I believe that teachers and family can both fill some of the same holes. For example role models can be both family members and teachers from your schools. There can be also other role models of course, but these are the ones we can interact with. These can be our mentors.</p>
<p>Social interaction can also be taught by both groups. Either our family teaches us how to communicate or we learn this in school by not only learning from teachers but by also practicing on class mates without us even realizing it. Do you remember some mistakes you made as a child when talking to others that you do not want to repeat? You learned by practicing.</p>
<p>Big part of social interaction is also our ethics and emotional maturity. Words like empathy, assertiveness, prosocial behaviour, etc. They govern how people perceive the world. Is the one person positioned in the middle of the universe or is she part of the universe, sharing it with other people.</p>
<p>Many people confuse assertive behaviour with being able to manage people, tell them what to do without them refusing - being able to boss people around. Assertiveness can also be perceived as ability to insult people without them feeling insulted.</p>
<p>Neither of those two definitions is correct. Assertiveness is not about ego or aggressiveness. Assertive behaviour is about confidence and calm head. When you see somebody else bossing you around you do not scream at them, you do not show your superiority. You simply call it out and calmly state you do not like it.</p>
<p>Imagine you are in a shop and you ask for a banana. There is healthy banana and rotten banana on the shelf. The person behind the counter gives you rotten banana instead of healthy one. What do you do? You can yell, you can try to insult the person, you can just be silent and take the banana. Or you can be assertive - simply and calmly state that there is healthy banana which you would prefer more.</p>
<p>I was taught that prosocial behaviour is about helping others without the need of being rewarded or expecting a reward. It is very rare behaviour in my opinion. Many people expect something in return. Even if not now, they expect something later. "Remember the time when I helped you..."</p>
<h4>My experience</h4>
<p>I learned a great deal from teachers. There were two that stood out the most when it came to soft skills and ethics. I did not realized it at the time, but these two teachers prepared me for life in a way nobody else managed to.</p>
<p>Not only they provided the most of my basis for ethics, they also inspired me in a certain way. They taught me about interacting with others, they gave me something to think.</p>
<p>One of them started every lesson by naming 10 "rules of ethics". These rules were basically just phrases from which I have already mentioned three. But these phrases are important part of ones personality and attitude towards others. And by realizing all of them and their meanings, he gave me the ability to decide who I want to be and also think critically about my existing behaviour.</p>
<p>The other teacher started every lesson by asking what is the most famous quote from Socrates. He gave the best grade to the first person who said the quote every single lesson. I was the only one paying attention so I passed the subject without any issues.</p>
<p>I did not understand the importance of this whole deal with Socrates until I realized that people learn new things only when they are willing to admit that they are wrong. Without this willingness, nobody could learn as everybody would be defending already made up mind.</p>
<p>This gave me the ability to question the world around me and to question myself. It gave me thirst for knowledge and truth and decreased the need to be right. I would suddenly enjoy talking to smarter people with different opinions cause they could teach me new ideas as opposed to those who believed in the same as I.</p>
<p>These teachers were a mystery to me when I was studying. I did not understand them at the time. Now I believe I get what were trying to accomplish. And I believe they succeeded for I would be very different person would they not teach me.</p>
<h4>It is our turn</h4>
<p>Now that we are the adults, the one with power to shape futures of others, it is our turn to teach and share our knowledge. After all, generation sitting behind school desks now will lead the world when we get old. They will be the one creating innovation and technology we use. They will be the one sitting in parliament deciding about laws we will have to obey and live by.</p>
<p>We have to realize that not everybody has the skills that people consider to be natural and we have to realize that everybody can still learn them. Those without inspiration and motivation to accomplishing goals or even making them can still gain both.</p>
<p>Some friends and I had this notion about year and a half ago and we decided to do something about it. We decided to start visiting secondary schools (high schools) and talking to students. Trying to give them some tips into live, teach them about possibilities and opportunities.</p>
<p>Instead of forcing them into decisions we just lay the options on the table and give them as much information as possible. Let them decide what they wnat to do and help and support them in whichever decision they make.</p>
<p>We try to provide them the chance to come with us for a day or couple of daya, and see how the world will look for them in few years whether they decide to continue studying on university or join the workforce. Hopefully we inspire them to create some goals and follow them.</p>
<h4>Gather to make a difference</h4>
<p>We eventually went to form Nation of Technical Excellance, or NTE in short. And even though it is an university nation (fraternity) it is built on community, unity and helping each other. One of my favourite activities is still helping others, teaching, presenting and organising workshops for students.</p>
<p>We are not as active as I would like, but I have high hopes that will change with the higher count of members.</p>
<p>Either way I urge you to think about this and try to help others who might struggle. Whether it is by teaching skills that are taken for granted those that lack them, discussing possibilities in life, being the role model and source of inspiration or anything else. Help the future of other people. Be prosocial x)</p>
<p>And if you feel like it, create your own flag under which you are going to rally to make a difference in this world, just like we did.</p>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFt7GeAU-fHXG_phBQI3tcNUUg3sHhsYi5GPc2TNJPUp88u9cN42mcjJP6ADS3T8t5qFYEcQspjChIMl0RfLMxa9kq2us6ttvWCMY6nZAb2W3NscSxxPDYWggO4GklgNYSineYkU3VNMo/s1600/V%25C3%25BDkres1-Model-1.png" class="full" />
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-12082927610342514742016-12-27T12:55:00.000+01:002016-12-27T12:55:15.024+01:00It's all your fault<p>In today's world, people are mainly interested in being right. In their faith, in their beliefs, in their views, in their opinions. And also in workplace. Imagine you have two people defending opposing views, not being able to accept any form of defeat. Just locked in infinite battle of who is right, never discovering the real truth.</p>
<a name='more'></a>
<p>Not listening makes it difficult to learn new things. Clients who do not listen are pain in the arse, managers who do not listen are pain in the arse. Pretty much anybody who does not listen is pain in the arse. However, how can you be sure you are the one who actually listens?</p>
<h4>Asked for a favor</h4>
<p>I was realy busy with my usual work when a friend of mine asked me to help him with something. It was not that big so I thought I could find some time for it. He started describing the problem via real time chat and we were slowly getting to the point of the task.</p>
<p>After a while I had to go offline. Since it was Friday evening we agreed on continuing discussion on Monday. I continued working on my own stuff during weekend (workaholism, yay!).</p>
<p>It was on Sunday when I suddenly had enough time to look into my friends issue. It would be helpful for him if I did it as fast as possible so I worked on it for a little while and sacrificed my Sunday evening to come up with solution.</p>
<p>Monday came and my friend was not satisfied. He started giving me more information about the tool which was contradicting the solution I came up with. I did not know why he decided to give me this information now and not before. He was like all the clients I dislike so much, withholding information until it is too late and you have to rework everything.</p>
<p>So I called him out on it as we were discussing the solution in his team. He did not provide all the information, he did not like some things on my solution so I asked his team why he does not like it. They were actually thrilled with my solution so he did not have much choice in the matter but to accept it.</p>
<h4>Asking for a favor</h4>
<p>Working on multiple projects at a time makes it extremely difficult to get anything done. I had a friend who asked me a for help once in a while so I decided it was my turn to ask for a favor.</p>
<p>I knew she was busy as hell, so I approached her carefully. I did not want to just unload all of the problems on her so I decided to have a chat with her instead of writing an email with tens of pages of proper description.</p>
<p>I started describing the problem to her and she said she can help me later on but has to go do something else now. So I agreed we will talk later.</p>
<p>I continued working on my own stuff even during weekend (workaholism, yay!) when I received a mail from her. She had apparently found some time to solve my problem and sent me her solution via mail. The problem was, this happened before I was able to explain the entire problem to her.</p>
<p>We agreed on another day of discussion and she proceeded to ignore this and just made her solution. And it was incomplete. So I gave her more information the day we agreed upon beforehand but her solution was already made so she would have to redo it.</p>
<p>She was not happy about it so she came to me and my team and started blaming me for not giving her all the information. For behaving like our clients. She got so defensive she did not even listen when I said I was not sure about some things that she just sent my team after me.</p>
<p>Calling me out in middle of my team for not being able to give proper information about problem and not liking the solution she provided. She pretty much put my team against me so there was little I could do to change things. Things that needed to be changed and still need to to this day.</p>
<h4>Where lies the fault?</h4>
<p>These two stories I just described are actually one. One story but from two different points of view. My friends point of view who was helping me and mine point of view as I wanted my friends help.</p>
<p>We both made some mistakes there. And we both have seen our truth in the whole matter. The question is, who was right?</p>
<p>I would say that no one was right. I should have described the entire problem to her via email as soon as possible and not wait for more discussion. If the mail would provide unclear description, my friend would see it and ask me how it truly is. While this way she did not see any issues because she was lacking the information altogether.</p>
<p>My friend could have actually waited for me to provide all the information as we agreed upon. It is awesome she decided to help me and even started working on the problem sooner than needed, but it caused a major issue. She lacked the information need to solve the real problem.</p>
<p>And even more painful part was that instead of talking to me about it, she started this discussion in my whole team. Dismantling me in front of my teammates and destroying the respect I gained from them.</p>
<p>It suddenly became way worse than just misunderstanding with the original problem. Now my team was involved and I was supposedly the bad guy who could not do anything properly. Even though not all the blame should fall to me.</p>
<h4>Anger spawns anger</h4>
<p>I was facing a decision. I could start blaming my friend and defending myself or I could let it slide for now. I decided to calm the situation down instead of starting an epic battle.</p>
<p>I was counting that the respect I had within my team would not be totally lost by this event. I also decided not to cause flame. I made some mistakes there. And I can learn from that.</p>
<p>My friend tried to help me, she tried to help me immediately as it became possible. And she did create a solution for me. But there were things that simply went wrong.</p>
<p>Instead of having a discussion about it, the entire action was moved to hurt me as much as possible. Undermine me. A turn of events both of us could have prevented. We have both failed in our own way.</p>
<h4>Conclusion</h4>
<p>Everybody makes mistakes. They say that the road to hell is paved with good intentions.</p>
<p>Do not ever think you are unable to be wrong. Do not ever think that good intentions can have only good outcomes. Do not ever start an argument based on emotions. And do not add more people into problem you have with one person. That should be settled between four eyes.</p>
<p>You thinking that you are right does not make you necessarily right. Realize your mistakes, learn from them. Become a better person, a better colleague, a better friend.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-71845609372805772442016-12-24T13:11:00.001+01:002017-04-22T22:33:56.118+02:00Art is not design<p>I feel like many people view art and design as the same thing or blur the differences to make them feel more of the same. Meanwhile those two things are quite different in its nature. Art plays a role in design. Art as whole is not design though. There is difference there. Art is an expression of the artist while design is an expression of the users.</p>
<a name='more'></a>
<p>This post was inspired by <a href="//austinknight.com/design-art-resources/">Austin Knights speech</a> on UX meetup in Budapest.</p>
<h4>Art</h4>
<p>Art is an expression of the artist. It encapsulates the current emotion of the artist making it. The ups and downs of her life, the struggles and the victories.</p>
<p>Art is supposed to be original in some way, it is meant to invoke emotions in you, make you think. When you hear it or see it, you should be able to understand the artist behind it. See the world as she does. This can open your eyes to new possibilities, broaden your horizons.</p>
<p>Art is an end result. There is no other purpose to its existence as its existence. The point is to enjoy the art itself, to see the meaning in it.</p>
<p>It is independent. You can take a framed picture off the wall and you will still have a painted picture which you can fully appreciate.</p>
<h4>Design</h4>
<p>Design is an expression of the users. Designing for colour blind people will require the designer to adapt the design. Designing for people in wheelchair will once again alter the design to accommodate their needs.</p>
<p>Design is supposed to be understood right away. There are standards, conventions and guidelines based on how people work and what they are used to.</p>
<p>Design is a means to an end result. It has purpose tied to something else. There is some meaning behind it other than just itself.</p>
<p>Design is depended. If you take a handle from the door it becomes useless. The purpose of the handle is to open and close doors. If it is no longer attached to the door then it has no purpose.</p>
<h4>Art is part of design</h4>
<p>Design includes art and engineering. Engineering provides a function while art provides the aesthetic. Good design has both of these. And users love good design.</p>
<p>Design with function but without aesthetic can still work. It will not be special, kind of average, but it can still work. Design without function usually does not work at all. Beautiful handle that does not open the door will hardly be popular among people who use doors – users.</p>
<p>Both art and engineering is what makes design memorable. Interface that looks gorgeous and appears to be reading your mind, calculating all the solutions to your problems without your need to bother with them, that is the future.</p>
<h4>Design is objective</h4>
<p>Since design is about the users it is also important to understand the users. That is something designers are tasked with. The more you understand the users, the more potential your design has. But how can you full understand someone else? Well you kind of can't.</p>
<p>We are all living our unique lives, with our own unique memories. Our view on world is based on our previous experiences. Therefore you can never truly say: "I know what is better for the users."</p>
<p>Design requires objective thinking, evidence, research. I have been talking a lot about research and the need for it. Without having the input from the users you cannot create design, you create art. Subjective opinions should not be sufficient arguments. Design is not about what you think, it is about what all the users think.</p>
<p>You should never base your design ideas on what you like or what you prefer. Do not create arguments without any objective facts behind them. Be objective. Learn about others and provide the facts backed up by research. Facts that you can use in later stages of the development when people come back and ask: "Why was this done like that?"</p>
<h4>Designer with ego is no designer</h4>
<p>Great design is about the fit for users. Due to the difficulty with this task, you should never get insulted if somebody raises an issue. Criticism is not there to insult you, it is there to improve the design.</p>
<p>Every time you get a notice about possible obstacle, it is up to you to decide if you get subjective and insulted or if you look at it objectively and research the obstacle to see whether the obstacle is truly there.</p>
<p>Sometimes your research can tell you everything is okay and it was just false alarm, other times you will learn that there is something that can be improved. And you will have the possibility to improve it. Possibility you would not have if you just threw your ego at the problem getting angry at the messenger.</p>
<p>My favourite motto for designing is Socrates' quote: "I know that I know nothing." Don't get angry with people criticising you. Embrace it, learn from it. If they want to help, you listen to them. And if they just want to piss you off, well you will use their own knowledge against them by actually listening.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0tag:blogger.com,1999:blog-4751317502700026249.post-89671611485965741342016-12-23T14:55:00.000+01:002016-12-23T15:06:23.440+01:00I want it to be good, cheap and fast
<p>Negotiating with clients is topic of its own. Most likely there are whole books written on that subject. And even though there are multiple levels of understanding client perspective and discussing it, there is one I want to discuss today. The triangle of quality, speed and price.</p>
<a name='more'></a>
<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_SRCzJC3NN3vdHg4sCCYvFLhhhCZsbl4FrLz1l-S2KOmE4_MyVbGY_Kiti40zjhyphenhyphenVeNfDzoEtfzJd3HDwT2bsLWhctWy1vRLKsA3gMORPMq2Iy2YnB_O2zN5AbA7VoDWw1Xy8_721rAU/s1600/triangle_quality-speed-price_bg.png" class="full" />
<p>Imagine you can drag the circle in the middle of the triangle to any direction. You can remain in the middle and have balance of product that is not very expensive, not very fast and not very good. Doesn't sound like the most appealing choice.</p>
<p>It is best to try to reach two properties. This of course means that the last one on the very opposite will be neglected.</p>
<h4>Good and cheap</h4>
<p>You can provide extensive quality for quite reasonable price. The downside is, it will take time. Lots of time.</p>
<p>Doing the market and user research, performing series of brainstorming, sketching the possibilities, decided on the optimal technology, developing the product, testing the product, etc. This all provides quality as much as it increases time it takes.</p>
<p>End result will be great, it won't be expensive. It just takes quite some time to arrive to it. After all, quality does not grow on trees.</p>
<h4>Cheap and fast</h4>
<p>Little bit of opposite is making cheap product very fast. You can skip the research, brainstorming, sketching, wireframing, you can quickly code something and glue it with duct tape. But it will not provide quality for you users nor you and the thought of redeveloping it will make all developers scream in fear.</p>
<p>You will have something. You will have it fast and you will not pay much for it. But that something might be rather useless to you in the long run.</p>
<h4>Fast and good</h4>
<p>This is the option picked by clients who have infinite pockets, not so good planning but understanding of quality translating to reputation and satisfaction which potentially also translates to revenue.</p>
<p>You can perform all the necessary preparation and development in time as long as you employ more people to do it. Those people will work overtimes, shift priority from other projects. More teams working together to provide quality in limited time is expensive though.</p>
<p>This option gives you very good product in short time. For this though, you need to have some serious money.</p>
<h4>Good, fast and cheap</h4>
<p>This is the impossible option majority of inexperienced clients want. For some this is because of lack of understanding. But there is no magic here. It is very simple. You cannot build entire house without any mistakes in a single day with only one worker.</p>
<p>You have to decide whether you want to have:</p>
<ul>
<li>house that will last apocalypse while being cheap but it will take years to build,</li>
<li>house that is built fast and cheap but will fall apart next winter,</li>
<li>house that will survive everything while being build in a month, but you gonna need some serious manpower and money to pay it.</li>
</ul>
<h4>Mongolian clusterfuck</h4>
<p>Mongolian clusterfuck is a notion that if it takes 1 woman 9 months of pregnancy to have a child, if you get 9 women pregnant, it will take only 1 month to have a child.</p>
<p>It is important to mention that even if you pick an option with speed in it, it will still take some amount of time. Even if you throw money and manpower at the problem, it will take time. Some problems cannot be divided into lesser problems. Some problems cannot be divided among people. Some problems just take time to solve.</p>
<h4>Pick two</h4>
<p>Educate your clients about this. Do not let them ask you for miracles. And if you see the wrong attitude inside your company, if you see people in your midst that do not understand this, educate them as well. Because misunderstanding or ignoring of this very basic concept can create tons of stress, unwanted problems and avoidable delays.</p>
Tomáš "Taja" Brzahttp://www.blogger.com/profile/09032150461747602711noreply@blogger.com0