Design thinking is a popular way to design solutions. The main theme is to evolve a design that is focused on solving human needs and there is an extra focus on dialog with prospective users and brainstorming to get it right. For an introduction to Design Thinking, check out internet articles such as this MIT Sloan article.

Design thinking is well applicable to software product design too. When that happens, the context of the dialogs and brainstorming are the software requirements — possibly the various use scenarios and the screen designs. However, many software products are deep in their functionality. In addition to how the product looks, how it works is also important — some times more important. The Xsemble flow diagram would like to humbly pitch in as the diagrammatic representation of the working of the product.

Why Xsemble Flow Diagram?

The Xsemble flow diagram has the following features:

1. They are easy to understand – Someone who can read flowcharts will be able to understand an Xsemble flow diagram. It takes just a little background on the different shapes of nodes and what they represent, just like one has to understand the meaning of various shapes in a flowchart.
2. They are quick to create – Admittedly, drawing an Xsemble flow diagram needs a little more work than in a simple minded draw tool. This is because you need to define the components before using them as the basis of nodes. But in spite of this marginal overhead, in practice, creating the diagram is remarkably fast. Thinking through the component definitions helps in bringing clarity to one’s thinking.
3. They capture more information – An Xsemble flow diagram contains both the control flow and the data flow of the application, and hence it is more expressive. If one wants to start quick with a high level picture, one can omit the data flow and/or hide implementation details in subproject nodes.
4. They are ready to roll – Beyond being the visual representation, the Xsemble flow diagram is the basis of creating an application. Glue code gets generated according to the flow diagram, which means that it is guaranteed that the actual application will follow the flow defined in the diagram.

We believe that the last two points would make it attractive to be used in design thinking. This is because it gives you a confidence that the design that is used in the discussion with the users / brainstorming is the same that will get implemented.

Xsemble Aided Design Thinking Process

The flowchart below shows how a design thinking project aimed towards developing a new product might run.

Here is the explanation of the individual steps:

• Survey1: This could be the survey to understand the key concerns of the users and enroll some of them as participants in the further process. This participation could be in exchange of something tangible like a good discount on the final product or partnership in the process.
• M1 (Milestone 1): This milestone represents that you have signed in adequate number of end user representatives. You may have possibly MoU documents signed with their organizations.
• Comms Set Up: You establish modes of communications and set up the communication mechanisms with the end user representatives. It is an important step since communication is very important to the whole process.
• SDLC 3 Steps: This is the core part of application of the design thinking principles — namely empathize, define, ideate, prototype and test. Executing just 3 steps in the enhanced software development process can give us maximum returns on our time investment. The artifacts created through them can be used as the basis of discussions and brainstorming with the end user representatives:
  • The requirements activity captures the application requirements.
  • The wireframing activity creates rough screen designs with minimum effort.
  • The Xsemble design activity creates the Xsemble flow diagram (capturing the working of the application).
• M2 (Milestone 2): Here you have a pretty good idea of what will be created and also have the representative artifacts ready to show for it. You can also have a very good estimate of development effort required, as you have a crisp WBS in terms of components, as mentioned under the Progress Report, Kanban chart section of our earlier blog post. Your collaboration with the end user representatives is almost over at this stage.
• Survey 2:  Touch base with the wider audience to gauge the acceptance. Try to get pre-orders to the product.
• Feasibility: The survey response will help you evaluate the feasibility of creating the software on economic terms. This is the acid test of whether to go ahead. In case it is a No Go decision, you can scrap the project without having invested much effort (and zero development effort) in it.
• M3 (Milestone 3): At this stage, the feasibility is proven without doubt and you are all set to start development. Ideally, you have concrete pre-orders in hand from customers.
• SDLC All Remaining Steps: Here you whole-heartedly invest all your effort in executing all the steps of the enhanced SDLC barring the 3 that are already complete. The development activity being that of developing individual components, it is easy to scale up / down the development team, and also have a good visibility of the progress to the management.
• User Acceptance Testing: Your product is ready to be field tested. Do that with the help of the customers who have given orders and/or the user representatives who contributed to the idea stage.
• M4 (Milestone 4): Your product is ready and field tested. This milestone marks the product release to the world.
• Sell: Sell your product and earn a lot of profit. Feel free to repeat this process for product enhancements and come out with different revisions. The Xsemble design will get modified as you make changes to the product, and stay up-to-date with it.

Conclusion

The Xsemble process is a natural match to the Design Thinking way of developing software products. Especially the Xsemble flow diagram can work very well as the context for dialogs and brainstorming, in addition to the usual requirements and UI screens. It is easy to create, and serves to further reduce risk of misalignment of the product implementation from the needs of the end user.

These points are further elaborated in this article with an example flowchart for a software product development.

Featured image credit: Image by Arek Socha from Pixabay