User Stories as a Negotiation Between Problems and Solutions

Building architectural design provides a blueprint for software development

Agile software development radically changed the nature of software creation. One of the hallmarks of agile is the creation of small increments of end user functionality as opposed to creating software in one or few large portions. Agile also included many other innovations such as starting with tests as opposed to creating tests after construction and creating self managed teams as opposed to traditional command and control. There was an earlier, parallel movement in understanding the design and creation of mechanical objects, including building architecture, product design and graphic communication. One of the major contributors to that movement was Bryan Lawson. In Lawson’s book, ‘How Designers Think’, he explains the characteristics of design problems, solutions and the process. In this post I will describe Lawson’s ideas on design problems, solutions, and the problem solving process. Understanding these ideas on the fundamental nature of problems and solutions will further benefit the power of agile user stories.


  1. The iterations in agile and the sequential phases of waterfall development are a view of the entire development process. In this article the focus is on the work of an individual developer implementing a user story. The reference to phases in this article is the way an individual developer addresses a user story.
  2. Agile has made major contributions to collaboration and group dynamics. The ideas presented in this article are not in conflict with the ideas about team work and collaboration.
  3. The design of a building includes the aspects of construction. In software, design is a separate and often optional activity. The use of the word ‘design’ in this article includes all aspects of designing and implementing a user story. For this article, let’s assume there is no separate UX designer.

Problems vs. Solutions

Most people think of problems and solutions as distinct. You solve a crossword puzzle or a jigsaw puzzle. A plumber fixes the leaking pipe. You replace the fused light bulb. Software development has a long tradition of solving problems. Software algorithms are mathematical/logical steps to solve problems. Common algorithms include sorting a list of numbers or searching a list for a value. Google search is based on a celebrated algorithm[1].

Design problems and solutions are different. When you design a library, is the library the problem or the solution? Does the client specify how the library should look like? In that case is he specifying the problem or the solution? In a student problem of designing a library, the student starts by asking about the broader purpose of the project. Even when a client has preconceived ideas about a solution, designers may want to understand the broader goals. A supportive client will participate in the process rather than be fixated on his solution.

In agile software development, there is similar thinking of specifying user stories as a customer need rather than a solution, i.e., what will be built. However, I find software engineers still confused between a traditional specification and a user story.

Solutions improve problem understanding and create new problems

In the past, architectural industry associations conceived of architectural design as a set of sequential phases — assimilation, general study, development and communication. However, in reality, often designers cannot gather information until they have studied the problem. Detailed designs often expose problems in the designers understanding of the problem. As a result, the process actually requires designers to loop back to earlier stages. Consequently, a more realistic process would have loops from the later stages to each of the earlier stages. A critical principle is that only when you develop a solution, do you realize the flaws in your understanding of the problem. Solutions may also result in new problems. As a consequence, the relative priorities and the objectives of your design may keep evolving throughout the design process (user story).

Figure 1: The reality of loops in design phases (Adapted from ‘How Designers Think’)

Problems are subjective

One of the iconic statements about the software development process is, ‘Quality is value to some person’[4]. The understanding is that the value that people derive from software solutions is subjective. However, the interpretation of problems themselves may be subjective. Lawson asserts that industrial designers may focus more on the way ‘buffet cars are laid out’ in a train, while operations researchers may focus on ‘timetabling and scheduling of services’ and graphic designers on ‘how the food is marketed’. In software teams you can see differences in engineers with expertise in databases as opposed to systems developers, or engineers who work in IT compared to those who develop software products.

Thinking approaches which redefine the problem

Lawson (quoting Eberhard[5]) describes a partly humorous account of an architect designing a door knob, questioning whether the door really needs a door knob to open. This results in questioning why they need a door in the first place.

Another type of thinking, results in a student designing a library[6], just to become immersed in understanding how libraries work in excruciating detail. There are probably many other ways in which you can think about problems which can prolong the problem definition. For example, in software instead of creating a user login you may decide to use the credentials (username and password) from a social media site like Twitter. Alternatively, you may decide that you really need a way to manage the user’s identity rather than just a credential.

Developers should contribute to problems as much as clients

Given the recursive nature of problems and solutions, you shouldn’t expect static definitions of problems with fixed boundaries. Since solutions result in clarifying problems as well as creating new problems, as developers create solutions, it should be expected that they make contributions to problems. Lawson describes the architect Michael Wilford’s[7] view of the client as ‘(not just) the source of the brief but a creative partner in the process.’ Lawson quotes the architect Eva Jiricna going a step further, ‘the worst client is the person who tells you to just get on with it and give me the final product’.

The role of the user has got a lot of attention in agile development. However, sometimes developers mistake this to mean that the user will provide a static problem definition and later validate it.

Solutions always involve compromise

It is common in design, for different needs to compete with each other. Lawson gives an example of motorists who want better acceleration as well as good fuel consumption.

In software, providing detailed logs may compete with system performance. There are certain higher level attributes which always compete with others, such as cost, performance and development time. High performance always competes with cost.

A common software attribute which is often overlooked and can be overbearing is security. As a result of these competing needs, it is difficult to create a solution which is optimal. There are infinite solutions if you can think of them. Given the varying needs of stakeholders and their subjective interpretation, it is likely that some will be more satisfied than others.

Design solutions are always holistic

When you consider the various attributes of a design such as performance, usability, security, it is difficult to map them to specific parts of the design which satisfy these attributes. ‘Designs are integrated holistic responses to a number of problems.’ Designs often satisfy multiple attributes at the same time.

Problem solving is a non-linear, endless process

Given the subjectivity of problems and solutions, and the different ways to think about problems, there is no ‘single infallible approach’ to solving problems. You can always think about new ways of thinking about a problem. You can always find new problems with your solution and further improve your solution. This implies that there is no end to the process and that there are infinite possible solutions.

Problems, solutions and the problem solving process have many different aspects. The most important learning is that instead of thinking of a linear path from problems to solutions, problems and solutions should be thought of as a negotiation. Mechanical artifacts such as buildings or industrial products cannot be created using the approach of agile user stories. Understanding the nature of problems and solutions used by architects and designers coupled with the concept of user stories can result in creating very powerful software designs.


[1] Lawson, B. R., (2005), How Designers Think, Fourth Edition

[2] Page Rank Algorithm, Wikipedia,

[3] Figure 1, A map of the design process according to the RIBA plan of work, Page 35, Lawson, B. R., (2005), How Designers Think, Fourth Edition

[4] Weinberg, Gerald M., Quality Software, Volume 1, How Software is Built, Section 1.3

[5] Eberhard, J. P. (1970). We ought to know the difference. In Emerging Methods in Environmental Design and Planning. Cambridge, Mass, MIT Press, quoted on Page 56, How Designers Think (2005), Fourth Edition

[6] Page 56, Lawson, B. R., (2005), How Designers Think, Fourth Edition

[7] Page 183, Lawson, B. R., (2005), How Designers Think, Fourth Edition

About the Author

Nilanjan Bhattacharya is a technical project manager in Semantic Sciences in Adelaide.

In a previous role he managed a test team in the R&D lab of IBM Security Systems in Singapore. He has 18 years experience working with software development and testing teams across U.S., India and Singapore, working on both consumer and enterprise products. His experience includes CAD/3D graphics, enterprise security software and text analytics software. He strongly believes in the principles of context-driven testing. He has an MBA from National University of Singapore.

Nilanjan’s detailed profile is available on Linkedin. His twitter handle is @nilanjanb and he blogs at Counterfactuals and Revelutions

Originally published at on July 8, 2015.