Some insights into the cumbersome traditional development model

A small incident today made me realize why traditional business models can lead to inefficiencies in companies. Here's what happened: We had a requirement to modify an existing client website system. When it reached me, the client had already approved the UI, but based on our conversations, they didn't seem to have any specific requirements for it. I found a very similar template on the market; I could simply purchase the copyright, modify it, and deliver the finished product. The template's design was far superior to the UI design. However, the project manager wouldn't agree, insisting that the client had already approved the UI, so we had to proceed with that design…

Anyone in the outsourcing industry knows that you need to handle the entire process from design and back-and-forth discussions with the client to finalization, then to program development, testing, and release. Each step in this process is crucial, like a chain of interconnected links. This is generally a good approach, but in the market, it can sometimes appear cumbersome. This is because many requirements are quite simple, and clients aren't particularly demanding. Following this process not only limits the client but also, inadvertently, restricts the development process. For example…

Client A wants to build a website, but only knows the necessary sections, color scheme, and other general details. The traditional approach is for the project manager to design the website architecture based on communication with the client, then the UI designer will create the design. After back-and-forth confirmation with the client, the programmers will develop the website, followed by testing and release. This approach presents several problems. First, the client often lacks a clear understanding of the specific UI, leading to confusion during confirmation. Second, the UI design may have flaws during development, hindering the programmers' progress.

So how should this situation be resolved? As we all know, there are already many frameworks and templates available for websites and apps. Often, the work involves piecing together and making minor adjustments. In this case, we could find good website templates on the market, select a few for the client to review, have the client choose a template, and then provide their suggestions for modification. After summarizing these suggestions, the programmers could adjust and further develop the template.

This not only saves on UI design fees and project manager time, but also reduces development costs. Even if the client doesn't like the template, there's no loss; the development process can be resumed normally. A rough estimate and comparison of the development time for both methods is provided:

Of course, the timeframes mentioned above are just estimates, and the actual timeframes will vary depending on the specific circumstances. However, for clients with simple and vague needs, the traditional development model is simply too cumbersome. To put it simply, I just need a bowl to eat from; you can just pick a good one out of the market and put it in a gift box, but you're telling me you have to design, manufacture, and bake it before you can give it to me.

Of course, this fast-track model isn't suitable for all clients. For most non-technical, hardcore clients, it's indeed very convenient, saving them money and time for the development team. Ultimately, the best approach depends on the specific client.