How knowledge becomes a blocker when you design products for end users

If you are the one having a background of working for big companies in the past, having worked on large projects, having met a variety of customers, written 100s of functional, architecture documents, travelled across the globe, having built small and medium sized products, having handled small to medium sized teams, having worked on numerous state-of-the-art technologies,

does it all help when you build a brand new product for end users like you and me?


I feel they block you from seeing the simplicity you need to reach ultimately in your design.


They block you to the extent that your brain constantly brings in ‘complexity’ of extreme nature ultimately making you roll into your comfort zone of what you were always doing. If you are a techie, you think the ‘How’ to solve it rather than what is needed for that end user or who is that end user. If you are a business guy, you weigh everything with money and business models and break even and so on without understanding how beautiful something can be conceptualised which makes life easy in selling.

The end user is that ordinary person who would like to look at things that are ‘cool’. Things that give them some value no matter how big or small. For example, my 5 year old goes on using the ‘Talking tom’ app pushing the cat, rubbing it and seeing the facial changes and the sounds coming out of the cat in the App. This is such a thrill for him. It is not to say you design everything like a game or entertainment, but you got to find those ‘nice’ and ‘beautiful’ things beyond the mundane even if you are designing a spread sheet.

The small things that are haunting have a big effect than the big things that you have no choice but to use. You want to get back to those as often as possible.

This is why I feel you need to completely unwind and become a ‘empty cup’. This is not a button you press and you are degaussed. This takes time and an enormous amount depending on how much assumptions you have built about yourself over time. If they are too many, unwinding becomes that difficult. It may sound like the philosophy of OSHO.

Dropping what you have done and taking a fresh look at the problem in hand, every day, every moment is all that is needed. Constantly questioning your own assumptions and trying to break free and see you are in an unbiased state is often needed. If you continue to do this you will eventually have unwound with a pair of fresh eyes.

s/w product development and the building block analogy

Developing a software product is akin to building a house. You have a plan when you start building the house. With computer models, you can pretty much visualise the entire house, space, things that will be there like sofas or ward robes or others and get a feel for the entire house before you construct. 

Why is it not the same with software? We still have this practice of drafting requirements in English which the author himself would find it hard to read after it is written. 

There are models based on UML as well which may be better than text. There are user interface mock ups which give an idea of the front end. But still the programmers who are essentially the masons and carpenters and plumbers of the code that builds the product has no way to visualise the entire house the way the plan shows. 

You may say that the masons of a real building may not know the entire thing and it is the civil engineer or the architect who has this mental model of the entire building. Agreed. But this is where a big hole is left open in software. Building a wall which forms part of a bigger plan is known up front when a building is constructed. However, in software this is not really true. The reason being the requirements themselves are vague many a time on a document. Further, the design based on UML or other diagrams are not frozen before coding begins. Though the waterfall models strictly mandate this, there is always a overlap of phases and with agile models and go-to-market strategies things have gotten really worsened to the point that you often end up scrapping the whole effort done earlier to begin a brand new build out. And we come out unscathed giving justifications for such acts eventually growing the mistrust on the programmers guild.

The biggest difference I see is, the requirements for a building are easily visualisable. And hence a wall that is done somewhere in one corner of a building is easily visualisable as well. If we ask why requirements for a building are easily visualisable, it is primarily due to the fact that you see houses all around you all the time. People right from when they are kids have a sense of buildings around. They play with building sets, they build castles on the beach sand and we live in them. So the sense of buildings are easily ingrained in us. It is not something like an effort has to be made to bring it into a visual form. Of course, complicated structures, aesthetics and so on may require hard thinking. But a engineer or an architect can do this in his head and bring it in a virtual reality model using a tool that can be seen and visualised easily by others. So it is easy to freeze the needs between the consumer and the producer.

If you take the case of software, the consumer varies in degrees in terms of the knowledge of the domain and may not know what software can or cannot do. Same is the case with the software guy who does not understand the business side to be able to speak that lingo with the consumer. There are nuances in every domain which only the experts in that domain understand. It is mostly a case of people, processes and the way businesses have been going on which is what the software tries to replace in parts or whole. How do you model this like the way you visualise a house?

If we take the different components of a software, each of them may expose interfaces for a consumer. Say, we are designing a software that brings together people in healthcare like patients, doctors, hospitals, diagnostics labs and so on into a platform where they exchange things. Now to solve this, if a graph database was chosen, which exposes APIs that allow the user to add, link , traverse and so on. All of this makes sense for the software guy. But how about the healthcare folks? 

If there is a visual representation of the 'business data' of the health care domain shown to enter a box representing this graph database and the data coming out of it or the ability to see the connected graph of the business information for one or more use cases that is produced as a result of interaction with that box which is the graph db, then everyone involved including the person constructing it will not miss the point. However, this can still be missed by the domain people who do not get what a graph db is or how it helps their case. How do we bring these two people together? 

This is where I feel we can use the analogy of a building itself which is familiar to both the parties and which in parts can be likened to software construction.

What I say here is a sort of convergence of the business domain and the software architecture / design. The software architecture is not done by having components and connections and interactions and flow diagrams independent of the domain experts. The business domain experts can make sense of the flow of the information into the 'user interface' which is the most visible part and be able to see changes in the user interface. 

The underlying parts which result in the computation are all now shown as a person walking in a house from one room to another, from one floor to another and coming out. It is sort of a model of a house with floors and rooms where the data payload is a person who starts somewhere say ground floor in a room which is akin to the component that exposes a REST API and starts going into the different parts of that room say cubicles that does some transformations to the payload which is the person himself. The person's look and feel changes as he walks through cubicles and rooms and floors which are the different layers of the software. The person may grow in size that is akin to the payload growing while traversing a room of a certain layer for example. The person may come out of a cubicle or a floor or a room based on O(n) computations that happen within them. If he takes more time, we know there is a large amount of computation necessary or unnecessary as a next step. 

This kind of visual models like a house, building and people where we are more comfortable to associate with than the flat diagrams with its own notations can often give a quick sense of what is going on for every one right from the business folks to the coder responsible for a module. I some how feel that this can be done with Lego bricks. The only difficult part is the morphing of the person walking along as he visits a room or leaves a floor with the computations or impacts created in that place. Even if there is a 3D model of this in software it looks like a interesting and highly potential software tool that can pretty help to accelerate the way we architect software in the future.