This is a longer post so if you don’t have time right now, save it to a reading list and then make yourself comfortable with a cup of tea or coffee, sit back and enjoy.
Introduction
I’ve made this mistake many times. I had started to write an application before I had any idea of how it will look and what it will do. Either I was too impatient to sit down and write a specification or make a mockup or my clients did not know exactly.
That way or another, I started to write as soon as I had a faint idea of the app or its module and, of course, I have stopped when the idea was implemented. Then I thought it over. The original indefinite concept became a bit cleaner, and I started to think about the next part or module.
Let’s write something and we’ll see what it will do later.
Inconceivably, this “workflow” did work for me, even if the application, I had been developing, was a bigger one. Well, “did work” means that in the end, I had the application the customer had been satisfied with. However, it also means that I had to suffer through the difficulties and limitations of this method of development.
User’s Product
The main purpose of an application is to help its end users to turn out their intended results, products.
For an application to make sense, to have a right to live in the hands of users for their good and not to be only a hobby horse of developers or a waste of time and money, we must find out and fully understand what the results, products of the users are.
For example, if a driver wants to arrive safely at a known destination without delays then navigation application must help him to get there. If the app leads him elsewhere, or if it chooses too long or a dangerous route, then it is obviously useless.
It is not only about ”that” an app helps the user, but it is also about ”how” it helps.
I remember the time when iPhone was too young and the quality applications had just started to find their way to App Store. I purchased a navigation application back then. It seemed that it was able to lead me from my home to the city quite fine, but I couldn’t listen to the music from the iPhone to my car audio via Bluetooth that I was used to.
So it did help me with the navigation, but it deprived me of music. ”That” worked, ”how” did not. Then, on the way back home, it did lead me to a one-way road but opposite direction! Now also ”that” failed so I returned it, got money back and purchased a navigation from another vendor with music, working correctly and many more interesting features. For example, the location of (fixed) speed traps so that I could slow down to avoid fines for speeding — another problem solved.
Problems with Product
If the potential user of our app can produce the results in abundant quantity and quality within the desired timeframe, then there is a high risk that he does not need the application in the first place.
There must be a problem, an area where the application can help. Issuing of invoice takes too long because we have to fill the contractor address, bank data and names of items manually over and over, there are too many invoices to keep a track of, so that the (potential) user is losing money by not exacting due and overdue invoices, he loses track of the promises to the existing or potential customers, misses appointments, to name a few. (Computer games also solve problems, but it is a different story.)
Well, the problem must be solvable by the computer software. No software is about to fix a flat tire, or not yet and not without an “inflating” hardware.
Now that we have a problem, that seems to be solvable or can be alleviated by a computer software we are ready to make the decision: Let’s develop a program, an application, the solution. Nothing against, it’s always good to have solutions to problems. However, somewhere in this phase lies the first deadly catch of not really knowing the end product or the problems with producing it.
Writing a program that solves a non-existent problem is stupid waste of time, money, and other resources and although the futility of it seems to be obvious, such applications or features of them, are produced and sold out in the wild. Take a deeper look at a big word processor, for example, and you will find thousands of solutions to the problems that real writers do not have.
The seemingly lighter, but nevertheless equally deadly, is not knowing major aspects or size of the problem. In the previous example of navigation, one aspect the developers did not think of, was to support music while navigating. Another missing aspect could be not to inform the driver of the current speed, estimated arrival time or duration left. You wouldn’t want a navigation software without them, would you?
Possibly the best approach is to analyze actions the end user currently needs to perform in the area we want to solve and in the direction of attainment of his product. Then we use all our imagination and creativity to conceive and visualize how his life improves when he will be using the planned application. How the app helps him to produce more, faster, better quality, how to give him more (or less as less is sometimes more) information he needs for the right decisions, etc.
Is there anything in what is he doing that could be automated so that we would save a tedious work? Is there anything the user is not doing, but he should? Is he forgetting something we can remind him of, or is an important action buried under a pile of trifles? What is the sequence of actions? Is it correct? Anything missing or extra? What data he works with and what are the relations among them? What is the size of data, how many items? Tens, thousands, millions, more?
Size of data can change the application design considerably. I remember when I developed an invoicing application for a client and I wanted to show unpaid invoices in a combo. The detail invoice form would show after making a selection in the combo. It looked good and worked well until I was told that the client issues about 30 invoices a day that are usually due in 14–30 days. Hence, quite normally, the combo would have 900–1000 items. That was just too much. I have finally implemented an invoice grid where he could filter out paid, due, overdue and other invoices.
If I knew the quantity before I started to code I wouldn’t waste time with the combo and the detailed form.
Keep digging into the area the application is going to cover until you achieve a deep understanding — that is usually accompanied by very pleasant feelings of confidence and very often with many ideas on what and how the app should do.
Now it is time to write the description of the problems the app is going to help with, what it is all about, the end product of using the application. Be as concise as you can, however, not at the cost of omitting anything vital.
Structure
Now that we have understood the problem and have the clear idea of what the application is going to do, we have to take the problem apart, break it down into smaller parts, modules, divisions, components, functional or building blocks, elements; you name it.
Structure is always subordinate to function. Therefore, we cannot start here by putting together the building blocks we think could comprise the app and build the app from down up. That’s upside down. The correct order is: Determine the purpose of the app — the problem it solves and only then decide upon the structure.
If we want to describe a structure, we must describe each component as to its function, what it does and what it does not do, and we also need relations and communication lines among the components.
We don’t chop the application into too small pieces in this phase. Individual fields of a form or even the form itself are of no interest yet. What we need to define now are bigger blocks.
For example, if we would be designing an invoicing software we would probably need a database of customers, a product catalog so that we wouldn’t need to type items every time but we could select from the catalog, we need some invoice form or templates, a PDF generator, a system to follow up unpaid and overdue invoices, etc.
We also need to describe the interactions of modules, the data and control flows, and the sequences of actions.
So we need to create a list of modules describing functions and block diagrams, flowcharts showing actions, relations and communications.
You see, I’m not talking about the architecture yet. Whether we are going to use MVC, MVVM or a combination of them or something entirely different. It is too premature even to think about it at this point. We are now playing at the borderline of function and structure that is at the much higher echelon than the architecture. We just do not think in terms of models, stores, views, controllers and data bindings yet. We’re designers now, let this stuff to programmers.
Mockup
A mockup is a collection of major screens that look like the real application screens shall look and they are even active. That means clicking on a button on one screen leads us to another screen, the actions of the user seem real.
There are some applications available that we can use to design our screens, or wireframes at least, and interactions among them. Even presentation applications such as Keynote or Powerpoint can be used for this purpose.
We need a mockup to visualize the design we prepared in the previous steps. Each building block of the structure is most likely going to have one or more screens that interact with the user. Data is presented in an appropriate form; user is asked to provide some data, then the workflow continues to the next screen, next and next, then back, home screen, etc.
The watchwords here are: beautiful, simple and straightforward.
Esthetics has a special quality: It is able to communicate directly to the person, to the best he is. Beauty is one of the main entrances to acceptance of the application by users. If all other aspects are in, but the application is ugly, it does not find enough customers easily. Put in some esthetics and you don’t need that much effort.
The utmost mastership of designers and programmers lies in their ability to hide the complexity of the application behind a simple user interface and simple and straightforward workflows, still keeping the complex options and functions available for advanced users. Ideally, users glance over a screen and they understand immediately what is it for, what to do with it and which button to click. No manual needed, self-explanatory, although I admit that a written guide is necessary in some cases.
Third most important factor is easy and logical workflow without extra clicks or detours. I use to say that one click less is worth $10,000 — sure, 10,000 is an arbitrary constant, yet, one extra click can be very costly. If it only takes 2 seconds, it is needed only 10 times a day and 1,000 users need to click then it is 120 hrs a month or 1,440 hrs a year. And if one hour only costs $50, then we get the loss of $72,000 annually. We can hire one full-time employee for this price.
Hence, time, effort and our wits invested into saving that one click shall pay back many times. You can ignore the application code optimization, but never skimp on streamlining of the application workflow and user interface.
Conclusion
Never start to write the first line of an application before you:
- understand the end user’s product
- know which problems will be solved by the application
- describe the structure and draw the flowcharts
- create and optimize a user interface mockup
Well, there is one exception. If you would design an application to take a spaceship to Mars you could start to program all those intricate equations necessary to calculate the trajectory in advance. There is no UI to them anyway and they come as a black box somewhere in a flowchart.
- Ext, Angular, React, and Vue - 27. June 2019
- The Site Resurgence - 11. February 2018
- Configuring ViewModel Hierarchy - 19. June 2015