Design as a Minority Discipline in a Software Company


Muller, Michael J., and Kenneth Carey. “Design as a Minority Discipline in a Software Company.” Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Changing Our World, Changing Ourselves – CHI 02, vol. 4, no. 2, 2002, pp. 383–390., doi:10.1145/503376.503445.

Michael J. Muller, Kenneth Carey – IBM Research

June 4, 2020


  • “Designers are an example of a minority discipline
  • Minority discipline = “a discipline whose members are often isolated in their work teams among co-workers with different training, backgrounds, and career paths”
  • This paper compares differences between actual practices of designers working on IBM’s Lotus software products and the way published reports describe design practices in group settings. It also describes the real practices to published advice in knowledge management studies.

Design as a minority discipline; The “Double-Knit Organization”

  • McDermott’s knowledge management theoretical framework is used in this research
  • Examples of minority disciplines in software include human factors, user assistance, and business planning
  • Multifunctional products teams work well in the beginning, and the first to experience problems are those in minority disciplines
  • Designers “are often expected to follow career paths similar to those of software professionals”
  • According to McDermott, designers can gain support by being members of networks with similar backgrounds
  • Members of majority disciplines and minority disciplines have different sources to turn to for career development; those in majority disciplines can expect career growth through their teams whereas those in minority disciplines turn to communities of practice for career growth

Studying Designers as a Minority Discipline

  • Participatory analysis research method:
    • Informal ethnographic interviews (20 sites)
    • CARD sessions (of typical activity flows in nine designers’ work)
      • Perhaps I can ask about their work flow and find points of possible knowledge sharing activity
    • Interviewed designers that worked as the sole design-oriented member of a product team
  • Ethnographic Interviews
    • 18 designers’ offices, 2 studio spaces
    • Backgrounds
    • Career paths into design
    • Working relations with product teams
    • Working relations with other designers
    • How they work with team members
    • How they use artifacts; are the tools they use similar / different than other team members? Ex. same tools as engineers?
    • Interviewer asked to access online repository of artifacts
    • Interviewer made sure to follow designers’ senses of what was appropriate to show; don’t put interviewee at risk
  • CARD sessions
    • CARD practice is used to map out and analyze a human work process
    • CARD maps out two levels of work processes – explicit and tacit
    • Explicit = work objects, work activities
    • Tacit = mental, cognitive, emotional
    • The first two layers contain events that take place during the work
    • The third layer contains events that occur when the designer is reflecting on the mapped out results of CARD
    • Designers become co-interpreters of their own work
    • You can gain more insights about knowledge management behaviours of designers by providing them a map of their current process to reflect upon
    • It’s like having them look in the mirror for the first time
    • Through what framework can I shape what they see to provoke a critical reflection of their knowledge management behaviour?
    • Can this framework be based upon a core theory that I draw out through GTM?
    • So, there would be two touch-points with the interviewee; by having the interviewee reflect on the map, it’s also a way to validate the GT

Results: Designer’s Isolation

  • Designers are known to work alone
  • “Visual access to work is a carefully considered and negotiated attribute of work areas and work practices”
  • Designers don’t like to work alone because they need someone to validate their work
  • Peering over each other’s work is accepted

Results: Designers’ Roles

Results: Designers’ Artifacts

  • Designers are tied to the product specs; they may have a lot of responsibility over the maintenance of specs
  • There are variations of prototypes that designers communicate through:
    • Informal: Hand-drawn, comic storyboards, scenario presentations
    • Formal: High fidelity, interactive simulations, advanced GUI
    • Prototypes are sometimes introduced early in the project to both test the understanding of client requirements and selling an idea
    • Knowledge management of work before an idea is sold to the client vs work done after a client approves an idea
    • This nuance may require different sources of knowledge being consulted to conduct the work

Results: Designer’s Practices

  • Interview Q: When do you listen more, and when do you speak more?
  • How long a designer stays in a project can also determine their KM practice
  • Interaction designers tend to take on general roles that overlap with software architect
  • With these fluid design job titles, I can ask how they think their roles overlap with different job titles that already exist in the organization, or do not exist in the organization. I wonder how important it is to them to identify that.
  • Interaction design x UI design x product design x product manager…

Results: The Exceptions: Designers in Design Groups

  • Within groups, critique sessions are part of a formal process

Contrasts and Conundrums

  • Artifacts:
    • When designers are alone in a product design team, visual sharing is not as prominent as traditional design teams
  • Practices:
    • There is “reluctance to engage in inter-team Crits” – designers are not interested in critiquing work across different teams
  • Knowledge Organization
    • Designers don’t follow a hierarchical taxonomy of knowledge resources
    • When working in a tight timeline, there is no desire to look to new resources
    • Designers focus on tools to determine their work, whereas usability specialists follow methods to conduct work – there will be a different in knowledge sharing on tools vs. methods
    • “Usability specialists tend to use the method to give structure
    • to the usage of the tool. Visual designers tend to use the tool to give structure to
    • the usage of the method.”
  • Persuasive Rhetoric
    • Visual designers use graphical displays to communicate their work and ideas
    • Interaction designers communicate through narratives to describe their ideas
    • Usability specialists use evidence to make their arguments
  • Authors claim a dominant KM strategy would not be suitable to meet the diverse needs of design practitioners (in software industry)
  • To strengthen collaboration, technological solutions (ex. online tools, formal) and social solutions (ex. creating opportunities for dialogue, informal CoPs) can be implemented