We’ve all been there. In the heat of an IT project – be it greenfield, modernization or just a little “tweak” – users provide you with their requirements. Everything seems to be so clear and obvious that you write up the specifications for the user, and they say it looks great. The project continues, and you repeat this process with more users. When all users have signed off on the paper specifications you begin the development process.
Your deadlines are tight so you are working day and night, pounding through the code. Then, you start to show the software to the users. At this point, your project derails and the wheels fall off. Now you hear:
- “Let me search by this, that, and the other thing.”
- “Move this here and that there.”
- “l need this additional information as well.”
- “I need to do this before I can do that.”
This continues with each user until it feels like a complete rewrite is in order as you missed the plot completely. Your budget is blown; the timeframe is missed and no one is happy.
What went wrong?
In my 30+ years of software development, I’ve discovered that users are visual. Back in the days when dinosaurs roamed the earth and systems were character-based, we didn’t have to worry about user experience. Navigation was pretty simple as the keyboard didn’t allow for much creativity. Get the right data on the screen and press “ENTER” to process. You could get by with your paper based design document. That’s only part of the process today. Without being able to understand the workflow, the navigation along with the data users often misinterpret what they are viewing. There’s a disconnect between translating what’s on paper into how the software will perform in the actual workflow of their job. Users need to see the application in action to fully understand what you are delivering and how it will operate.
What can we do better?
The first step is to admit we have a problem. Step two is to understand that users get a much better feel if you prototype your application. An executable prototype that reacts like a real application can eliminate many of the surprises you get from your users by better managing their expectations. Users get a realistic representation of the application you are going to deliver. This results in much better comprehension by your users with fewer surprises. There are tools out there that do this for you, and many do an excellent job.
The main issue with most prototypes is that what you’ve developed (in the prototype) is a throwaway. You need to start from scratch when you build the actual application.
A rapid prototyping tool like Visual LANSA Framework is an excellent example of a visual prototyping and runtime simulation tool. It will provide the foundation for your application including menus, security, navigation and the plumbing required in every application freeing up your developers to focus on the business requirements. The fact that the prototype is created within the framework itself insures that any design work you have done is retained as you “snap-in” your completed, fully executable program components. This allows the user to better envision the software and see the entire evolution of the application from prototype through a fully function solution. It also allows visibility of new prototypes alongside their fully functional applications as you continue to extend the software. The prototype’s navigation performs exactly like the final application, allowing the user a more complete understanding of the process flow.
A good prototype insures that if you are building a tiny house and users are expecting the Taj Mahal, you discover this long before delivery – when expectations can be leveled and/or designs changed to avoid a nasty surprise to all.
It is impossible to create the perfect application in your first delivery. Therefore, once you have your prototype created your goal is to now deliver your solutions as quickly as possible. You will again receive feedback once the users get hands-on with the real application. This will be your first true requirements feedback based on real business value. This feedback and development loop will drive the continued refinement of your application.
This is why you’ll need to deliver your initial application and the follow-on refinements as quickly as possible in response to the real-world business needs of your users. This kind of user-driven application development will require your developers to be as productive as possible. Remember, there will also be other demands on your development team.
Because you will not be given unlimited resources and change requests will come in for all parts of an application (UI, app logic, database, middleware, etc.), your current developers must be able to wear many hats. To be productive, you can’t rely on specialized skills where one developer works with the database, another develops middleware and yet another builds the UI. You need “full stack” developers who can address every aspect of a development project – not just one or two. Unfortunately, it’s hard to find these types of developers and can be very expensive to employ.
Low-code tools are quickly becoming the new standard for software development to meet these productivity demands. Tools like Visual LANSA will allow you to make your current staff into “full stack” developers. Your developers will be able to react to any change your users throw at you and allow you to utilize your development team at full capacity. This would include rapidly moving portions of your application to a mobile platform, if necessary.
Low-code tools like Visual LANSA and it’s Visual LANSA Framework will allow you to work closely with your users to deliver the best possible solutions meeting your users’ needs in the most timely manner possible.
If you are interested in learning how you can better meet your users’ expectations, check out “LANSA’s Rapid development with our application framework” at LANSA.
