Before one starts to layout the blue print design for a new software application, there are a few hurdles that must be overcome in order for me to create a truly innovative and accurate product solution. The primary way that I achieve this goal is by following a set of steps that help me and my team mates focus on the actual problem that we wish to solve.

More often that not “product customers” are completely unaware of the complexities involved in creating a software application and wrongly assume that the software application must include a massive amount of features and functions in order to be a complete and robust solution. To help focus the stakeholders on the task at hand I use what I refer to as the “five phase” thinking process to help narrow down and focus the discussion. This is done to ensure that we don’t go off course in our discussions and planning.

As simple and straight forward as this may seem, people have a tendency to fully understand the thought process behind the concept in theory. When they themselves are charged with the task of building a software solution they cast reason into the wind and go function crazy and suffer deeply from feature greed, wrongly assuming that more is better.

The importance of lean agile development and quick time to market is paramount. Customers, team mates and sales people rarely grasp the problems that over development create until we have moved way ahead in the development process and costs and complexity begin to mount.

Linear Thinking vs. Lateral Thinking

Before we discuss the best way to tackle problem solving, first I’ll provide a brief overview of the two main thought process methods that human beings have developed to solve problems and create solutions for them. A persons primary method of understanding something is by analysing data that is conveyed to them by their senses. This means that we can only understand things “around us” as they present themselves “before us” in our field of view.

So, if some information is distorted or missing from our view we must compensate for it in order to create a full and complete picture. Therefore, we are constantly struggling to understand what is going on around us. I will now briefly describe the two main through process methods that can be utilised by problem solvers to ascertain optimal results when attempting to create a good application design.

Linear Thinking

Linear thinking for problem solving means putting things in order of the user experience flow. The process moves forward in a sequential manner, or as the most efficient way to get from one point to another in a straight line.

Linear thinking consists of using a conscious approach and rational assessment in order to take in information or make decisions.

Pros – Linear thinkers are good in fields related to logic, mathematics and science. They are good in subjects that work in the realm of cause and effect.

Cons – Using a linear thinking method for analysing a situation does not take into account that, there can be multiple points of entry when performing a specific task or function. You simply don’t always know where things begin and where they will end.

Lateral Thinking

Lateral thinking is solving problems by implementing indirect and creative approaches to a specific problem. This is achieved by using reasoning that is not immediately obvious and involving ideas that may not be obtainable by using only traditional step-by-step logic. For example, building a thin user story in order to perform a task and then exposing it to the end user. The user then plays with the new feature or function and provides feedback based on the users experience. This sometimes provides enhancements or minor changes to the original design requirements. This process bounces back and forth between phases until the desired result is achieved.

Lateral thinking involves using customer feedback, intuition, risk taking, imaginative through, unconscious and subconscious processes.

These understandings can be observed by the designer when watching the user play with a specific application feature or function.

Pros –Lateral thinkers are good at grasping abstract subjects, like social sciences. They also often excel in the arts like music, painting and invention.

Cons –Using the lateral thinking process does not base itself on maths, science or pure logic. It is not always good for perceiving things that have a definite cause and effect.

Fusion Thinking

Software application design employs elements from both the pure logic and mathematical spheres, as well as artistic, aesthetic, human behaviour and experience spheres of reality. I try to fuse both linear and lateral thinking processes into my design methodology. I find that mixing them both is the best way to achieve optimal results in the shortest time.

In the following section, I provide my personal check list that I use to create my application functional architecture and user experience designs for software application designs.

The Five Phase Thinking and Planning Process

The first part of the thinking process is related to defining the “Problem” aspect of an application design. The next step is ascertaining the main limitations associated with the current method for performing target task by answering the “What, Where, Which and How” questions about the problem that is the focus of the project.

Phase 1 – Understanding the Problem – What, Where, Which and How

So, we must start by asking the following questions.Whatis the problem that the software application is tasked with solving.Whereare the main stress point located in dependency chain that we have to address to provide a solution for the outlined problem.Whichare the minimal sets of technologies and functionalities required to produce a viable solution to the problem, and finally…Howcan the solution to the problem be most effectively implemented quickly and cheaply to solve the problem.

I believe that creating a lean solution as quickly as possible to start with is always the best plan of attack. This is because application customers rarely if ever know what they really need.

Phase 2 – Define the Problem in a Brief

Once the main problem has been defined it should be summed up in a product problem brief. Start by writing the problem in the form of a single sentence statement. Keeping it brief will help you focus the problem definition. This is not the time to speak in broad terms, but rather to be very specific. Then, all stakeholders should revise the product problem brief and reflect upon it. I can’t stress the importance of this crucial stage in defining the applications product objective. It is imperative that the problem that requires solving be fully understood and clearly defined. Failure to do so will create shock waves further down the path if this stage is rushed through.

At the end of the problem brief you should write an expanded problem definition that includes your product. Then place your application in the context of its industry food chain, highlighting how it can solve the problem.

Phase 3 – Defining the Solution to the Problem

The next step is to deep dive into the problem and create the framework for a detailed solution to the problem. It is at this stage that it is time to expand the circle of stakeholders to include a broader group of idea contributors. I try to involve a single representative from each discipline form both the product industry as well as a member from each development link in the software production chain. I personally find that keeping this group under 6-8 people is the golden number of participants. Anymore than that number of contributors tends to create unfocused and convoluted input that doesn’t produce the desired result. It also makes it far more painful during the meetings themselves.

It is at this stage that we can begin to discuss and define actual product functionality and specific features.

Phase 4 – Create a Lean Product Prototype and Perform Test Cycles

It’s now time to select some of the more central and important functions and features of the application and to build a lean simple prototype of the application. If the application was focused around helping customers find cheap parking in a busy city for example. Then you might want to first build a mechanism that can detect parking stations and check for empty space availability as a start.

This is the stage that the conflicts occur, as you begin to develop your first prototype certain stakeholders such as developers, sales people and some in-house end users will become excited and try to convince you to develop more that just the shortest path between the two points. This is a mistake, as you should now stop once you’ve built the “mini app” and perform your first technology and implementation evaluation test. Sometimes simpler is better and complex and intricate solutions are not what the customer is looking for. Nobody said that building the ultimate next generation solution should be complex.

If the customer accepts the prototype, then refine the technology and move on to the next problem. If there is something missing from the initial prototype, refine the design and perform the testing cycle again until satisfaction is achieved.

Phase 5 – Refine the Design and Complete the Application

Once the initial prototype is complete it’s now time to complete the product using the best solutions identified during the prototyping and testing phase. But, because this is an iteration based process there still might be addition tweaks, additions and refinements to perform on the final application product deliverable because of user feedback and last minute input and revelations.

The product designers and QA testers should now perform rigorous acceptance tests to ensure that the complete product is using the best solutions identified during the prototyping and testing phase.

Don’t forget UI persistency when clicking between views, interface latency and the UI component loading sequence. The application must also be sexy and smooth and snappy when using it. People love snappy…

Putting the Product Design into Perspective

Before you even start to think about the “product” that you want to build. Before you define the problem and a solution, make sure that you understand the following aspects of your products industry.

The products market, its size, age range, the number of potential customers (units) that can be sold. Dedicate most of your thought towards market competitors, market penetration, collaboration with existing market players. Perform a thorough investigation into existing technologies that your product solution can leverage in order to build the first version. Ask the right questions such as, do existing technologies and logic engines exist that can be used as a base starting point, rather than developing them all from scratch. The majority of your product proposal document should be discussing these issues.

The most common mistake that people make is over define the product functionality and just mention the market aspect of the product as a foot note at the end of the product definition document.

Market Penetration Strategy

By over defining the product features and functionality at the beginning, you throw into the wind all of what I have discussed in this article and commit the first cardinal sin of product design. By wrongly assuming way too much about your products final version and the real customer usage of your future product, you waste valuable time and resources. This is how almost all start-ups fail, spending way too much time and money on product development and not any time or effort on a sound and thoroughly researched market penetration strategy.

There are companies that fail to address this issue at all and leave the target market as an after thought. Once they have spent all their money they stare at the wall in wonder, not even able to admit that they are to blame for the products failure…..

Conclusion

The application design process is dynamic and fluid. It involves many different user view points and stakeholders. The first phases of this process are linear in nature, where one stage naturally flows into the next. The next phases in this process are lateral non-linear processes that can often occur in parallel and require a flexible opened minded approach to achieve optimal results. Other phases in the design process occur in repetitive loops and require the stakeholders to react responsively to the customer feedback and input without applying a layer of their own logic on top of the design, regardless of their professional understanding.

Most of all don’t forget that this process is supposed to be fun and exciting. So, get out there and start creating…