Abstract to Concrete: The Struggle of a Team

Michelle Vs
4 min readJan 30, 2021

This response paper is based on Design as Learning — or “Knowledge Creation” — the SECI Model and UX Information in the daily work of an agile team: A distribution cognition analysis.

Essence of SECI Model

While skimming through the Knowledge Creation paper, a quote by Nonaka caught my eyes:

“Knowledge is created through the synthesis of the contradictions between the organisation’s internal resources and the environment…”

This is in correlation to the first step of the SECI Model, Socialisation, where through experience and discussion, we acquire the first, most crucial, tacit knowledge. Hence, Nonaka implies our surroundings create the kind of knowledge we acquire, to each of their own.

There are two kinds of knowledge; tacit and explicit. Tacit knowledge is the kind of knowledge that is difficult to transfer to another person verbally/written. Explicit knowledge is the exact opposite, like a manual in your new gadget contains information that can be poured in a paper.

SECI Model

In short, this is what I gather from the figure.

Socialisation -> Tacit to Tacit -> Brain to brain -> “Discussion”

Externalisation -> Tacit to Explicit -> Brain to Paper -> Define/Synthesise Problem

Combination -> Explicit to Explicit -> Paper to Paper -> Research/Organise/ Iterate

Internalisation ->Explicit to Tacit ->Paper to Brain -> Application

Abstract / Concrete

In correlation with the Bridge Model, Externalisation and Combination can be labeled as “Descriptive/Concrete”, while Socialise and Internalise can be labeled as “Interpretive/Abstract” due to its nature.

Hassenzal and Garrett Models were also marked by this Abstract/Concrete labels, where they categorise these from Most Abstract to Most Concrete:

WHY/STRATEGY: Search for user motivation, align user needs with objective

WHAT/SCOPE: Defines functionality of product

HOW/STRUCTURE: Arrangement of content and action of user (e.g. UI)

By categorising these steps into abstract and concrete, we know what to expect in what step, be aware of the correct path to solving the problem and be wary of the mistakes we are bound to make. E.g. If we need to do research in office environment, don’t do it where your father is the boss because it can lead to bias results.

The Reality of a (Design) Team

According to Jane Vita, designing is always about transforming the abstract into concrete. Design itself, as a discipline, has the power to make the intangible, tangible. The research conducted in UX Information in the daily work of an agile team: A distribution cognition analysis shows that this is true, but in a way that designing is not the priority.

There are few points that I am not surprised with the team environment:

  • Developers were not responsible for giving information or preparing artefacts about UX, yet they expressed concerns about not using the feedback collected as well as they could.
  • The Newsboard was seen as useless to developers even though it contains the feedback from users collected after product release.
  • Developers reported that UI and UX Designers were both responsible for mockups with Product Owners, yet UI designers are not considered part of the team.
  • Location of UX information was not effective (Newsboard was visible only at the entrance of the room, while the frequently used TFS was not effective in delivering UX information).
  • Most of the time, developers were the receiver of UX information.

This team of developers did not involve themselves in the most part of the Abstract phase (The Why; meetings, newsboard) and put more focus on the Concrete phase (The How; mockups, demo, releases). From these points, I can safely say that UX was not a priority in this team. It was more like, kalo ada bagus, kalo gaada yaudah. Basically, lack of communication and engagement between developers and UIX.

In addition to the room and location of physical artefacts, the “Socialisation” (Abstract) phase differs. Maybe if they put the Newsboard somewhere within their eyesight, it would be more useful and may lead to different discussion.

Therefore, it brings me to a realisation that if you are not involved in the abstract phase, you will struggle in the concrete phase. Even though this is still a prominent problem in the tech industry where the tech guys and the design people are detached, certainly in the future there will be artefacts that make these information explicit, visible, and accessible to all team members.

--

--