Methods might not improve designs, but are still useful for design professionals

Methods are a core topic in UX design. The human centered design cycle, Design Thinking steps or other variants that suggest how to structure one’s design activities. Not designing methodically is framed as wrong and as missing out on valuable insights 9. However, it is unclear if formally structured methods improve the design outcomes itself as created by designing per se.

Designing per se happens, whenever the designer acts directly on the designs (plans, prototypes, files) to develop and improve these designs. This takes the largest part in the education of designers and it is what defines the professional identity. Design in practice includes also other activities that are part of the designer’s job, but not designing per se, like meetings, calculations, and negotiations 1. These tasks are often seen as necessary evils 2. I argue, that, while design methods might not improve the designing per se, they improve a lot of other activities that are also important to successfully design in practice like being respected by colleagues, negotiating what needs to be done and claiming the definition of “what really matters”.

That the use of methods might not improve outcome of a design process has been demonstrated. In the empirical studies, designers do not approach design according to plans 12 and act opportunistically 13 14 12, they change the problem they are solving mid-process as they discover new requirements14 and they do switch the frames that they use to make sense of their designs 1516. And all that seems not to lower the quality of design. Some of these practices do actually seem to be necessary for successful designing17.

So if in these studies, design outcome is not improved by adhering to what a particular method prescribes, why use methods at all? The power of methods is less in telling what people should do to create a good design per se, but in than their social use, that is collaborative sensemaking, their use to claim authority and to enable managerial control in organizations.

Design work is often multidisciplinary. UX designers usually work (directly or indirectly) with developers; product designers need to communicate with engineers. The methods used in the design process can serve as a resource for coordination: Designers and people they work with will use the method to ensure they are on the same side and to ensure that they make sense of the world in a similar way. They will say “We will then enter the implementation phase” or “Let’s get the results of the user research until early November”. They might also tell the manager of the developers “We will need to work with a member of your team in February; before we have no scenarios that should be used to write the user stories”. This only works if the method is at least somewhat known by the people designer communicates with. If the people know the method and the terms, they can assume standard responses, standard actions, standard sequences. This does not mean that the actual process happens according to what the method prescribes. It is rather that what happens is explained using the method, including instances where people do something that the method does not suggest: “We should have been doing an in-depth analysis, however…”. Indeed, plans can serve as a way to communicate more easily about what is unexpected 19 18.

This collaborative sensemaking can not only be used in friendly coordination. A method also signifies rationality. First on the level of “this is the rational way of doing it“ and then by rhetorically alluding to natural science and economics. A method helps to “find” needs and “unlock” potential, it identifies the “right” customers, it suggests to evaluate if the products performance is “really” as it should be. Like that what it alludes to – the “scientific method”– a design method can also be used as a weapon against opinions which can be framed as not in accordance to the method thus rationality: The method is then mentioned and employed to lower the acceptance of other, “non-methodical” ways to proceed: “We should not start without knowing what our users actually want”, “You should have checked with quality control, they would have noticed”, “Without data we can not know what users actually do”. This only works if the method is accepted as the way work should be done, but as methods ally with rationality, science and economics, they have a good standing, usually 3 4.

Despite all pushes to democratic organizations, performances are measured, people are judged as being productive or not and managers hire and fire 6. Methods can be used to assure that people behave similarly by prescribing what should be done when and in which order. Methods can also assure that these behaviors lead to standardized “deliverables” that allow to see that progress is literally made (or not!): Often, steps in methods prescribe the use of representations of progress like reports, metrics, or prototypes. This regime of control and communication is not maintained forcefully 5. The methods and what they enable management to do is part of the environment the work happens in, like the path you walk on and the language you speak.

Now, as a designer one could take offense in what methods are used for and try to escape them. But that would also mean to try to escape the structures that shaped what a designer does and thus also the identity of design itself. Methods and the rationality they bring are not something pushed on designers from the outside, it also is an important way to strengthen the discipline and present it as a profession, a profession that is useful for earning money by fitting into structures of management and promising scalability of its output: A design is created once and that design is used to build products over and over again or to show many, many people the website. Designers could show that designing is deeply social, shaped by contingencies and sensemaking. But these are less valuable concepts when power should be defended.


  • I noted that invoking methods as a concept itself that people should follow is similar to invoking abstract math as described by Jean Lave in “Cognition in Practice”, where she writes that “…arithmetic is used there to justify choice are just the symbolically powerful images of rationality, utility, and objectivity”(p158) and “Calculating activity exists, but formal solutions… are more often… used as vehicles for the expression of feelings about rationality, than for its implementation” (p176) (Lave, Jean. Cognition in Practice: Mind, Mathematics and Culture in Everyday Life. Learning in Doing. Cambridge ; New York: Cambridge University Press, 1988.)
  • Laura Yarrow suggests in a tweet that Design Thinking works like a MacGuffin (An object in a story that drives the protagonists but does not do anything itself): “ …it can indirectly help with design maturity and build trusting relationships between design and other teams”.
  • Another method that is irrational, yet might lead to desired results is root cause analysis and 5 Whys, attempts to find out the final cause in an imagined chain of events. Assuming a root cause can prevent recognizing systemic issues and multiple factors; asking “why” can lead to hearing retrospective explainations rather than a retelling of what mattered in the situation (more critique: The Infinite Hows (Kitchen Soap blog) ). However, the assumption that there is a root cause can motivate doing an analysis in the first place; assuming that one has found the root cause helps to argue that one needs to fix that assumed cause.
  • 2022-12-19: Minor typo fixes; Added a footnote on core- and peripheral tasks based on Abbott, 1988
  • 2023-01-27: An pretty plausible method to understand users could be to learn an activity yourself and then be part of the design for it. For people working for a long time on the same product, this could actually be done. It is also part of contextual inquiry (A UX research method) to get some basic competency in user tasks and in academia, Ethnomethodologists do learn skills to analyze them. However, this clashes with UX research’s slogan of “you are not the user”, used to justify the need for the profession in the first place as well as with the general idea of the prototypical professional being an expert to be consulted – see medical doctors and lawyers as prototypical professionals. Still, it is possible that people do it; it is unlikely that they use their personal skill as justification as professional.

  1. Abbott writes about an idea that he calls “professional regression” which proposes a model in which professionally pure tasks (what I described as design per-se) get more in-the-profession prestige than tasks that are in-practice, e.g. where there is a lot of contact with clients and non-professional roles: “Professions tend to withdraw into themselves, away from the task for which they claim public jurisdiction. This pattern results from internal status rankings. The professionals who receive the highest status from their peers are those who work in the most purely professional environments.” 10 These pure environments are consulting for other professionals and working academically. The potential trouble is, though, that professions can not afford to lose the support of the public (who understands them as profession, as doing a high-status-work), yet the profession might neglect the work with clients and in-practice for its low prestige. 

  2. Looking at another job that also deals a lot of with methods, software development, there is a whole culture of despising meetings and the time they take away from “real work”. Meetings, hated or not, though perform crucial tasks in modern organizations 11 

  3. The use of methods as a social defense is described by Wastell in “The fetish of technique: methodology as a social defence”20. The crisis of professions and their relation to the need to be rational is discussed in Schön’s “Reflective Practicioner” 15. Llach’s “Builders of the Vision” discusses the concept of the architect as the person who creates the concept which then is instantiated by diligent builders as described by 13th century polymath Leon Battista Alberti. 

  4. The higher value of abstract creation vs. dealing with real world contingencies shows also in the lack of appreciation of maintenance. Maintenance is slow, context bound, much more like care and attending to than the green field creation so much loved by designers and developers. 

  5. Although not focusing on plans, the use of communication (also) for control is discussed in Yates’ book “Control through Communication” 21: The process of making work adhere to a formal structure is the theme of Agre’s “Formalization as a Social Project” 22. This can also serve to make outcomes traceable, which allows not to manage how people do things but that they do them 23

  6. I do not know sources that deal with the topic of how methods, managment and design are connected. However, computer programming and it’s relationship to methods has sources that tell about this aspect. For example, Ensmenger’s “The Computer Boys Taker over” 24 tells how computer programming was framed and re-framed by both programmers and managers in each fractions interests. An important word in this discussion is the “Software Crisis” which was used to justify the need for more formal methods. Fitzgerald: “An examination of the literature reveals a two-fold bias, which, firstly, construes the ‘software crisis’ as a problem arising from the sloppy, ad hoc and irrational approaches of systems developers in practice; and, secondly, views the solution to the software crisis in terms of more widespread adoption of rigorous and formalized systems development methodologies.” 25 

  7. Gedenryd, Henrik. How Designers Work - Making Sense of Authentic Cognitive Activities. Vol. 75. Cognitive Science, 1998.

  8. Parnas, D. L., and P. C. Clements. “A Rational Design Process: How and Why to Fake It.” IEEE Transactions on Software Engineering SE-12, no. 2 (February 1986): 251–57.

  9. Kolko, Jon. “Without Design Methods, I Feel Like I Am Cheating.” Blog, May 18, 2012. 

  10. Abbott, Andrew. 1988. The System of Professions: An Essay on the Division of Expert Labor. First edition. Chicago: University of Chicago Press. 

  11. Schwartzman, H. B. The Meeting: Gatherings In Organizations And Communities. Softcover reprint of the original 1st ed. 1989. Springer, 2013. 

  12. Visser, Willemien. “More or Less Following a Plan during Design: Opportunistic Deviations in Specification.” Int. J. Man-Mach. Stud. 33, no. 3 (1990): 247–78. 

  13. Visser, Willemien. “Organisation of Design Activities: Opportunistic, with Hierarchical Episodes.” Interacting with Computers 6, no. 3 (1994): 239–74. 

  14. Guindon, Raymonde. “Designing the Design Process: Exploiting Opportunistic Thoughts.” Hum.-Comput. Interact. 5, no. 2 (1990): 305–44. 

  15. Schön, Donald A. The Reflective Practitioner: How Professionals Think in Action. New York: Basic Books, 1983. 

  16. Dorst, Kees, and Nigel Cross. “Creativity in the Design Process: Co-Evolution of Problem–Solution.” Design Studies 22, no. 5 (September 2001): 425–37.

  17. Atman, Cynthia J, Justin R Chimka, Karen M Bursic, and Heather L Nachtmann. “A Comparison of Freshman and Senior Engineering Design Processes.” Design Studies 20, no. 2 (March 1, 1999): 131–52.

  18. Bardram, Jakob E. “Plans as Situated Action: An Activity Theory Approach to Workflow Systems.” In Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, 17–32. Springer, Dordrecht, 1997.

  19. Rönkkö, Kari, Yvonne Dittrich, and Dave Randall. “When Plans Do Not Work out: How Plans Are Used in Software Development Projects.” Computer Supported Cooperative Work (CSCW) 14, no. 5 (2005): 433–68. 

  20. Wastell, David G. “The Fetish of Technique: Methodology as a Social Defence.” Information Systems Journal 6, no. 1 (1996): 25–40.

  21. Yates, JoAnne. Control through Communication: The Rise of System in American Management. Johns Hopkins paperbacks ed. Studies in Industry and Society 6. Baltimore, Md.: Johns Hopkins Univ. Press, 1993. 

  22. Agre, Philip E. “Formalization as a Social Project.” Quarterly Newsletter of the Laboratory of Comparative Human Cognition 1, no. 14 (1992): 25–27. 

  23. Agre, Philip E. “Surveillance and Capture: Two Models of Privacy.” The Information Society 10, no. 2 (April 1, 1994): 101–27.

  24. Ensmenger, Nathan L. The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. Cambridge, Mass.: MIT Press, 2012. 

  25. Fitzgerald, Brian. “Formalized Systems Development Methodologies: A Critical Perspective.” Information Systems Journal 6, no. 1 (January 1996): 3–23.