Drive Success with Intuitive User Experiences

How Adaptable Should Agile Be? When I first came across Agile software development, one particular phrase stuck with me – “Agile until it hurts.” After working for almost two years in an Agile environment, I started thinking that Agile somehow started causing not only pain but bleeding several times. The methodology that teaches us to adapt somehow needs adaptation. I will share why adaptation is necessary and how to achieve it, drawing on insights from my experiences. How It All Began: Project Setup and Emerging Challenges Our Scrum team followed Scrum practices and a 14-day sprint cycle. While things ran smoothly initially, increasing scope changes became a challenge as the product grew. The project, an operations management app with evolving requirements from multiple stakeholder teams, faced frequent and urgent feature requests, sometimes mid-sprint. New requests that arrived at that time were the result of various in-house demands from different teams using the application. Each request was deemed important due to the equal involvement of these teams in the organization. To manage these requests, we engaged in discussions with stakeholders to prioritize them effectively, utilizing several approaches to reach an agreement. Nevertheless, there were instances when consensus could not be achieved, necessitating mid-sprint adjustments to our sprint goals. Despite planning, these requests often took precedence over current tasks. The rapid influx of new features, priority shifts, bugs, and needed improvements made managing scope changes challenging. Adhering to Scrum’s framework became difficult as we struggled to keep up with the pace of change, leading us to be “too agile” for the environment. Starting to Tackle the Challenges As a product owner, I took this problem seriously and analyzed possible solutions. So, my first stop in this analysis was the good old Agile Manifesto, as we were still using Scrum at the moment.  “Responding to change over following a plan.” This principle suggests that the team should be able to respond to and welcome change (sounds like just what I needed), but Scrum’s “no change within the sprint” rule doesn’t address mid-sprint scope changes. Shortening sprints to 7 days might help manage scope, but client requests can still arise during the sprint. Adapting to change requires balancing completed work with delivery frequency. Maintaining a two-week cycle while frequently adding new features and changing plans made allocating time for critical phases like testing increasingly difficult. Consequently, sticking to the “no change” rule during sprints became unfeasible, prompting me to explore other solutions. I left some space in upcoming sprints for new features, which worked in some cases but not others. Sometimes, the design team completed medium to large features that later lost priority, causing inefficiencies and frequent context switching. Rushing without proper planning also led to neglected performance and suboptimal iterations that didn’t integrate well into the overall product. Unveiling New Pathways After some time, I came across the Agile 2.0, which at the beginning seemed to me like the newest version of the iPhone – 90% the same as the one before, but this time, you have one additional camera lens. However, I read one argument on why Agile 2.0 is better that says:  “Agile does not tell you how to transition to being more Agile – it only provides a target state.” Since I completely resonate with this, I gave it a shot. So one of the first principles of Agile 2.0 says: “Any successful initiative requires both a vision or goal and a flexible, steerable, outcome-oriented plan.”  The difference here is that Agile 2.0 shifts from merely responding to change to actively initiating it.  Why is this different? When initiating, one needs a plan and a structure. This approach emphasizes the need for planning and structure, enabling teams to prepare for and embrace changes effectively. By focusing on goals rather than just tasks—like removing obstacles and achieving alignment—Agile 2.0 combines structured planning with Agile’s adaptability, enhancing overall effectiveness. Agile 2.0 didn’t introduce a new methodology or tool but rather facilitated implementing change. For me, it opened the door to implementing changes. While investigating Agile 2.0, I noticed it was built by customizing what didn’t work in an Agile. This also sends us the message that even the best methodologies need adaptation at one point. Our goal should be that we are always prepared for needed change and have a plan even for plan changing.  At the Heart of the Solution Next, we combined these new principles with the old-schooled Scrum we were previously implementing, left the strict frames of Scrum that were not serving us any longer, and still kept the good stuff. These are some of the key points: Encouraged clients to consider their most important long-term needs for the product Inspiring clients to think about their most important goals for the upcoming period brings a lot of value – to their business, to the product we are building, and most importantly for all of us to be on the same page regarding the priorities for the near future.  Introduced incremental planning with a time frame tailored to the team’s specific needs We started having more frequent planning meetings where we would discuss some of the newest requests and how to incorporate them into the upcoming work. In addition, we introduced a concept of quarterly planning to our clients to set clear goals for the upcoming quarter since the quarterly approach worked well with our client tempo. We ensured the incremental plan reduced scope changes for the team and provided clients with clear expectations for product expansions. Allowed flexibility for high-priority features while keeping a predefined general path for the upcoming months This gave us a clear view of planned features and expansions. We always left some space for thehigh-priority features to squeeze into particular months, but the general path for the next few months was preset. Still, we kept our sprint plannings, where we would add some smaller new features, bugs, and improvements to the sprint. But the “highest” goal was always known in advance.  Adjust plans according to the preset  goals: add new items if needed, decide if something must be removed, and establish priorities for removal When adopting plan adjustments, base them on the preset goals. If new items or features need to be included, evaluate whether existing elements should be removed to maintain balance. Prioritize which elements to remove by assessing their importance relative to the new additions and overall goals. This approach ensures that changes align with strategic objectives and resource constraints. This method balanced structured long-term goals with the ability to address immediate needs, ensuring that both the team and the clients were aligned on priorities. As a result, it significantly reduced the frequency of scope changes and improved overall project stability, making our planning process more strategic and efficient. Final Thoughts: No One-Size-Fits-All – Crafting Custom Solutions Agile and Agile 2 focus on flexibility, collaboration, and customer satisfaction. Agile 2 enhances Agile by streamlining processes and addressing its limitations, making it better for larger teams needing structured flexibility. But overall, my experience has taught me that no methodology in the world will fit each team’s and each product’s needs. Organizing work in a way that we are always ready for change but in a way where we planned it in advance by leaving space for urgent requests without disrupting the initial plan that much, was really a winner for my team. Product owners and service leads must adapt methodologies to fit their team’s needs for success. The challenge lies in finding the right balance between frequent adjustments and maintaining a structured approach. It’s essential to select the appropriate cadence that aligns with your team’s dynamics and project requirements. I found success by blending principles from Agile, Agile 2, and even waterfall into a custom solution tailored to my team. Crafting a solution and adapting it in every moment where you notice it doesn’t serve you any longer, using all kinds of sources and methodologies, certainly will give results if done properly – just give it a shot.  

Executing a plan without a formal design means you’re making design decisions. Whether consciously or not, you’re inevitably filling in the gaps, making assumptions, and shaping the user experience as you go. That’s why I want to share a few practical pieces of advice to help you avoid some of the common pitfalls. Before We Dive Into the Top 10: A Few General Best Practices Ask for 10 Minutes of Experience When building larger features or entirely new flows, consider consulting with a senior designer or an experienced peer. A 10-minute conversation can prevent hours of rework or a poor user experience that may persist because it is too expensive to change. Early decisions, like how to structure navigation or organize content, often have long-term consequences. Use a Design System (Even a Basic One) Using a pre-built design system, such as Material UI, Tailwind UI, Ant Design, or any design system already integrated into your application, is one of the easiest ways to avoid visual and accessibility pitfalls. These systems come with proven spacing and typography scales, color palettes, and well-designed components that handle interactivity and responsiveness out of the box, allowing you to focus on logic and functionality. Let Someone Else Click Through It A quick review from a colleague, whether they’re a designer or not, can uncover issues you might miss, from layout inconsistencies to unclear interactions. Share your work with teammates, stakeholders, or clients. If possible, get quick feedback from an actual user: ask them to complete a task you’ve just built and observe their performance. Top 10 UX/UI Tips: 1: Clearly Show the User’s Current Location When users land on a page, they should instantly know their location within the application. Use clear page titles, highlight the active navigation item, and include breadcrumbs for deeply nested hierarchies (more than three levels). This removes uncertainty and helps users stay oriented. 2: Make Important Features Easy to Access If a feature is used often, don’t make users dig for it. Surface key actions where they’re most relevant, and consider shortcuts for power users. Visibility should reflect importance. 3: Make the Primary Action Stand Out Every screen should have a clear “what now?” Users shouldn’t have to think about what the main action is. Make it visually distinct. A strong call to action reduces hesitation and guides flow. 4: Always Provide a Clear Way Out Users should never feel stuck or forced to complete something. Always offer a cancel, close, or back option, and make it visible. Giving users control and a sense of freedom improves confidence and trust. 5: Label Actions Clearly — Use Verbs Important buttons and links should describe exactly what they do, no guessing. Use verbs that match the action (like “Save Draft” or “Invite User”) and avoid vague terms like “Submit” unless the context is obvious. 6: Group Related Elements Together Things that belong together should look like they belong together. Place labels next to their fields, related controls side by side, and keep actions close to the content they affect. Visual grouping reduces friction and speeds up comprehension. 7: Prevent Mistakes Before They Happen Think ahead to what users might do wrong and gently guide them away from it. In user flows, look for steps that lead to dead ends or unclear next actions. For forms, placeholder hints, and default values can all help users succeed the first time. It’s better to prevent a problem than to recover from one. 8: Write Friendly Error Messages Sometimes we need error messages, but we shouldn’t show error codes or vague alerts. Instead, tell users what went wrong in plain language, and ideally, what to do next. Empathy in errors goes a long way in making the experience feel thoughtful. 9: Confirm Destructive Actions If an action cannot be undone and is not trivial to perform again, especially actions like deleting data or removing users, always ask for confirmation. Use strong cues, such as modals, colors, and wording, to signal that the action is important. A simple “Are you sure?” can prevent potential damage. 10: Follow Established Patterns (In the App or Elsewhere) Consistency makes interfaces feel familiar and intuitive. Reuse visual and interaction patterns already present in your app, as users are used to them. If there is nothing to reuse, borrow from tools your users already know, such as Google, Slack, Notion etc., depending on your user profile. Closing Notes You definitely don’t need a most delightful design to build a usable, thoughtful interface. With a few solid principles and a bit of pattern awareness, you can make good design decisions right in your code. These tips won’t replace a designer, but they may help you build something users can trust, use, and even enjoy.  “No Designs? Let’s Make It Work: Top 10 UX/UI Tips for Software Engineers” Tech Bite was brought to you by Zlatan Hajrudinović, Senior UX/UI Designer at Atlantbh. Tech Bites are tips, tricks, snippets or explanations about various programming technologies and paradigms, which can help engineers with their everyday job.

In the era of financial services’ transformation, where digitalization has become inevitable, the market is flooded with Fintech apps. It’s rare to find someone who hasn’t used at least one daily. Whether your app is geared towards investment management or streamlining buying and selling processes, our previous experience has highlighted two crucial aspects that demand your attention. Our team recently delved into the complexity of a digital investment platform, and they successfully navigated to address both aspects thoroughly. First and foremost is security. Coupled tightly with this is the user experience, designed with complete transparency and reliability in mind.  Risk Mitigation in Fintech: A Security Checklist  Security is always important, no matter what the business domain of your digital product is. But, when you add bunches of private data and sensitive financial information, it becomes even more serious. It is beyond the scope of this article to explore all security concepts within software engineering (explore our blogs section to find some captivating findings). However, we want to emphasize those that can seem obvious but could be easily overlooked.  Legal compliances  The most important aspects of legal compliance are data protection and industry regulations.  Different data security regulations are imposed for data-at-rest and data-in-transit depending on the following: region of business operations and  the geolocation of the user base.  The most known regulation for Europe-based digital products has been GDPR (General Data Protection Regulation).  In any case, the first thing to do is encrypt all data. Both in transit and at rest. There is a great whitepaper published by AWS called Navigating GDPR compliance on AWS. It contains simple guidelines for implementing the required rules to help you stay in compliance with GDPR. Furthermore, countries outside of the EU and even European Union countries can have additional requirements. Besides this, each Fintech digital product has to clearly define the areas of financial services it offers and comply with the known regulations for these areas, such as the financial market, investment management, or digital currencies regulations. These regulations can also depend on the business and user’s geolocation. There is a check-list to help you ensure the compliance each #fintech app desires: Investigate regulations that your Fintech digital product is eligible for based on the location of your headquarters and the geolocation of your user base. Study and explore these regulations to understand how they affect the architecture and functionalities of your product. Understand potential collisions between the requirements and set the course of action. For example, GDPR’s “Right to be forgotten” and many regulations in the financial market that ask for audit periods can collide. Therefore, action items can include: Separation of private data and transaction data inside the storage The highest possible level of anonymization of transaction data (needed for further audibility regulations Different combinations that can unambiguously define an individual have to be continuously monitored, with each new user’s information being ingested in storage or used in transactions.  Infrastructure Regarding infrastructure, most apps today are hosted on some cloud provider’s machines. This adds another layer of complexity and potential risk. For simplicity, the terms used in this article will be related to AWS. Principles apply to other providers, but their implementation can vary. Zero Trust Architecture Zero trust architecture (ZTA) is a security model that focuses on providing security controls that do not depend on traditional network controls. Instead, network controls are enhanced with identity, device, or other mechanisms. The first point is continuous verification. Users’ or other services’ access should be verified all the time for all resources. Enforcing a strong password policy, mandatory 2FA (Two-Factor Authentication), SSO (Single Sign-On), and using short-term credentials can help ensure that only authenticated and authorized users can access resources. Adopting the least privilege access principle limits the potential damage that can be caused by compromised accounts. Access policies can help implement least privilege access. A good idea is to start with a global Deny-All policy and explicitly grant only the privileges required for a user or a service to work. Security-related events, like denied login requests, should be monitored and trigger an alert. The production environment and supporting services should be completely isolated from development environments. This sounds like common sense, but quite often, some sort of communication is needed. In these cases, the least privilege access principle should be applied. Data at rest The great thing about cloud providers is that they make encrypting the data a seamless job. The first thing you need to do is identify which services have access to user data, store it, or consume it in any way. This includes but is not limited to, EBS volumes, S3 buckets, RDS, CloudWatch, or AWS Lambda. Logging services like CloudWatch can often be overlooked but can contain sensitive user data. Even though application logs should not contain private data, certain error logs can reveal sensitive information that will end up stored in CloudWatch. AWS KMS service is integrated with other AWS services and helps you encrypt data stored in these services. While AWS-managed keys automatically rotate every year, it’s recommended to use customer-managed keys. Using system-generated keys can sometimes lead to expired or exposed keys remaining in use, leading to insecure data. The customer-managed key lets you control how data is encrypted and define a specific key rotation period. It will help you better meet compliance regulations.  Data in transit Data sent from one service to another must be encrypted. Using TLS for “public” traffic is standard now, but connections in the same VPC shouldn’t be ignored, nor should connections between VPCs. While communication within the same VPC is isolated, there can always be a zero-day vulnerability which can lead to potential leaks. A simple service mesh can add an extra layer of protection and limit the blast area in case things go wrong. Tools like Istio service mesh or Calico CNI offer simple integration and effective protection.  The Essence of Reliable Customer Experience When sensitive data inputs, transactions, and operations are performed, users expect an impeccable feedback loop about the triggered actions, possible error states, and unexpected behavior of the application.  When users choose apps to help them with financial services, they usually select them for longer periods. For example, if they invest, and it is not just day trading, they want to stay there for a long period. Getting a user’s trust can take a while, and losing it can be quick. If users feel unsafe and unsure about where their assets are, have gone, or will be, they are likely to move elsewhere.  When dealing with the #fintech domain, make sure to delve into the following aspects of user and customer experience before any others. Error handling and bug reporting Errors will inevitably occur in any application. They can be due to incorrect user inputs or any other possible reason, but when they do, you need to inform users timely and precisely.  Example 1 shows a comparison between two different kinds of error messages. Example 1.1: Clear explanation of the upcoming steps and potential roadblocks Example 1.2: Every disabled action should be clearly explained Furthermore, each application strives to have fewer bugs, but some will happen. To ensure different ways for users to have easy access to report them is of the utmost importance. However, no matter how well-designed and envisioned error handling and bug reporting are, there is a slight probability that we will not catch everything.  It should be easy to access tutorials, a help desk, and live customer support to make users feel protected and heard. Predictable outcomes for actions and triggers The control they have over the application behavior and the level of predictability for their actions can give users a feeling of security and stability. To feel in control, users value familiar outcomes of the actions and the option to control the output by themselves. To achieve it, start with something you should avoid and eliminate. These are dark design patterns. For some time, there has been discussion about the sophisticated design practices called dark patterns. These are generally invented to trap users into actions they can not predict or bypass. And those are precisely what every #fintech app should avoid. It could give you temporary leverage, but along the way, it will scare your users and make them leave.  Additionally, you can take some more steps to ensure users feel comfortable to use different actions: Think about “heavy” actions users have to perform in your app, such as signing documents, confirming transactions, or giving permissions. Inform users about what to expect once they complete that action. You can use messages in toasts, banners, or label forms. Give them extra involvement and control over details that the app can do automatically, but it will not harm to let users decide. Example 2: Messages and clues  to inform users about the steps Example 3: Additional involvement of users makes them feel in control Real-time updates If there are real-time changes that users should know about, we must let them know as soon as possible. Keeping in mind there are financial assets users are managing through most of the fintech apps, real-time updates are very common. There are different options to consider in order to inform users on time: Real-time notifications:  Push Notifications: Ideal for immediate updates. Use them judiciously to avoid overwhelming users. Summaries: Daily, weekly, or monthly summaries can be sent via email, providing a less intrusive way to keep users updated. A user’s dashboard featuring real or near real-time updates: Engagement: It engages users with the app and lets them feel secure about what is happening.  Easy-to-grasp data: Dashboards almost always contain different graphs and table data—and to learn how to choose the right ones depending on your domain, check here. Keep things on a high level with the context of users’ settings if they affect the results, and allow users to drill down and see more details to feel extra secure.  Predictions: Last but not least, let users search the history and make predictions for their asset growth in light of the services they can use in your app. However, there are cases where your app can depend on 3rd party services that don’t provide updates as frequently as you would want. In this case, it is necessary to: Clearly show when the latest update was and when you expect the next update Notify users when data refreshes if the period is too long Let users know if there is any other way they can get the latest update (e.g., via phone call) if they need it right away Example 4: Users are well informed about the most recent data update