How to Create a Great User Experience in Any Application – Part 1

The most crucial aspect of any application is providing an exceptional user experience. This principle holds true for a wide range of platforms, including Windows, MAC, mobile, web, and even web API’s. As a developer, it’s your responsibility to ensure that your users enjoy using your app and that it enhances their work or personal life. By prioritizing user satisfaction, you can build a loyal following, increase revenue, and secure your job. Ultimately, the success of an application hinges on how well it meets the needs and expectations of its users, and crafting a positive user experience is the cornerstone of achieving that goal.

The Best Programming Course I Attended

Way, way back when I was learning how to be a software engineer, I attended courses at a local community college here in San Diego, California. I have only ever taken two college-level programming courses. The first was one about the Pascal programming language, where I spent most of my time helping others in the class on their projects. The second was the best one and I still use what I learned in that class to this day. That class was called “System Design and Analysis”. This class, where we did not write any code, was just on designing applications based on the customer needs. Everything we did was on paper, and the class project was designing an application for a fictitious fitness gym. I took this class while I was working two jobs and had two toddlers at home!

The class taught me how to design an app from scratch which included gathering requirements from users and then designing (on paper) prototypes of the screens for the app. We worked in teams of three to four people and our final grade was our team presenting to the users (students and teacher in this case) the application we designed to land a contract. I had our team dress in suits and dresses, and we even brought food! After my team’s presentation, we received the grade of A++, which I didn’t even know existed! I guess we would have won the contract.

In my opinion, one of the most critical skills that every software engineer must possess to be successful is the ability to design and architect a solution from scratch. Without this capability, you may find yourself merely writing code all day long without fully understanding the bigger picture. As a result, you could end up being a “code monkey” who implements someone else’s designs without adding any real value to the project. By mastering the art of software architecture, you can create elegant and efficient solutions that meet the specific needs of your users, while also advancing your career as a respected and valuable member of any development team. Regrettably, there seems to be a trend toward skipping critical preparatory work in software development, such as designing and architecting the solution, which inevitably leads to subpar user experiences. There are many reasons for this, including improper implementation of Agile methodologies, excessive pressure to deliver features and bug fixes quickly, high development costs, and more. In my opinion, the best approach is to recognize that coding is just one part of the overall solution and that the majority of the effort should be focused on careful planning, design, and architecture. By taking the time to thoroughly understand the problem and develop a comprehensive solution, we can create software that meets the needs of our users and delivers maximum value. Rushing through these critical steps in favor of rapid development may ultimately do more harm than good, leading to buggy, poorly designed software that fails to satisfy users.

For the rest of this article and in part 2, I will give examples of how I used this class throughout my career.

Ticketing System for a Movie Cinema

One of the earliest applications of my classroom learning occurred during my tenure at a small company with only five employees. I was tasked with developing a ticketing system for Edwards Cinemas, a major movie theater chain in the United States, and despite my relative inexperience at the time, I was appointed as the lead developer. While building the application, I relied heavily on the guidance of the company owner regarding the design of the system. However, I repeatedly requested the opportunity to visit one of the local Edwards locations, observe their current system, and ask questions to gain a deeper understanding of the user’s needs. Unfortunately, the owner refused my requests, insisting that he knew exactly what the client wanted.

After developing a working prototype of the ticketing system for Edwards Cinemas, I continued to insist to the company owner that I needed to visit one of their theaters to observe the system in action and gain valuable feedback from the end users. Eventually, he relented and allowed me to spend several hours at a cinema close to where I live. I set up my computer screen next to the employee responsible for selling tickets and carefully mimicked their actions in my system to ensure that it met their needs and made their job easier.

During the downtime between sales, I engaged in conversation with the employee, asking about their experience with the current system, their likes and dislikes, and any other questions I could think of related to reporting and other features. Through this process, I discovered that the company owner’s assumptions about what the users wanted were incorrect, which resulted in significant rework once I returned to the office.

This experience taught me the importance of interacting directly with end-users and understanding their workflow to create the best possible user experience. I made it a priority to incorporate this approach into my future work and even asked the CEO of my next company if I could spend a day with the app’s users to gain valuable insights. Unfortunately, he refused, which led me to realize that I needed to find a new job. Soon after my departure, the company closed its doors permanently, which only reinforced the importance of putting the user’s needs first in the development process.

Mitchell International

At the start of this chapter, I emphasized that considering your users applies to web-based API projects as well. In the late 2000s, I began working as a Principal Software Engineer at Mitchell International, where I focused on their product called RepairCenter. Mitchell provides software for the automotive industry that assists with collision and medical claims, parts and labor estimates, and glass replacement quotes. After version 1.0, my main task was to create a way for our partners to integrate custom apps into RepairCenter and a web API that would enable them to retrieve and update data in our backend system. I will now elaborate on the API, which was the primary focus of this feature.

Our largest partner, who owns over 300 repair shops in the United States and Canada, requested direct access to our SQL Server databases. We declined for two reasons. Firstly, we were concerned about security, as we did not want anyone but ourselves to have access to our databases. Secondly, we were embarrassed by how poorly our database was designed (by the original software engineer who sold his application to Mitchell). Even I struggled to understand it! Every time someone updated vehicle information, it had to be updated in multiple tables since much of the data was duplicated, and we had no idea why. This made it challenging for new developers to join the team since they often encountered issues when they fixed a bug, only for QA to report that it was resolved in one part of the app but not others due to the duplicated data. It took three years urging Mitchell to hire a database business analyst before they finally did for my team.

I did not want our partners to endure the same difficulties that we had faced, so my primary goal was to cover up the poor design. Consequently, I dedicated myself to figuring out how to do this. Initially, I needed to understand the database better, so I spent a lot of time with the original developer, who lived in New Mexico since nothing was documented (as usual). I created UML models and went back and forth with him until I got it right and was confident that it was easy for any developer to understand. This process took nearly three months. In my experience, taking time to design a solution leads to better outcomes. If you don’t, you will end up repeatedly coding the same thing or simply applying band-aids to conceal the poor design, eventually losing your customers.

For the first version of the API, I invested a lot of time conversing with our most significant partner and their developers to understand what they needed since they would be the first users. My job was to deliver something that was easy for them to understand, use, and meet their data requirements. In addition to the design, I worked on documentation, creating detailed and straightforward documentation and illustrations that Mitchell still has on their website to this day. I devoted considerable time to the documentation since I was the only permanent software engineer on this project. Although I had one other developer to assist me from time to time, I did over 90% of the work. As a result, I did not have the time to handhold all the developers who would be coding against this new API. I haven’t seen documentation for projects like this improve since then, and in my opinion, it is much worse, if it even exists.

I also developed a reusable Microsoft .NET Framework assembly to make coding easier, at least in .NET. This assembly included all the proxy classes (models), methods to call the API, and more. I did all the hard work, and all they had to do was add it as a reference, set a few configuration values, and they could immediately start calling the API! It couldn’t be any simpler than that. I initially created the assembly for myself to make it easier to write a custom app to test and benchmark the API endpoints, and later it was used in the actual RepairCenter product.

When I departed the company, we had 40 partners who were either live or in testing. Our first partners were being tested, and Mitchell was set to receive a 1% cut from each sale generated through their apps. Partners had free access to the API, except for the profit-sharing arrangement. I would like to emphasize that the success of this project was primarily due to the knowledge and skills I gained from the class I took. Prior to writing any code, I spent a significant amount of time in the design phase, which also contributed to the project’s success.

Part Two

There you have two real-world stories on how that one college class on application design has dramatically helped my programming career.  But I haven’t told you the best story that even made me a patented inventor which I am saving for part two of this article. Also, in part two, I will give you some recommendations on how you can get real-world experience in designing solutions that I hope you will use for the rest of your career as a software developer!

How to Create a Great User Experience in Any Application – Part 2

Make sure to read part 2!

Do you have any comments so far? Please make them in the comments section below.