There are many myths about the development of UI-centric software. For example, some people believe that there is no need for more changes if you create a prototype with precise requirements. Others think that it's better to wait several months before launching an ecommerce system so that they can be sure everything is perfect. In this post, we will outline some common mistakes and how to avoid them when developing your own ecommerce website or custom application!
The Problematic Development of UI-Centric Software
The date is one of the first pieces of data for each new project. The date is chosen for a solid business reason: the trade show, conference, seasonal event, or funding factor. It's crucial.
What else is essential for the project where the user experience is critical? E-commerce shop, for example. That's correct! The design has commercial value. Bad design will harm conversions and retention rates; thus, it has a business worth.
Businesses put all their effort into getting the best design they can, and only when the design is ready and perfect, they go to developers and ask them to build out their designed system. This is known as the Big Design Upfront method, which is also referred to as BDUF. However, because most of the time and money was invested in designing, the deadline is approaching swiftly.
Even if developers are brave enough to state that achieving a deadline is out of the question, someone will volunteer to "give it a go." But, of course, trying will not assist, and the entire project will fail.
I've seen the same scenario repeatedly throughout my software development career.
Design-first approach is considered harmful
The practice of obtaining detailed and specified requirements endures on and on. However, it is ineffective. According to the CHAOS study, just 11% of Waterfall projects are successful. Agile projects that do not have well-defined requirements are considerably more likely to succeed.
The most significant issue is that a design does not include all the requirements. It provides all the constraints that upfront requirements do, but it does not give any information about how the system should function. Therefore, there must be an additional analysis stage if we wish to pursue Waterfall. Unfortunately, it's too frequent to proceed with design without addressing functional and non-functional needs.
Another problem is that designers should not be aware of architectural constraints or implementation complexity. For example, adding just one button might take several minutes for the designer, resulting in a month's worth of effort in development.
There may be fast and straightforward solutions to issues from a development standpoint, but once an interface is established, it might conflict with the best solution. In this example, developers will come up with a less optimal solution or argue about the design. Both situations result in more time and money being spent.
Time is not a renewable resource
It's not good to be in a position where your development bills are constantly going up, but money may still be made and time only spent. Late software becomes obsolete if a company picks a date for legitimate reasons, like a trade show. Not perfect software or software with just a few essential features will have worth.
In most cases, time is critical to outpace competitors. Competitors will acquire as much market share as they want if they release products earlier. In this instance, it is not about whether the product is perfect; instead, the first released product wins.
Assume that a firm releases its product three months later than anticipated. If it was on time, it could produce $1k MRR in the first month, $2k in the second, and so forth. Despite that, it made just $1k at the end of the third month because of the delay. However, the cost of delay is more than $5,000; each month, the actual MRR will be lower by $3k. The accumulation of delay price may be high, and it will grow over time. When a problem arises, nobody can stop the process.
That's the goal of any business: to bring something new to the market that is simple and functional, rather than waiting for the ideal design.
You can't always get what you want
Another disadvantage to upfront design is that software development is always a tradeoff. If each firm could acquire everything they want, when starting a project, the product would have no worth since everyone would get the same thing.
You can't always get what you want but if you try sometimes, well, you just might find what you need! - The Rolling Stones
Should developers assume that each component on the ideal design has the same importance and that all parts are necessary for business? What should they give up to fit the budget or timeline if yes? It might be non-functional criteria such as quality, maintainability, performance, or security. Are they less important than the interface's appearance? I don't think so, but we should consider them to find a balance instead of expanding the interface scope.
Functional requirements can also be affected by this. A design does not dictate how the system should function, so during further analysis; developers may suggest less complex behaviors or eliminate the needs of specific users, such as admins.
We may only achieve the correct balance if we concentrate on what is essential in each of these fields: how it works and looks.
We don't know what users want
A primary worry: "Our product is one-of-a-kind, and we must prepare all necessary information ahead of time." This worry isn't linked to the complexity of the industry or the product.
Everyone wants to control the entire process from start to finish, ultimately. We think that more study, analysis, and precise instructions will lead to a superior product. Unfortunately, this method provides only an Illusion of control. We create systems for people, and we can't possibly anticipate their behavior. Because users will act differently than we expected, many preconceptions will be wrong.
Is there a difference between products that must be weighed carefully before development and others that should be developed iteratively? The United States National Defense Authorization Act for 2010, section 804, titled "Implementing New Acquisition Process for Information Technology Systems," states:
early and continual involvement of the user
multiple, rapidly executed increments or releases of capability
early, successive prototyping to support evolutionary approach
a modular, open-system approach
Even military software is created based on fast user feedback rather than fixed upfront demands. Is e-commerce software, for example, riskier than any military program? Certainly not.
We cannot predict the future
Finally, even correct and fully finished requirements are only valid when produced. Within a few months or sooner, the environment, business demands, competitors, user demands, and so on will change. Nobody knows how.
If the reasons for adopting a new system change, we must also modify the software requirements. Some developers refuse to make any modifications during development, while others negotiate change requests. Both strategies throw a wrench in the value chain. In the first scenario, a company does not obtain the software it needs and receives software it does not require. Another example is software that businesses require but needs twice as much effort to describe and redefine requirements.
The problem will be solved when you engage in a continual process of defining business demands. It implies that design should not be completed in the beginning.
Focus on what user can do
So, what is the best first step? We shouldn't be concerned about how it should appear; instead, we should consider how it should function. We create software for people to use, so concentrate on what they may do with it. "User can add a product to the shopping basket" is referred to as a "user story." Make a list of user stories based on the types of users you're dealing with.
It's all about the value, not the specifics, with this method. It provides a good enough understanding of how software should work without telling you how to do it. Furthermore, you may pick what to do next and consider how to accomplish it only before the creation of the user story begins.
What about the User Interface? The story may be improved by including further information in a basic wireframe. The final design should be created for each user story at the beginning of development. Create your design gradually, as well as the software.
What about the big picture? If we progress one small portion at a time, how can we ensure that the entire application appears as a single system? Creating a UI library is a wonderful notion. The same typography, headers, buttons, selects and dropdowns, and grids may be found in various application sections. Components based on similar ideas can be readily transformed into reusable components. Once a new element appears in the wireframe, it's time to create the UI component. Then, you'll be able to utilize these elements without needing a designer as you accumulate more and more of them.
When we create anything, whether it's a website or software, we assume it will be done in a specific manner. The objective is to validate these preconceptions as soon as possible to make sound judgments and get the most out of the software.
It's important to hear what your users have to say, as it's the only way to confirm preconceptions. However, you can obtain a lot of information in various ways: metrics, polls, interviews, and so on. Google Analytics is one of the simplest methods for observing user behavior and determining what to do next.
Embrace the change
To summarize, the proper development method includes acceptance of change. In order to embrace change during the software development process, it's essential to be prepared for it. This means that requirements and designs should not be finalized upfront, as they are likely to change as the project progresses. Furthermore, user feedback should be welcomed and incorporated into the development process to ensure that the end product is as desired by the users. Lastly, it's essential to be flexible and accept that changes will occur during the development process to avoid any roadblocks.
Project Estimating: What You Need to Know
- December 23, 2021