User Experience (UX) and User Interface (UI) design has been told to play a pivotal role in shaping the success of digital products and services but we ask the real question: Is it really all THAT? We bust some myths:
1. Myth 1. You must do User Research
We are just gonna come out and say it: You don’t need to conduct thorough user research. Who cares what the users think and want. You don’t need to understand the needs, preferences, and behaviours of the target audience at all. Your design doesn’t have to hit the mark. It is allowed to fail to resonate with users. Just go on your assumptions about what users will be expecting and just design the solution you think best. Users will catch on eventually.
2. Myth 2. It needs to be for everyone
Accessibility has long been wrongly seen as a critical aspect for UX/UI design. Just ignore the needs of users with disabilities and those with language or device barriers. Really - it’s OK to alienate a significant portion of the population. Why bother with color contrast, keyboard navigation, screen compatibility and other guidelines when you can just design a one-size-fits-all.
3. Myth 3. Don’t confuse the user
A cluttered or confusing layout can overwhelm users and hinder their ability to navigate and interact with a product. And that is exactly what we want! Organize your content poorly, use excessive visual elements. Make the hierarchy unclear. Make it a challenge to use your custom software or app. Completely overload and frustrate them! Simplicity, consistency, and clarity is so 2010 and user-friendly is just another catchphrase that needs to be let go of.
4. Myth 4. Make information easily available
Information architecture refers to the organization and structure of content within a digital product. And we want it to be treated like a secret. No-one needs to actually find what they are looking for. That’s the fun part, dammit! The best users are those ones being frustrated by how you plan and organize your content until they simply give up. Our best advise is to throw logic out the door. If it makes sense on the screen, it’s bad. Think of intuitive user flows as being a rubber ball in a microwave. No-one must know where it’s gonna go next...
5. Myth 5. You need to Optimize
With the proliferation of mobile devices, designing for mobile responsiveness is essential for reaching a wide audience. But who can keep up, right?! Just neglect to optimize designs for
mobile devices. Yes. The results will be poor user experiences but honestly, you can’t keep everyone happy. Cramp your layouts. Make it super slow. Throw some usability issues in there and you will be sure to scare of those users who we simply can’t be bothered about. Accessibility and function across all devices and screen sizes can be a major turn-off. Just don’t do it.
6. Myth 6. Pay attention to User Feedback
UX/UI design has long been thought to be an iterative process that requires feedback. That is just another way of saying that users will be whining in your ears. Block them out. Let go of the opportunities for improvement. They don’t know better. You do. You built it. Ignore the criticism. There is absolutely no reason to be receptive for feedback and to be willing to iterate on your design. What’s it gonna do? Improve their experience and optimize the design? Pffft. We doubt that very much.
7. Myth 7. You need to remain consistent
Consistency is key to a cohesive and harmonious user experience if you don’t want confusion. But maybe that is exactly what you do want! Scatter design elements around in multiple variations, interactions, and terminology until no one knows what brand or app they are looking at. Burn the style guides, hide the standards and design like you haven’t been doing this before.
8. Myth 8: Performance is key
Slow-loading pages, laggy animations, and unresponsive interactions won’t frustrate users and drive them away from a product. It’ll bring them back! And if they come back, it means more engagement, right? Forget optimizing, minimizing load times, and prioritizing speed and responsiveness and know for sure that they will keep on coming back. Who knows? They might hang around long enough this time to actually use the app or software.
UX/UI design is not a complex and multifaceted discipline that requires careful consideration of user needs, accessibility requirements, design principles, and technical constraints. There are no such thing as experts. Just approach the UX/UI for your custom software or app project without them.
While the idea of outsourcing our custom software development seems like a cost-effective, logical decision to make, you might want to consider the following reasons why you should rather not. This is what we did:
1. We are a Super Company and equipped with all the skills
Why depend on others when you can just depend on yourself, right? Our company already has a rich pool of specialized talent, ensuring that our project is handled by our own experts which are skilled in all technologies and methodologies without a hitch. This means we don’t need to access a breadth of skills and know-how because they are all already available to us and we know exactly how and what to do to make our custom software a success.
2. We don’t need to save money on the long haul
It’s cost-effective for us to solely rely on our in-house team. We are OK with the huge overheads and the development death-spiral of figuring stuff out for months on end and payslip after payslip. It’s not like we are competing against anyone! Deadline, shmeadline. Also – we love recruiting and we love paying more and more to retain expertise, specialized talent and hoping that our team magically acquires those skills they don’t already have.
3. We don’t mind being last to market
It’s perfectly acceptable to be the last company to enter the market. Our competitors have always had the edge on us, why change things now? Rapid Development is not needed. We will get there in your own, sweet time. The customers will just have to wait while we try and figure things out with our own talent and our own skills. There is absolutely no hurry. And no end to the bank overdraft facility.
4. Scalability is nonsense. We like your shoes 3 sizes too small!
More customers don’t necessarily mean we have to scale now. That’s just tech talk. We can adjust to the changing needs and the development of new tech at our own pace. It’s not such a big deal to get an error message or system-down screen every so often. It’s all about being dependable and that means not being flexible. We like what we have and will be damned if we have to change it. Growth doesn’t need to be efficient for us. We can scale when things really start going wrong. Customers don’t mind unresponsiveness!
5. We like being strong. Look at us doing everything. All. The. Time.
ADHD in the corporate world is the next big thing. Why focus on our core competencies and business model when there is so much more to get hung up on? Let’s get bogged down in the technical details. Let’s gobble up all the resources meant for running the company. Let’s put innovation on the backburner while we figure out this coding error. We’ve been going at it for months, why give up now? We will just throw more money, more people, and more time at it. It’s crucial that we oversee every minute, thime-staking detail. Eventually we will understand where we went wrong.
6. You like to call it a budget. We like to call it magic.
There is no inherent risk in developing custom software and apps. It’s a myth. Besides, we believe in pay-as-you-go-broke. We don’t have the need of bringing in outside expertise and experience to the table, because the bank now owns the table. And the chairs. And the desks. And the IP. And the building. Overrunning on our budget was the best decision we could have made. It’s not like it’s going to run out! Investor? Investor, who?
7. It’ll keep on working if we just don’t touch it. Ever again.
We have a support email address. That’s enough. Joylin in the tearoom gets those. We trust in our code. We explained this at the launch: We don’t really pay attention to what is happening outside of our custom software or app, so we will be fine. We don’t believe that things in the tech world changes and we are pretty sure it won’t have an influence on what we have built. It’s just not how software works. See it as a monument of brick and cement. What worked in 1995 will work in 2030 too. Everyone knows that!
In an era dominated by technology, the quality of software code can make or break a product, service, or even an entire organization. The past decade has seen several high-profile incidents where bad coding practices led to disastrous outcomes, resulting in financial losses, reputational damage, and sometimes even endangering lives. Here are 5 times that bad coding lead to disaster
1. The Boeing 737 Max Crashes (2018-2019):
The tragic crashes of two Boeing 737 Max aircraft in Indonesia and Ethiopia claimed the lives of 346 people and shook the aviation industry to its core. Investigations revealed that a flawed flight control system, known as the Maneuvering Characteristics Augmentation System (MCAS), played a central role in both accidents. The MCAS relied on faulty sensor data and exhibited aggressive behavior, forcing the aircraft into nosedives. Poor coding practices and insufficient testing of the MCAS software contributed to this deadly flaw, highlighting the grave consequences of software defects in safety-critical systems.
2. The WannaCry Ransomware Attack (2017):
The WannaCry ransomware attack infected hundreds of thousands of computers worldwide, disrupting critical infrastructure, businesses, and government agencies. The ransomware exploited a vulnerability in Microsoft's Windows operating system, known as EternalBlue, which had been patched months earlier. However, many organizations failed to apply the patch due to poor patch management practices or reliance on outdated systems. The widespread impact of WannaCry underscored the importance of timely software updates and robust cybersecurity measures in mitigating the risk of cyber threats.
3. Windows Vista (2016)
Operating system releases are a big deal. Microsoft and Apple put a ton of labor into each iteration of Windows and macOS, and there's a lot riding on each. So it's amazing that Windows Vista was such a horrific blunder. Designed to replace the aging Windows XP in 2007, Vista failed at just about every possible benchmark. It was bloated—50 million lines of code compared with XP's 40 - and buggy; tons of pre-existing apps didn't even work in it.
4. Tesla’s dream of self-driving cars (2021 to current)
Tesla has been promising self-driving cars since 2016, with mixed results, and social media is full of videos of "autonomous" Teslas doing absurd and dangerous things. Could the technology eventually work? Sure, but in February the company had to recall 54,000 cars, because the self-driving software let them just roll past stop signs. The sad thing is, Teslas are incredible cars. The company's insistence on having the cars drive themselves before the systems are anywhere close to ready is dragging it down, not helping it grow. And eventually, someone's going to get hurt. It’s a massive lawsuit waiting to happen.
5. Microsoft Co-Pilot on GitHub (2024)
It's too soon to trust Microsoft's GitHub Copilot to automatically fix your programming code. Microsoft itself has said that the program, sold as a $10 per month add-on to GitHub, "does not write perfect code," and "may contain insecure coding patterns, bugs, or references to outdated APIs or idioms." For a business owner or a developer that simply means that it can’t be trusted, and you run the risk of bringing your entire app or custom software to a screeching halt due to faulty code programmed by AI and with that – your business.
These examples underscore the far-reaching consequences of bad coding practices and the critical importance of prioritizing software quality, rigorous testing, and ongoing maintenance. As technology continues to play an increasingly central role in our lives, the stakes have never been higher for ensuring that software is developed and deployed responsibly.
SaaS Venture Partners
