Food for thought
Articles to get you thinking. New ideas and models that challenge the norm.

Second-Order Effect in Prod...

In the early 20th century, the French colonial government in Hanoi declared war on the exploding rat population by placing bounties on these little creatures. All people had to do was to submit the tails of the rats they had killed to claim their reward. Within days, wave after wave of eager civilians submitted rat tails in droves. While the officials were excited by this development, there were a few twists in the story. Rats were rampant in early 20th century Hanoi, posing a significant health risk to the population. Strange sightings of tail-less rats were reported in the city, and people soon realised that it was the work of unscrupulous bounty-seekers. To add fuel to the fire, enterprising people began to breed rats for their tails in illegal farms, seeking to enhance their livelihood via the lucrative trade of rat-hunting. Known as the Great Hanoi Rat Hunt, this case study is a classic example of the Cobra Effect phenomenon, whereby an unintended (and disastrous) consequence arises from a well-meaning solution. More importantly, we are going to talk about the Second Order Effect, a concept that informs everything we know about the Cobra Effect. So, What Is The Second Order Effect? Second Order Effect in a nutshell. Second Order Effect refers to the idea that every action has a consequence, and each consequence has a subsequent consequence. In other words, this means that a single decision can initiate a series of cause-and-effects, something which we might not have knowledge or control of. Therefore, it can be very difficult for us to predict possible implications of the original decision (unless we are somehow blessed with an all-seeing crystal ball). As product design and strategy practitioners, we might not necessarily be paying attention to the Second Order Effect when we make certain decisions. This is because we are oblivious to the subsequent consequences (2nd order and thereafter), beyond the desired outcome (1st order) we want to achieve. How Does The Second Order Effect Affect Us? Similar to the concept of duality, there are benevolent Second Order Effects and malevolent Second Order Effects. Needless to say, benevolent (and by default, beneficial) Second Order Effects are always welcomed, but we need to be mindful and understand that malevolent Second Order Effects can turn into nasty Cobra Effects if left unchecked. How the Great Hanoi Rat Hunt transpired. Note how the malevolent 2nd and 3rd Order Effects mutated into Cobra Effect (red background circle). To provide you with another example of a malevolent Second Order Effect, let’s imagine if we were tasked to design a resume optimiser for a job portal. With this feature, we definitely hope that our job seekers will get a higher chance of interviews from employers (1st order). However, unforeseen possibilities might exist, such as unwitting applicants using the optimiser to create a factually incorrect resume (2nd order), or employers distrusting the job portal due to the massive number of applicants with previously submitted resumes (3rd order). How it might go wrong for a resume optimiser in a job portal. So, How Can We Predict The Second Order Effect? Unfortunately, there is no easy way to predict the Second Order Effect. My favourite method is to employ laddering questions during user research sessions. You might have heard of the laddering approach via the popular “5 Whys and 5 Hows” technique, but our aim here is not to focus on the “Whys” (the root cause of an issue), but rather on how the “Hows” of a specific goal are achieved. Going back to the example of the resume optimiser, the following hypothetical “Hows” questions illustrate how we can identify potential red flags from users: ___________________________________________________________________ Researcher: “How do you think the resume optimiser can help you get a job interview?” User: “I think this feature will allow me to refine my resume to a point that I will stand out more among other applicants.” Researcher: “Can you elaborate how?” User: “Probably the new keywords recommended by the optimiser will showcase my professional ability better. I might be even inspired to add in new keywords which might be related.” Researcher: Can you tell me how would you think of new keywords? User: “I’ve done a basic course on Microsoft Excel a couple of years ago. Since the resume optimiser recommended me to add Microsoft Word as a keyword, I think I can add Microsoft Excel to my resume…” ___________________________________________________________________ While we can see that the resume optimiser is fulfilling its original purpose of helping the user (1st order), there exists a worrying prospect that the same user might add in information that is not reflective of his true ability (2nd order). Imagine what can possibly happen if the employer interviews our user and discovers his “actual” Microsoft Excel skills… So, How Can We Solve The Second Order Effect? The Second Order Effect is multifactorial by nature. Most of the time, it could be the combination of many things, such as product eco-system, business requirements, or even human nature (in the case of the Great Hanoi Rat Hunt). It only takes a well-meaning decision to start an unknown firestorm. My advice is to stay calm and think deeper. What we have basically done is to uncover another problem statement which can be solved via good design methodologies. Knowing when and where to anticipate Second Order Effects is important to Systemic Design, a concept that is increasingly gaining traction. Conclusion As product design and strategy practitioners, the last thing we want in the world is to have our products misused in the worst possible manner. While answering our users’ needs is important, we should always be mindful of the Second Order effect and the potential implications it might bring. Let’s think deeper, always!

Tracing My Journey T...

5 years ago, I started out as a web designer. I earned a living working with Photoshop and communicating using terminology like Mastheads, Image Thumbnails, Breadcrumbs, and Carousels. Life was simple. Fast forward to the present, I have inadvertently crept into the UX industry. Along the way, I have learned processes, methodologies, and tools that UX designers used. Terminologies like double diamond, affinity clustering, and “how might we” statements are familiar concepts to me. But as this article from https://trends.uxdesign.cc/ highlights, designers are at risk of becoming too obsessed with methods, and neglecting the need to empathise and design responsibly for the good of our users. Frankly speaking, my understanding of responsible or ethical design is rather superficial. It was only on a recent project that I started to reflect and reassess my attitude and approach towards my work. Even though our processes and methods were thorough, I found myself encumbered with a product redesign that failed its users dramatically. I was working on a major release of a newly revamped mobile application and the public response was filled with nothing but hostility. Excerpts from actual user feedback: User-unfriendly. Full of trick to make you loose your money. No respect for the user. Because of that, I lost $10 from my balance. Please explain why you deduct money for no reason. Is this how you make money by hiding all charges details from your users? What Went Wrong? It was only by going through feedback and connecting with users that I learned about their pains and frustrations, and this revealed an alarming consensus: Users felt deceived by the product. Many experienced loss of money and in short, the design caused them more harm than good. Why Did Users Feel Deceived? We forced the design update on users This made it difficult for them to access features they used on a regular basis. By pressuring them to conform to the redesign, we caused a mental model discordance which resulted in major backlash. Ouch. We hid essential information which were instrumental in decision making Even though the intention of the design was good, the manifestation of this misinformation eventually helped drive short-term business revenue. Unfortunately, this was achieved at the expense of users’ trust and well-being. Start By Changing The Way I Worked Trust takes years to build, seconds to break, and forever to repair. We are operating in an economy rooted in trust and reputation (ask yourself, would you rather book a hotel with less than 3 reviews or one with more than 10?). As a designer, I needed to understand the importance of building and maintaining this relationship if I wanted to create experiences that would leave a positive impact on people and the world. So how can I change the way I work? Quit being lazy and stop parking information in the fine print or terms and conditions Remember the last time a request from the client came for new content/clauses to be added just when you thought your design was pixel perfect? Guilty as charged — I have been fond of prioritising the integrity of my design and parking these information in the footer as an afterthought. The irony is that this ends up affecting the integrity of the user experience and reflects badly on the designer. Never neglect the users’ context of use I was accustomed to using use cases and edge cases to anticipate design issues that I frequently overlooked the context of use. To save time on design, I had crafted solutions with the assumption that users have access to the same things I do. And this is dangerous. In the case of my project, assuming users had access to wifi/mobile data caused considerable amounts of unexpected monetary loss. Never procrastinate issues, constantly evaluate decisions When facing tight timelines, it is easy to leave issues until after product launch to fix. While I have to learn to prioritise, it is also equally important to constantly evaluate the impact of my design by using worst-case scenarios and asking myself: Will this improve the experience for my users? Am I making it worse for others? Will it upset me if this happened to me? When a product is launched, features tend to stay untouched for a longer period than anticipated and improvements or iterations may get pushed back. Would I want users to experience more negative repercussions for a longer time than intended? With the prevalence of design and technology in our everyday lives, the potential harm they can cause is extensive. The existence of dishonest and deceptive designs are a poignant example of how little designers and businesses care about users. As a designer who still hopes to make a little impact on our world, I choose to care and this reason is good enough for me to start now.

Happy Chemicals, Hap...

Can chemicals play a role in our workplace? If we were to pose this question to the employees of a bank, or maybe even a tech company, their response would probably be: NO! To some extent, this answer is correct as we don’t see any test-tubes being used in our office. Unknowing to most, a few chemicals do in fact, play a vital role in every workplace. This is not quite evident as these chemical changes happen in our bodies rather than in a laboratory. Let me introduce you to our “happy” chemicals: Oxytocin: More commonly known as the love hormone or the cuddle hormone. This chemical helps you build trust and form strong relationships. It is not very difficult to get this common chemical flowing within us. You can significantly improve the Oxytocin levels in your team by replacing distant ‘hello’ waves with handshakes, and further improve it by replacing greetings with hugs (Ensure the hug is in consent with the other person or else you may be reported to the HR team for inappropriate behaviour. Also, you don’t want to be known as the creepy hug guy in the team). When a team is committing to a mission, provide them with an environment and encourage them to put their hands together at the end. This helps with the circulation of Oxytocin. Oxytocin is very selfless in nature, so you can stimulate the flow of this chemical by praising people in front of someone else, or by simply taking the time to ask “How are you?” Serotonin: This particular chemical gets triggered when we feel important or significant. We can increase the flow of this chemical just by sharing a meal with a team member. This chemical starts to flow when we remember what we have achieved in our past, so it is a good idea to reflect on our team’s accomplishments every now and then to receive a healthy supply of this chemical (which to me is an unbelievable deal). The deficiency of Serotonin may result in depression. Endorphins: Endorphins flow in order to produce relief from pain or to produce a feeling of well-being, which in turn, also reduces anxiety. This is a common occurrence with runners - they receive a burst of this chemical and will feel happy after an exhaustive run. As tempting as it might be, we simply can’t ask people to run around their workplace every time they feel stressed. Instead of running, we can create and promote an environment that generates happiness through laughter. This includes watching something fun together, encouraging people to share funny stories, messages and emails with each other, listening to a great song together, or going for a short walk out in the sun. We can also help them co-create and align themselves with the purpose behind their work, and revisit it time and time again. Lastly, we can change the format of meetings so that they can become more engaging and eventful instead of dull and monotonous, and organise charity initiatives such as blood or book donation drives. All of these activities help to boost the flow of endorphins within us and make us feel happy, especially during stressful times. Dopamine: Dopamine is closely associated with inspiration and recognition. This chemical helps us move towards our goals, and gives us a sense of happiness and satisfaction while achieving them. Since this is the chemical that helps us take action towards our goals, the onus is on us not to set very long term goals for ourselves. If we create goals that span over a very long time, we may run into dopamine deficiency. A recommended practice is to break down your bigger goal into smaller goals and celebrate when you successfully achieve something. This ensures the continuous flow of dopamine in your team. In my experience, I have seen amazing positive changes in team dynamics just by replacing distant waves to high-fives, taking coffee breaks with the whole team to discuss non-work stuff, and going for lunches or dinners together as a team at least once a week. Teams gradually improve on their awesomeness scale when these chemicals are in action. As time goes by, they become more accountable, reliable, trusting, proud, transparent, and fun to work with. Additionally, the improved trust levels result in improved understanding and amazing collaboration. So what’s your team’s daily dose of happiness?

If Everyone Is A Des...

Just like many practitioners, you will have probably found yourself mumbling under your breath at some point, “everyone thinks they’re a designer [nowadays].” If you haven’t, a quick Google search might help contextualise what I’m trying to say. The frustration stems from having to work alongside individuals who have little first-hand experience in the discipline, but have much to say about the direction of your design work. In more extreme cases, they’d also have hardly any empathy for your expertise and effort. It’s easy for them to feel that way, especially when the project’s success hinges on making the “right (subjective) call”. It occurs when the outcome depends on a decision that draws on “good taste” — whether the decision was made consciously, based on experience, or as an upshot of luck. Come to think of it, we’re not alone. It’s a bit like cooking… The barrier to entry is low. It’s fair to assume every household should be capable of doing it (cook). In fact, some people who do not do it as a profession, can actually produce very good meals. So then, why do we need chefs? Why do restaurants continue to exist? It is encouraging they still do. While convenience may be a part of the reason, I’d argue that we find delight in and appreciate the unique expertise they bring. It’s rather an aspect of selection than just a dash of salt and pepper. As a customer, this happens when you pick the dish you fancy, along with the recommended drink pairing. Regardless, this act is but just the tip of the ice berg. We often do not recognise the unseen depth of labour, technique, and knowledge. This is where respect resides. As a designer, it’s best to accept that this will always be a sentiment people will hold. It won’t go away. But, let your practice and experience build such that when the time comes, your counterparts would feel, “I’m glad to have you around. There’s no way I could have designed something like that.” Ideally, you’d be filing that void with both craft and artfulness (creativity). On Craft And Intuition This concerns the old-school appreciation for repetitive practice. You’ll know of this as the “again” and “again”. In the classic atelier, assuming it were a 4 year course of study, you’d only be touching colour beyond the third. The first two would be exclusively focused on mark-making in black and white. It’s formulated to enforce dedicated focus in honing those fewer crucial characteristics to perfection, before introducing more complex elements. The well-cited “it takes about 10,000 hours before to become decently good at anything” rule by Gladwell that comes to mind. I never had that privilege to be schooled in this way. Yet, I’m quite conscious of how our beloved design field has become a victim to a lack of appreciation as of late. Don’t get me wrong: the point here is about how genuine practice builds that experience; nothing about the necessity of a formal design education. The product of this great effort is the development of sensitivities and intuition. Now, to put this under the fire: Given the rise of data-driven and evidence-based decision-making, the trending dominant prescription in methodology requires validation or testing of some kind. Without which, in the affairs of the current market, we cannot possibly prove that we’re doing design in any marketable form. What then for us? Adapt like how manufacturing did with the rise of machinery? Adapt like how every knowledge worker will have to with the rise of acutely algorithmised processes (AI)? On Artfulness And Individuality Sensitivities and intuition will always matter. Figures and research will play their part in informing what they should. But like many domains in this world, it’s the careful balance and play between the “art and science” where we reap the best results. Practically speaking, it’s impossible to “go out and verify with your users” on every single item in your battery of features. It’s not wise, it’s wastefully silly. Experienced judgement helps eliminate plenty of unnecessary assumptions — it’s the right type of educated guess that you want. Lastly, with regards to best practice versus “ingenuity”, there’s a little analogy I often like to draw on. Give a bit of thought to the “spirit” of design which best describes what is needed: in the vein of McDonald’s or that of a Michelin-starred restaurant? You could also say that they both deliver “high quality food with great success”. One staple, quick, and impeccably standardised. The other, distinct, esoteric, and not for every tongue. There is room for both. Pick what represents you best and go with it. Design has always been around. And it’ll always continue to be.

Why Organisations Mu...

To ensure their clients get the best experience, building a design-driven culture is essential for every organisation that wants to go beyond just selling their products. At present, many firms that are interested in improving the customer’s experience, building brand loyalty, and remaining competitive have made design a core part of their business. Design is a change tool that is capable of transforming how organisations carry out their activities and build their brands. It helps to bring order and coherence to a seemingly complex world through empathy and user research. “It helps to bring order and coherence to a seemingly complex world through empathy and user research.” Design is not driven by technology, but rather by the needs and urgency to create an organisation that can accommodate empathy, diversity, security, and equality. Design also involves building a constructive feedback channel that allows design decisions to hinge on business objectives and goals rather than personal preferences. Building a design-driven culture starts with placing customers at the centre of the problem-solving equation. Design companies do not only strive to understand what customers want, but they also research and know why they want it. “In most cases, customers even place more importance on the experience they get while purchasing a product than how the product performs.” This is because it is difficult to separate the experience a customer has when buying a product from the actual product performance. In most cases, customers even place more importance on the experience they get while purchasing a product than how the product performs. A design-driven culture that seeks to give customers the best experience isn’t just for startup companies alone; even large organisations must ensure that their customers have the best experience throughout the buyer’s journey. Benefits of Building A Design-Driven Culture Organisations that build a design-driven culture enjoy so many benefits, including: Stock market lead: A recent research by the Design Management Institute’s Design Value Index indicates that design-driven companies have maintained stock lead ahead of others by outperforming the S&P 500 by an extraordinary 219 per cent over the past ten years. And that is why so many companies are committed to improving user experience, driving growth and remaining competitive using design. Saves time and money: Design-driven organisations understand the business opportunity, focus on the right problems, map out the right business strategy and deliver the right outcomes to their customers. Learn from failures and successes: One key benefit of design-driven culture is that it helps team members learn from both their successes and failures while engaging in the design process. Organisations and team members that embrace learning are not afraid of making mistakes and create better ideas that solve problems in real-time. Key Elements of Design First, every organisation that embraces the use of design must have a perfect understanding of the customers need. This is because the difference between a design-driven company and other companies is their capacity to go beyond understanding what customers want and uncovering why they want it. Design-driven firms do not just rely on data, which may not account for the empathy metric. Instead, they turn to ethnographers who conduct interviews with shoppers, listen to customers, get feedback on how customers make use of a product, and record their experience they have thereafter. Secondly, the key to running a design-driven organisation is to ensure that the right sets of people are employed to carry out a given task. It is vital for every design-driven organisation to employ the services of a Chief Design Lead to take the lead on strategic business decisions and remain a primary customer advocate. He or she has a responsibility of translating business goals into customer-friendly initiatives by building a culture where employees strive to enhance the customer experience. Furthermore, an excellent customer-focused design must start with a braided approach that aligns design, technology, and business strategy, while keeping the customer’s experience in check. It also includes having people from different backgrounds such as industrial design, visual design, user experience, research, and rapid prototyping coming together to create a design that focuses on giving customers the best experience. “Furthermore, an excellent customer-focused design must start with a braided approach that aligns design, technology, and business strategy that aligns together while keeping the customer’s experience in check.” Also, design-driven organisations make use of iterative design processes that allow them to identify user needs through user research and generate ideas that meet their needs while developing a prototype. A design-driven organisation will also take the next step of testing the prototype to see if it meets their needs in the best possible way. The insights that were gathered from testing the prototype must be used in amending the design. Following that, the firm can create a new prototype and begin the process all over again until they are satisfied. 4 Steps to Building A Successful Design-Driven Culture Transforming an organisation into one that focuses on design as a change agent takes a lot of time. However, the steps listed below can help you with your transformation: Get a professional design coach: Every design-driven organisation needs the services of a design coaching professional or firm to ensure that design factors like customer experience are part of any business strategy. Review your metrics: It is also essential for every design-driven organisation to define and regularly review their design metrics and key performance indicators, and test them to discover areas where changes must be enacted. Work with the right set of people: To ensure that your transformation is a success, you must ensure that as an organisation, you work with the right people who ensure that your design actively contributes to business decisions and the development of experiences across the customer’s journey. Understand what motivates your customers: You can have a perfect understanding of what motivates the customer by using human-centred design research techniques that interact with customers and discover vital information about them. Finally, to become a leader in business, it is vital to build a culture of excellence where people feel comfortable to try out new things and encourage learning from failure. Implementing a design-driven culture will enable your organisation to clarify their objectives and deliver value to people in an effective and efficient way.

Transcending Borders...

Getting the opportunity to travel for work is a privilege that not many get to enjoy, lest moving to another country to experience a working life. I sat down with a few colleagues who have had the great opportunity to work from the various offices that we are based in, around the world, to get a peek into what their experiences have been like. Mention Sydney and the first thing that comes to my mind is Bondi Beach or the many coffee joints that have popped up over the years. The capital city of New South Wales, Sydney, best known for its picturesque harbourfront overlooking the Sydney Harbour Bridge and Sydney Opera House, is home to many exciting tech companies and startups looking to be the next Airbnb and Uber. This week, I sat down with Guillaume Teillet, a Software Engineer at PALO IT Singapore, who had experienced a short stint at our Sydney office. Hey Guillaume, could you share how you got the opportunity to work in our Sydney office? In 2017, I went to the company retreat in Bangkok and Tanguy, our Regional Managing Director, gave a speech about the Internal Mobility Program in PALO IT. A few weeks later, during my annual review, I expressed interest to Jessica, our Chief Happiness Officer, and told her that I was interested to apply for the Internal Mobility program offered by PALO IT. It was very timely at that point in time as our Australia office was just established and I have never been to Australia. I thought it was the perfect opportunity for me to explore the city and I discussed with Tanguy about the possibility of joining the team for a short project. Within a few months from our conversation, Tanguy got back to me and I joined our Australia office for three months, right after our company’s retreat to Bali in 2018. During my time in Sydney, I joined a team of 6 people (3 developers, 1 Agile Coach, 1 Product Owner and 1 Business Analyst) on an innovative trigger-based insurance project. We developed a web application in React that allows customers and the insurance company create customised insurance products. We built the backend with C# .NET and deployed the project on Azure. This project was a great opportunity for me to improve my skills in Microsoft technologies. PALO IT Australia is an intimate team of 15 people. The office is located in a co-working space called Tank Stream Labs and for this project, we were working from there. In the co-working space, each company would have its own dedicated space while sharing the common facilities (meeting rooms, pantry, pool table etc.). It’s always nice to be able to share a coffee or a drink with individuals from other companies and exchange ideas on the way we work. We’ve heard a lot about the work culture in Sydney. Could you share more with us? “No worries mate!” would best summarise the Australian mindset at work! The work culture in Sydney is so different compared to what I have experienced before — in Sydney, the work-life balance is very good and I feel that people are relatively more relaxed at work. It was amazing to be able to mix work and team moments, just around a cup of coffee or a pool game! More importantly, how did you look into maximising your stay there? What did you do over the weekends? Over the weekends, I took the opportunity to discover the rich Australian culture through visiting food festivals and attending operas in the world-famous Sydney Opera House. I used the time I had to discover the countryside as well — I did a road trip with my girlfriend and my sister, travelling from Airlie Beach to Cairns. We even took a plane to fly over the Great Barrier Reef, observed kangaroos in the wild and flew over the city center. We also managed to witness the fireworks at the Sydney Opera House on New Year’s Eve! During the Christmas break, I also took a flight to New Caledonia, a French territory three hours away from Sydney. I had never thought about visiting New Caledonia before because it is a very isolated island in the Pacific. Being only a few hours away, I told myself I could not miss this opportunity! The overall experience I had there was amazing. I will not want to trade it for anything else! What stood out the most for you? On the professional side of things, I really learned a lot about new tools and the technologies from Microsoft. I would like to take this opportunity to thank my colleagues, Alex and Sang, for being great team players and mentors. On the personal side, the beautiful landscape and the diverse culture of the country stood out the most for me! Australia is a wonderful place in the world and it was amazing to be able to discover their work ethics and culture. The three months were definitely too short to be able to discover every part of Australia. I definitely need to go back as there is so much more that I have yet to discover! Would you go back again, if given the opportunity? YES! YES! YES! Definitely! In fact, I am already in the talks to see if there are other opportunities for me to experience working from the other offices or going back to Australia. It was definitely a fantastic experience and I cannot emphasise how beneficial this internal mobility program has been for me. I enjoyed my time in Australia and the Sydney team was very welcoming. It was a real pleasure to work with all of them! Aside from reminiscing the good times in Sydney, I could clearly tell what stood out for Guillaume were the fun times he had “working” with the colleagues in our Sydney office. I mean, doesn’t this picture say it all? I nodded and smiled as I spoke to him about his experience, but really, deep down inside I was jealous. Perhaps, I’ll take the opportunity to walk over to HR right now and express my interest to do the same. We shall see! Internal Mobility Program PALO IT’s Internal Mobility Program was set up to allow our employees to work from the many offices we are based in, ranging from a few weeks to a few months. This program hopes to provide a dynamic working experience within PALO IT, where its employees grow holistically and are able to experience the diverse culture and work environment the company has to offer.

Sniffing out the fun...

The title of this article might throw you. How, after all, can an Agile team have a ‘funk’, or a bad smell? To explain this, I have to walk you through an analogy I ran into while reading the book The Power of Habit by Charles Duhigg. Today, Febreze is a household name for our air-freshening needs. Little known, however, is the fact their product was on the brink of failure despite being “a breath of fresh air.” When Procter & Gamble came up with Febreze, they expected their product to fly off the shelf. Instead, sales dwindled. People who needed Febreze most did not realise the strong odour in their house. For example, when marketers visited a woman with nine cats in her living room, they realised she had grown used to the foul odour and did not notice the smell at all. People who have become accustomed to bad odour in their living environment will often get used to the smell and ignore it. Similarly, in an organisation that prides itself on running Agile, bad practices that everyone has become accustomed to can often be ignored. This situation is more than often  indicative of deeper problems. Let’s explore a few different Agile ‘smells’ and how you can Febreze them out of your organisation. 1. Silence is not golden Organisations, no matter how big or small, encounter breakdowns in communication. It might seem intuitive to tell your team to speak up, but that’s easier said than done. Creeping scope, unclear user stories and delayed deliveries are caused by a lack of communication. If your team members don’t talk to each other regularly each day, it’s time to start sniffing around for the underlying problem, and there’s no better way to discover issues and blockers than face-to-face conversations. Your organisation can foster collaboration by allowing team members to work in proximity to each other. For a global team, they should use portals like Slack and Google Hangouts to foster communication. It’s also essential to hold a standup meeting every day. A 15-minute, face-to-face meeting lets the team sync for the iteration and communicate any impediments that could block development and delivery. To ensure the meeting is fruitful, the information being shared should be measured in quality, not quantity. 2. Leaving users out of the equation Unlike a traditional waterfall process, an Agile team should strive to shorten the feedback loop to its users. Startups and SMEs often lack the resources and time to reach out to users, combined with a lack of communication between both parties, the product is in danger of not responding to the needs of users. Users are your most important stakeholders, their opinions can help the organisation frame and validate your vision for features and functionality. You can analyse the most popular requests submitted by users and use it to groom the product backlog. By talking to users, you can obtain important data and trends that are crucial to product development. You should check this feedback loop every iteration so you don’t build a product that doesn’t meet user needs. 3. Playing the blame game If you are new to developing a product or software it can be a baptism by fire. Time and time again, when you release new software, complaints from clients will come flooding in. Imagine waking up one day, you smell burning fumes, you walk to your kitchen and discover a piece of burnt toast in the toaster. You naturally wonder who is responsible for making your kitchen smell like a barbecue. As survival instinct kicks in, we often shift blame to others. It’s very typical for people inside an organisation to start pointing fingers—most likely at the development and the QA team. This blame game is very destructive to team morale, which in turn hinders future product development. To combat this, we have to be honest with each other. An organisation should not seek to single out any members of the team. As a team, it’s essential to understand that the team either succeeds or fails together—teams should seek to make rational decisions together as a cohesive unit. 4. Fearing failure People usually want to avoid a failed project because it’s considered detrimental to their career. As a result, fewer people take the risk of starting a project that might not succeed. Management might also rashly set up an insurmountable amount of hurdles for the team to overcome, so much that they end up catching themselves in a ‘paralysis by analysis’ situation, where every idea needs to get signed off before execution. Even if people are taking risks, they take the lowest amount to ensure they won’t fail. In this video, you can see SpaceX made plenty of mistakes before creating a functional orbital rocket booster. We often dislike the idea of failure, as we fear we might lose valuable resources and time. This might be true if you are managing a factory that requires consistent performance in a pre-defined set of standards. However, if we apply that in an ever-evolving business, the idea of avoiding failure can strangle the innovation of an organisation as a whole. Don’t play it safe, learn to let go and embrace failure. The culture of experimentation is very crucial to an organisation. Your product might not currently boast every feature you’d like it to, but if you never take it to market, you’ll be in the dark in terms of user feedback and unable to build the best possible iteration in the long-term. 5. Dealing with drill sergeants Management wants to see results: a rise in revenue and profit, an ever-growing user base and brand awareness amongst the public. When growth stalls, management often falls into panic mode, “what are we doing wrong?” In a time of crisis and panic, management often falls for the fallacy “great leaders don’t tell you what to do, they show how it’s done.” Leading by example is crucial, but this top-down approach can cause teams to become indifferent. It also suffocates their spirit of innovation. In Agile, leadership is not only about barking orders, but also lending a pair of ears to any suggestions coming your way. As servant-leaders, management should make sure employees understand the vision, starting with the "why", and let the teams define the "how”. In Agile organisations, management should guide teams with questions. Questions such as “What do you recommend?” are very useful to inspire teams. According to David J. Snowden and Mary E. Boone, executives at one shoe manufacturer once opened up the brainstorming process for new shoe styles to the entire company. As a result, a security guard submitted a design for a shoe that became one of their best sellers. It’s essential to trust the talent in your organisation.You never know who will come up with the next groundbreaking idea. So, slow down and smell the roses. Appreciate your team’s talent and embrace change when it drifts your way. Maybe then you’ll be able to sniff out the deeper issues in your Agile team.

Sprint Retrospective...

Can you sense the drop in ENERGY, when the retrospectives become boring? This article is based on one of the experimental retrospectives that I have facilitated using Rory’s Story cubes and Liberating Structures by Henri Lipmanowicz and Keith McCandless. Sprint Retrospective is a very important event in Scrum as this is one of the most crucial feedback loops for the entire system. I consider it as the heart of the Scrum ecosystem as this is where you would formally get an opportunity to meet and talk about improvements around your ways of working and agreements that bind the entire process together. To be a Scrum master is like being a thermostat. We must recognize the drop in engagement and participation levels of teams and adjust the course to improve the overall experience. Every team goes through an inevitable drop in energy over a period of time. When you feel the energy drop in the retrospectives, then one of the highly engaging and energetic ways to do retrospectives is by using the Story cubes. Story cubes are considered as children’s toys, but they possess the ability to connect with people on a visual-spatial intellectual level. How to conduct a ‘Story Cube Retrospection’: Although there are a lot of ways out there, I have personalised it a bit. Things you may need: Whiteboard Markers 9 cubes from the Story cube set. Sticky notes for “1–2–4-All”. Request people to stand for this activity. Preparation: Create Three columns on the board i.e. Happy, Sad, Action. Let the team roll the dices and pick them up one at a time. Every dice will have an image on the surface, let the team members talk about the experience from sprint which comes to their mind while looking at the image. Make a note on either the happy list or sad list. Repeat this activity for all the 9 dices. Now against each happy or sad item, get the team to dot vote what they want to pick up to improve on the next sprint (Recommendation is to pick just one or maximum two, depending on your timebox). Now, for every item that is selected, run a “1–2–4-All” session. 2. How to run a 1–2–4-All session: Let the team members brainstorm over the topic individually and make notes on a sticky note — Timebox — 1 minute. Repeat the same activity in pairs (exchange the ideas in a brief manner) — Timebox — 2 minutes. Repeat the same activity in quartets (exchange the ideas in a brief manner) — Timebox — 4 minutes. Repeat the same activity with the entire group sharing and noting the most suitable solutions around the topic — Timebox — 5 mins. Note: You can customize the repetition based on your group size. Once you have run the 1–2–4-All for the selected item, you will have solid actionable items derived by the team to conclude the sprint retrospective. I have facilitated quite a lot of retrospectives as a Scrum practitioner and from my understanding, one of the best ways to conduct retrospectives is to keep changing the way you run it. On average, I recommend trying a new way every three sprints, which gives the team a sense of familiarity while at the same time, enabling them to learn new creative ways to do retrospectives. Happy Retrospection!! P.S Thank you Nagesh for including me in the Liberating Structure user group Bangalore.

Anti-Patterns of Ent...

Throughout the years, many people have learnt to implement agile but are still struggling with how to run big transformation programs. Many big organisations take initiatives building a central team of coaches for transforming the whole organisation into agile, but there are some mistakes that should be avoided. While working with big organisations as a member of an agile transformation team, I have learnt some anti-patterns that I am going to elaborate in this article. This is the first article in the series to cover mainly seven anti-patterns: One size fits all. Too long preparation time All at once Ignorance of supporting environment Ignorance of technical practices Vendor management and distribute team excuses Agile as a delivery engine In this article I am explaining the first anti-pattern: One size fits all Each product is different from another in terms of complexity, team structure and vendor association. How then, do standardisation of tools and practices work? This is one of the most common anti-patterns of agile transformation programs. Many organisations try to standardise agile practices, tools, and behaviours. In my experience, I have seen people recommending, or worse, forcing teams to use enterprise-level best practices or tools. There is no best-practice, because the best practice does not leave a room for improvement; which is against the agile principle of continuous improvement. Secondly, recommending standard practices defeats the purpose of flexibility in agile, which was the original reason of not making agile frameworks prescriptive. For instance, there are many big organisations that write their own agile methodology and prescribe all the practices, tools and how to implement them. Also, they call it “<company name> + Agile Methodology”. Often this appears to be a compromised version of agile. Similarly, organisations choose one standard agile tool for all teams without knowing if it would be comfortable and suitable for teams. The most common pattern is using one electronic tool for all teams that use Kanban. However, there are better tools available to serve the purpose. For example, recommending Atlassian Jira in the whole organization can lead problems for kanban teams. Instead, they might use Swift Kanban or Trello which are a better fit for Kanban. The more alarming situation is when the teams are co-located and can use physical boards, but are forced to use the electronic tool because it is a recommended standard enterprise level tool. Why is Standardisation Harmful? As every human being is different and forcing them to behave, talk and work in the same way can be counter-productive. Having a standard agile methodology in every situation proves to be harmful. I have seen support teams struggle with fixed iterations, novice teams struggle with a continuous flow of work and support functions struggle with writing user stories. Hence, standardisation only leads to frustration in people and compromise in business benefits. It mostly happens when people focus more on practices rather than on values and principles. Moreover, not having trust on teams for experimentation and not letting them choose their own suitable way of working can harm productivity. Custom Fit  As you might be convinced by now, “one size fits all” does not work. What is then the solution? The answer is “custom fit”. The first step is to understand the context of the team, product nature, people, and business expectations. Then, choose your framework, set of practices and principles accordingly. Try and continuously learn from your mistakes. This way, the method will evolve over the period of time and you will find the “suitable model” for you. Don’t stop improving! Please share your experiences. Do you use standard tools and practices? Are they working for you? Have you evolved your method over the period of time? Stay Curious! Coming Soon: Second anti-pattern – Too long preparation time.

How: Cracking the En...

Enterprise mobile apps have moved from ‘nice to have’ to ‘mission critical’ tools for many organisations in the recent times. A recent study has found that demand for custom apps that allows employees to be more productive is on the rise. However, the process of deploying a mobile app for an enterprise is not only hard to navigate, but also taxing on the finances. "Organisations spend countless hours and a fortune working on the design, user experience, development, testing, infrastructure and finally training; only to realise that the seeds of the apps have sprouted weeds instead of fruits — and by this, I mean ‘low adoption’." ‘Adoption’ is the word that haunts most of the organisations when it comes to enterprise apps. As a product owner myself, after our product went live; with the roll out plan heavy on internal marketing (right from marketing videos, posters, surveys and town-hall meetings to other engagement activities) and dedicated trainings (pit stops, classroom trainings, refresher trainings and tutorial videos), I waited patiently to see the fruits of the effort the team had put in. I’ll be honest — at first, I was definitely not disappointed. The increasing adoption rate was really satisfying to see. But soon enough I realised that the beautiful graph of adoption was what we can call a ‘Typical Adoption’. To give you a background, we had tried to follow almost all the best practices available for creating the good enterprise app. ‘Involve ends users upfront’ — check, ‘quick and multiple feedback loops’ — check, we even worked hard to get our internal marketing and training tactics right. As you get the point — I was pretty puzzled on why the adoption was taking a hit. So with a mind full of questions, I got down to do some industry research on adoption of enterprise apps. So I decided to charge and chart out a strategy to analyse and fix the 'typical adoption' problem for enterprise apps. Step 1 - Analytics - Measuring the results Everyone needs analytics. When it comes to adoption of mobile apps, analytics should be the basis of every decision taken — right from strategic to tactical. "Trying to improve adoption rate is like changing wheels of a moving car so that the car runs faster, and analytics would help you point out which wheels to change." The metrics you would want to measure would differ based on the type of app you are dealing with. Holistically, there are two categories of apps — engagement driven and transaction driven. For our case in point, we would consider that the app is transaction driven. Primarily, we need to look at two main buckets of data — performance and usage (no brainer). However, getting the data categorised as per metrics is only the start. After we have the data in place, comes the herculean task — making sense of the data! And the best way to do this, as per what I did, is through segmentation approach. The first level is to identify the ‘Repeating customers’ versus the ‘One time customers’. You’ll be able to get this information via the retention and churn data. The reason why it is of utmost importance to get these two segments right is because you’ll have to analyse and handle these two segments in a very different manner. For repeating customers, you want to know why they came back to use your app, and for one time users — why then they didn’t. The next step is to look for patterns within the segments. In my case, I was able to identify specific personas using the demographic information of the users and team structure. Step 2 - Asking the Users - Survey & Interviews In our case, gathering feedback is like killing two birds with one stone. First, it would give us actionable insights which would help us on our quest for higher adoption, and secondly talking to the users and taking their feedback makes them feel that you care enough to consider their views. This will increase the feeling of ownership and could win you with some internal advocates of the app. We need different sets of information from the personas identified, and hence the best way is to design different short surveys based on the personas. The survey should not be very long and the user should be able to complete in 1 to 3 minutes. Any longer and you might lose their attention. Surveys should be designed keeping in mind the potential problems users might be facing. This would streamline the thought process of the users and help you gather structured data rather than haphazard feedback with no actionable insights. Once you have the survey data, analyse the responses to identify the top users who gave clear and useful feedback. These are the users with whom you want to discuss more and pick their brains for insights. Set up interviews (ideal length  –  30 minutes) and gather detailed feedback. Step 3 - Identify the problem Now that you have all the data you need, it’s time for the moment of truth. This is where you map your findings, look for patterns and deduce potential reasons for the low adoption. From my experience, there are 4 potential reasons why enterprise mobile apps fail. 1. Users ear disruption of existing processes Change management is hard. People don't like changes - unless something is really broken. While this may be one of the hardest issue to solve, it is definitely possible. Here are some suggestions to ease out the transition - Communicate the benefits of the change clearly. This should be the core theme of your internal marketing. Have a robust support initiative. The end users should never feel stranded with a pile of issues with the new system. Use the top-down approach. A subtle push and guidance from management will reinforce the trust of the end users in your product. 2. Users don't feel confident enough to use new technology for important processes. (Fear of screwing up) Considering everything you do is related to technology in some way or the other, you would probably not face this problem. But my project has a very specific segment of users who weren’t comfortable using tablet devices. They preferred paper over a tablet, and that was one of the culprits. So here are some of the approaches we took to mitigate the issue – One on one training sessions with the users. Users from this segment don’t usually come out and ask questions in group trainings (due to the fear of feeling stupid), leaving them with unanswered questions and hence leading to low or no adoption. Tip  –  include role plays during the training. I would be repeating myself, but there is no replacement for a good support initiative. Make sure you are always reachable and in their radar. 3. (The most dreaded one) Priorities of the users versus value proposition "Fun fact — end users do not have spare time. So if your product demands them to spend time which doesn’t result in time saved down the line, it is very unlikely that they would keep using the tool. Thus, leading to the downward spiral in adoption rates." While your product may still have a strong value proposition, that might not be what your end users are looking for. In most cases, this issue should not happen if you have done your UX study right. But sometimes the processes are so complex (specially in financial institutions), that a digital clone of a manual process may end up being more taxing for the users. While there might be way to coax your users to adopt your product even in this situation, I would recommend the hard way – going back to the drawing board. 4. Users aren't aware of the capabilities of the product. Alas, while we thought we had a failsafe training plan in place  –  we realised many of our users weren’t aware of what all they can do with the app. However, this issue is relatively easy to solve. Here are some tips on how you can do it better – Opt for short videos which the users can refer to at their own time. Make a FAQ page for the app on the internet. If your company has already jumped in the chat bot bandwagon – that is also a good idea.

How To: Conduct Rese...

The designer came back and asked exasperatedly, “What do I do with this?” He was looking at a research report that was meticulously done, but that did not help translate into something that could inform ideas on a solution or even physical designs. I often get asked by clients, “How do you get from research to design?” I admit it’s not an obvious transition. You learn something about someone, designers go back to their desks, and all of a sudden you have a specific solution. How do we know that creation was founded on what we learned? It is a concern where we as researchers have to look at our own work and ask — are we serving designers with what they need in order to do their jobs? Are we speaking on behalf of the user in a way that will encourage creativity, possibility, vision? When our research does not bridge the gap between knowledge and creation, our research is useless. UX Research is meant to engage, inspire, and ultimately mobilize those who use it. This goes all the way back to when we embark on research and all the way to how we structure and communicate our findings. How can we make sure that research informs design? Ask the designer what he/she needs to know to do their job. I know it seems obvious, and sometimes the researcher IS the designer, and they still miss it. Even with designers, they may mentally disconnect the research activities from their design activities. I create objectives before I create any materials in the research, and those objectives are informed by what I want to know about the user and what the designer and developer want to know about the user. Ask yourself — “Does this get me closer to a solution if I know this?” One flaw that I see in analyzing data is that you analyze it and then you. report. everything. Not all information is useful. What information pushes the narrative of the user in a way where you can understand what goals they have, what type of solution they need, what user flows are necessary, what features are relevant, and what content is important at what time? These are all questions a designer is worrying about. If the information is “nice to know” but doesn’t inform them on this, you’ve wasted their time. Create an empathetic story. A big part of design thinking is having empathy for your users. This is powerfully relayed in the way that you explain and contextualize your research. Who are your users? The quickest way to predict what someone will do in a hypothetical situation is to understand about their motivations, attitudes, emotions, and their triggers(events that get them thinking about something your client is probably interested in). Paint a picture of them on that level, and people will be able to empathize because motivations can be shared, how we enact them in different context, cultures, etc. can be different. I walk clients through an “emotional user journey”, a journey that shows not only what they do but how they feel at each point in time and why. It helps clients experience the ecosystem they may be stepping into on a gut level. Highlight solvable problems. In design thinking, we want to create statements of possibility, an open invitation to consider alternatives. “How Might We… improve the way we track people’s time so that time sheets aren’t so painful to fill out?” “How Might We… reimagine a toothbrush so that users can reduce their environmental impact?” Our research should help inform these ideation questions. Represent the user. Research is a process often with documents to consolidate learnings but it shouldn’t stop at the document. Reports, personas, user journeys, etc. distill the rich information you have experienced in this process. If the researcher IS the designer, that’s amazing. Then the user lives on in the designer in a primary form. If the designer is NOT the researcher, the user lives on in the designer’s memory of the presentation and interpretation of the report — a secondary form. If this is the case, the researcher should be providing advice, reviewing, or co-creating with the designer. Research is not a powerful design tool unless you approach it knowing what it will be used for. Why should businesses care that we approach research right? Research gives us confidence that we are looking at the right problems. All good projects must start with truly addressing real problems — otherwise, you’re wasting a lot of money on creating something that is solving a problem no one had. Subsequently, how do we know we are meeting the needs of our users? Research helps businesses establish a baseline for success metrics. Good initial research helps us measure our return on investment. Why should designers care that we approach research right? Research should be one of the most impactful tools in a designer’s toolkit. Research ensures decisions are focused and informed. It keeps stakeholders and designers honest about the design decisions they make (or argue over) because the rationale from the research should back it up. Research at the beginning isn’t the end-all-be-all. It’s an informed starting point. As we progress, we learn more. But it provides more confident user assumptions to start with. Designs can create targeted user tests (does our design solve the problems we revealed in the research?) so that we can continually clarify what we know and whether or not we are on the right track. Research is okay when it addresses gaps in our knowledge: “I want to know you”. Research is a powerful tool when it bridges the gap between knowledge and possibility: “I want to know you so that I can help you.”

A mentor’s way to pr...

How to foster mentorship in a team? The traditional way of helping someone improve in their work is to provide constructive feedback. i.e., you observe something, you tell the person “here is what I have observed, and I think you could improve by doing this…”. At PALO IT, we meet regularly to share and learn from each other. In our last team gathering, I suggested we try the Feedforward exercise inspired by Avraham Kluger, Organisational Consultant, and Marshall Goldsmith, Executive Coach. It is a technique to give and frame suggestions in a much more powerful and positive way than standard feedback. Let’s start! 1/ Introduce the exercise by saying something like: “We are going to do a Feedforward exercise where each of us is going to receive suggestions from the others. Each suggestion should be treated as a gift. A gift is something you receive, you don’t always like it but you always say thank you.” This way of introducing the exercise is to reinforce an attitude that should always prevail: respect each others’ ideas, don’t be judgmental and express yourself. 2/ Ask your team members to each think of one thing they want to improve. It can be anything. 3/ Form pairs. In each pair, team member A says “I want to improve…”. Team member B says “Then you could try to…”. 4/ Reverse roles. Team member B says “I want to improve…”. Team member A says “Then you could try to…”. 5/ Split and form new pairs. Continue until everyone has talked to everyone. At the end, I asked each team member to give me one word to express what they felt and the results were amazing: “Energised”, “Positive”, “Great”, “Inspired”. And they asked to do it again the next time we meet! The numerous benefits of this practice The “no judgement” style makes people feel comfortable on both sides, receiving and providing suggestions. Because the person receiving advice is choosing the topic, it is perceived in a much more positive way than typical feedback. We don’t focus on saying what is not done well up to now, but what you can start doing from this moment forward. Again reinforcing positive communication methods. Team members get advice from different people with different backgrounds and skills. Team members get to give advice even though they may be junior. It is a way to learn to be self-introspective regardless of experience, as well as gain confidence in expressing ideas. Everyone participates, but with an one-to-one approach. This puts less pressure on people who are shy. I recommend you, as a Leader, to also participate. It makes everyone feel on the same level. You will lead by example and of course you end up learning new things as well. Conclusion For all the reasons above, Feedforward is a much more positive exercise than giving feedback in a traditional manner. You can also use it for one-to-one sessions with your team members, however I think the group version is even more powerful. If you want to learn more about this Feedforward interpersonal improvement activity designed for team and organisations, I invite you to watch the following video: And you? Have you ever tried it yourself? I would love to hear about your experience!

Designing an Interna...

It all started with an idea that came about during a conversation I had with my boss, Nadege Bide, when we had just finished a project for a banking client in 2017. During our dinner to celebrate the completion of the project, we were discussing how we could apply the functionality of some aspects of our new product into UX practices. I immediately saw an opportunity coupled with a clear vision to make a promising new project. Enthusiastically I manifested my desire to transform the idea into a reality and sooner that I knew, I got the approval to work in the project envisioned. “The idea of the project was to help UX designers with qualitative user research. A project that I named RestitUX.” Alongside other talented Palowans I was able lead the project of RestitUX from inception to MVP, relying on prior research to come up with the following product:   The Product PALO IT to present its interview research and speech-to-text technologies internally. The main features of the MVP includes: Create questions based on objectives: User needs addressed: This gives guidance to anyone who wants to do interviews (UX, PO… and even marketing or sales people) and make sure that every question asked will respond to an objective of the research. Conduct interviews with speech-to-text transcription and tags: User needs addressed: Allows users to index and structure information as they conduct the interview to save time during the analysis. While we usually encourage at least two people when conducting interviews, at PALO IT, it might not always be possible. Edit text and selection of the most important content to export it in a .txt file: User needs addressed: Based on our participant feedback , one insight we found during our research phase was the desire to be able to easily analyse each interview. The functionality of highlighting text allows the user to be able to see the information that interests them with minimum effort. Transcribing a recorded interview: User need addressed: Users that do exploratory user-research prefer not to write questions beforehand and ask questions in a more spontaneous way. For this kind of interviews, the users can input a recorded file to get it transcribed from speech-to-text and have the tool analyse it.   How We Made It 1. User research phase In order to make a product that addresses its users needs and desires, I was given the opportunity to lead a formal user research where I interviewed  different designers of PALO IT’s design team from across our international offices (Singapore, Hong Kong, Mexico, Paris…). I got the opportunity to interact with designers from different backgrounds and experience levels to understand and define a strategy that ultimately creates the most inclusive design possible for our target audience. We wanted our targeted users to be able to express the way they work, their pain points, their habits, etc.. The challenge was not bias my research or findings, in order to do so, I took note of all the important feedback from the participants to later define the most important solutions in speedboat workshop with some of the other colleagues from PALO. The idea was to put myself in our client’s shoes, when they think they know their users by heart (which in most cases turns out they dont know them as well as they thought). (more on the speedboat workshop later down in the article). 2. Competitor analysis Part of the vision I had when I first started the project was based on an inspiration that came from a speech-to-text app called “cassette”, that I fell in love with during my Masters in UX design. Typically, at PALO IT, we usually conduct functional benchmarks of existing products to ensure that we are able to identify existing solutions in the market and build the best product possible. At the end, RestitUX is the result of a blend of two of my favorite apps I benchmarked. Existing Solutions Cassette: An app for user research that allows people to transcribe information from speech-to-text while using bookmarks to define key moments during the interview. I found the concept of the app great, even though I found it to be a bit too simple. Trint: Trint is a speech-to-text service that allows users to transcribe recorded interviews. Some colleagues at work had told me about this new service which had proven to be quite useful, but painfully expensive. Note: We are using functionalities of tools that already exist but enhanced with an improved user experience. The goal of the project was to create a tool that will make Palowans more productive without needing to outsource apps to work efficiently and effectively, such as leveraging on speech-to-text technologies.   3. Framing and ideation workshops: Doing ideation workshops and framing the perimeter of the project is a classic process we have at PALO IT – the ideas are gathered in 5 days within a Design sprint, sometimes along what we call the inception sprint. At PALO IT, we have a complete deck of “innovation games” we like to use, depending on the insights we got from the users. This time I used the famous speedboat innovation game which allows us to have a view of the pain points they encounter during their process as the anchors of the boat t and all the desires and opportunities as the sails of the boat. The goal is to later involve people being able to vote for the ideas they consider the most valuable to them. After that we then got to co-designing the customer journeys of the users (3 personas in total) 4. Prototyping, Testing, Repeating… PALO IT is a development company and I learned a lot about working in lean UX with developers to bring an idea to life with all the code infrastructure needed to function. For this I also learnt a few of the skills product owners use to collaborate with developers in order to create a product. As for a true agile product, we got to work on the MVP by prioritizing the backlog. In order to do that, we used classic Kanban and Scrum. For those who are not familiar with these Kanban method board is a board tracking the process flow while maintaining the number of work-in-progress activities. On the other hand, a Scrum board is a board tracking work in Sprints. A Sprint is a short, consistent and repetitive period of time (which is normally 2 weeks). You can find the detailed difference between the two > here <. As a product designer, I was asked to understand how to write good user stories. I got a better understanding of how to write user stories and how to use trello or other software such as pipepify to do such tasks. The normal way of creating a user story is in this manner: As <persona> I want <what?> So that <benefit for the user?>. Tip: When building a product that has many User stories, it’s a good idea to give them numbers such as US#31 (User Story #31) to be able to refer to them more easily when having discussions with the development team. If you want to learn more about it I highly recommend this tutorial .  5. Things I learned during the process: POC vs MVP During the production segment of restitUX, I realized that I was mixing the terms POC and MVP. Put simply: An MVP is a minimal form of your complete product that is tested with the end users/customers. Whereas a POC is a smaller project, typically used internally not publicly, to verify a certain concept or theory that may be achieved in development. During this project a combination of both was used. We used POCs in the form of SPIKES to validate the feasibility of my ideas and eventually create a functional tool that would be used internally in the form of an MVP. If the term SPIKE is not familiar to you, in agile software development, a spike is a story that cannot be estimated until a development team runs an investigation of the feasibility of this story.   6. Debugging and testing When it comes to debugging, this is the first time I have actually experienced this part of the process, I originally thought that the debugging was the job of the development team, but it is actually a third-party that should do the testing and debugging to make sure every possible manipulation within the tool is working in optimal shape. There are different types of automatic testing so that a software can grow in a scalable way such as Cucumber, a tool we use at PALO IT. Now restit UX is being used by our Palowans and iteration v2 will come soon from the user’s feedback! This is a good example of how we all work together on a daily basis to make our client’s user’s life easier…   Final Thoughts The value of being able to work in this project was the opportunity to follow the proper design process for the creation of a product (from idea to MVP) in Period of 4 months. PALO IT is company that has Coding and agile development embedded to its core. If you want to get to know how to work with developers in an agile framework, this makes a great base ground for upcoming designers who want to make the transition into product design where you get to see the whole cycle of a the creation of product. Transition into product design The project RestitUX has allowed me to do a transition from UX/UI design into the field of digital product design as I was able to learn how to lead the project from inception to MVP delivery. In Justin Edmund‘s words, “A product designer oversees product vision from a high level (how does this feature make sense for where we want to be in 6 months) to a low execution level (how does styling this button this way impact how the user flows through this function)”. I am glad I was able to officially make this transition, as it has always been my original intent ever since I started learning about digital design and marketing back in 2011, Smashing Magazine.

Demystifying Agile –...

My experience in startups and PALO IT has taught me that Agile practices don’t only apply to software development teams. Agile represents a new way to increase the efficiency of your teams, respond to changing requirements, and deliver value to your clients. Agile only works for developers and software? It’s true that the Agile Manifesto was written for software development. However, the underlying “why” behind the values and principles of the Agile Manifesto is all about increasing adaptability and delivering valuable outcomes for your customers regardless of the domain. It allows companies to flourish in markets that are increasingly uncertain and complex. Agile helps businesses deliver instant value at scale. For organisations to survive the volatile market, they found it rational to embrace Agile. Today, there are over 70 different Agile practices, many of which are still evolving. In this article, I will seek to bust the myth that Agile is only for software development and explain how it can be applied to your non-software development teams. Make budgeting great again – The flexibility of Beyond Budgeting start! At the heart of traditional project management, the budgeting process and the budgeting mindset is still king. Organisations are used to drawing up quarterly budgets for five quarters, re-assessing it at the end of each quarter and make changes where needed. In order for organisations to become more responsive to the changing needs of the customers, the budgeting process must be addressed for organisations to become more Agile. As Bjarte Bogsnes has pointed out: “One of the most stubborn myths in traditional management is that the only way to manage cost is through detailed annual cost budgets, with a tight follow-up to ensure that no more is spent than is handed out”. The lack of flexibility can lead to wasted resources and effort if it no longer responds to the customer’s need. To bust this age-old myth, organisations can benefit from transitioning from a traditional budgeting process to Beyond Budgeting. Beyond Budgeting is the practice of creating shorter rolling budgets and reviewing them at regular intervals. Credit: Bjarte Bogsnes No matter what team you belong to, a company survives on delivering value to their clients. If your team is constantly looking to improve their work according to the customers need in shorter intervals, then the budgeting within the organization must match the strategic vision. Toyota – the car manufacturer, for example, made resources available just-in-time to meet each customer order. Beyond Budgeting allows more room for flexibility and improvement at shorter intervals. This process ensures your ideas responds quickly to customers idea and deliver value. By embracing Agile, it is not a call for companies to abandon the construction of a roadmap. It is still essential for companies to adhere the iterations to a long-term goal. For me, this goal should be accompanied by a cost-conscious mindset as well as making resources available as needed. Traditional budgeting in many ways has obstructed the nimbleness of companies. If other teams and projects can adopt Agile to become more efficient, it can lead to more valuable outcomes for the customers. Limiting work-in-progress (WIP) and maintain a consistent workflow Imagine chewing a piece of gum and watching TV at the same time, it’s easy to do both at the same time right? Now try to engage a conversation with someone and reading a book at the same time; it’s an impossible task to focus on both. The idea of “multi-tasking” has always been a buzzword in the business world. However, when we try to multitask, it diminishes our brain’s ability to focus and maintain attention on a single task. When we try to multitask too much, we won’t perform those tasks well, as our brain will try to take in too much information. This idea can similarly apply to the workflows of any non-software projects. Kanban methodology has taught us that we should limit our work-in-progress.Instead of juggling 10 tasks at the same time, it’s much more productive to focus on at most three tasks at hand. Credit: Roger Brown Any other teams should also possess a “stop starting, start finishing” mindset. According to the graph above, by distributing time on different projects, it’s actually reducing time in each project and creating waste that is not necessary for creating customer value. Jerry Weinberg, a computer scientist has shown that even if you account for a 10% penalty for each context switch, in reality the cost is even higher. Even as Agile preaches the positives of forming a cross-functional team, team members should not seek to multitask on different projects with a wide spectrum of context. For example, when a team member leaves to do work that is not related to the team’s work, the rest of the team has to compensate for the time lost as well as helping the returning member to catch up on the context in his/her absence. Through setting WIP limits, it helps teams to reduce context switching and avoid slowing down the team with an ever-expanding scope of work. This practice also reduces the number of mistakes committed by teams overloaded with tasks. Agile at work: the implementation of Agile Marketing To encourage non-software development teams to embrace Agile, it’s important to demonstrate the value and cultural changes that an Agile approach can deliver. I would seek to explain these valuable outcomes with the implementation of Agile Marketing. Agile Marketing can be defined as an Agile approach in which teams “identify and focus their collective efforts on high-value projects, complete those projects cooperatively, measure their impact, and then continuously and incrementally improve the results over time”. Since the approach embraces rapid iterations and data-driven decision making, it ensures your marketing investment is being optimised. Credit: Inbics To implement Agile Marketing, a marketing team should seek to develop flexible roadmaps of projects and tests instead of rigid upfront planning that is not adaptable to changing conditions. For example, a marketing team can release a part of a marketing campaign to selected users. Through this approach, the team can collect valuable data and user metrics to determine their likes and dislikes. The collection of this data will also help the marketing team to continuously improve their content. Agile Marketing embraces the visualisation of the team’s current workflow. The transparency of the project is amplified by increasing communication and honesty. Agile supports the team to collectively own the process of the project and encourage them to speak up and contribute to the project vision. With the aid of project management tools, stakeholders and team members can be aware of what’s going on at all times during the project lifecycle, including the team’s responsibilities and how money from clients is being spent. In addition, Agile Marketing serves as a risk buffer, as companies no longer have to pour in huge funds into a single marketing campaign that users may not be attracted to. As long as you can help your teams improve their communication and workflows, you are one step closer to Agile success. In reality, there is no one-size-fits-all approach to introduce Agile to your non-software development projects and teams. Final thoughts Most importantly, don’t be afraid to experiment with Agile. You should not coerce your team into an approach that does not fit their need. You should strive for continuous improvement, and never be complacent about adopting new ways to implement Agile with your non-software development projects and teams.