7 ms·

Design Thinking is the Data Science of UX: an attempt to gain influence in fields that you don't have expertise in. Even though there might be universal design

• ccppurcell 9mo ago
  Can you give an analogous example for data science? I confess ignorance here, and always took the term at face value. Is the issue that "data science" tries to be agnostic about the source of the data? (I'm not claiming that that is true, just guessing)
  • bsoles 9mo ago
    Sure. There are many examples of data scientists attempting to use complex Machine Learning and Deep Learning models to predict machine (bearings, gears, etc.) failures from vibration data, where a simple Fourier Transform (FFT) provides a lot more insight and predictive powers about the same problem. However, spectrum analysis is not something that data scientists learn at school, yet every mechanical/electronics engineer working in the field knows about it. So, without an expertise in a particular field, data scientists often reach for a big hammer, when more specialized tools exist and are known to the experts in the field.
    • deleted 9mo ago
      [deleted]
    • IOT_Apprentice 9mo ago
      Yet I suspect that mechanical engineers are not writing software for companies in the large. There are software developers doing so. I suspect that they should be consulted by data science folks as domain experts. That said won’t AI replace both? ;)
      • layer8 9mo ago
        Likewise, UX designers should consult HCI experts.
    • randcraw 9mo ago
      Another classic example is data scientists trying to model biological processes (or answer questions about processes while ignorant of which components regulate others). Systems biology has a long history of largely clueless attempts to predict outcomes from complex processes that no one understands well enough to model usefully. The biologists know this but the data scientists do not.
    • mythical_39 9mo ago
      huh. I'm a professional data scientist, and my masters was in signal processing. In one class the final exam required us to transcribe fourier transforms of speech into the actual words. In another the final exam required us to perform 2d FFTs in our head. Please be careful about generalizing. I agree that many 'data science' programs don't teach these skills, and you certainly have evidence behind your assertation.
      • Nevermark 9mo ago
        I don’t think anyone is making the claim that data science has no merit, or data scientists are universally ignorant of anything. Simply that some data scientists, formally trained or titled by themselves or others, have been known to apply their skills to data without having special knowledge regarding the data. It is a bit of a cliche in some of our experiences. The consulting company that analyzes data for a decision paralyzed organization, that seeks outside guidance in lieu of getting better leadership, is something I see. That is a real phenomenon, and despite good intentions, can have all the effectiveness of reading tea leaves. Because there is always data to be scienced. Competently or not.
      • bsoles 9mo ago
        > ... my masters was in signal processing But, you are making my point for me here. Most data scientists don't get masters in signal processing. You are also acknowledging that gaining expertise in a particular field was worth pursuing.
    • Grosvenor 9mo ago
      It's much worse than that. If you dare to ask that a team speak with the problem owners - mechanics, managers, etc, you will get booted right quick. Since the 2010's data science has gone from scientific based curiosity in solving problems to pure technicians work. There's a set of algorithms they follow, no exceptions allowed. Kaggle is a horrible anti-pattern. NB: I am a data scientist.
    • doctorpangloss 9mo ago
      i confess, i've read both of your comments on this - your analogy and a deeper explanation of the analogy - and i still have no idea what you are saying. i'm not stupid. so first, my feedback here is, it sounds like you are an educator or in an education-adjacent role, and you should focus on making more sense haha. like lay out your beefs clearly, it sounds like you have a beef with interdisciplinary work, specifically between some STEM departments and especially with humanities and STEM departments, which is subjective. you don't have to be objective about everything. you can just say, "i don't like this design thinking thing because i don't like the people involved" or whatever. but i don't know! i cannot figure out what you are saying. it sounds like your point is: "some ways of solving problems are superior to others." i've heard this take a million times. one perspective i'll offer to you is, math is not the only way to solve problems. it's not even the best way in many cases. not everything can be solved by defining a narrow goal, and then having a dispute about the methods, and then picking some objective method and then applying it very optimally, or whatever. this is also on you, as an educator, to understand! i could give a bajillion specific examples. but first, you have to concede: an analogy nobody understands is bad, and you have to own that, and two, it's not really clear, what exactly is your dispute with Design Thinking? it doesn't have anything to do with user interfaces... so why the hell are you talking about it? why "Design Thinking people"? What is your beef here?
      • rawgabbit 9mo ago
        I believe he is trying to articulate the failings of e.g., JFK's Whiz Kids who were experts of statistical analysis and tried to use that knowledge to domains they knew little about. In a nutshell, these experts tend to deep dive on parts of the problem where data was available and ignore the parts of the problem that is not quantified. Which is usually a huge mistake.
      • bsoles 9mo ago
        As many other people on HN, I am an advocate for software engineers and I think it is important that software engineers themselves develop expertise and become owners in their particular fields of application, their processes, etc. Attempts to undermine their role and turn developers into simple cogs in the machine rub me the wrong way. I perceive (you might disagree) that Design Thinking, Agile, Scrum, and similar things as attempt for designers, PMs, etc. to insert themselves into the process, not as equal partners, but as people with elevated privileges over software developers. I don't necessarily disagree with the idea and ideals of Design Thinking. I disagree with the practitioners and their perception of themselves as something special over software developer. I also think that my original analogy at the top is perfectly understood by a lot of people here as much as I understand the type of people on HN.
    • runlaszlorun 9mo ago
      Sorry... OT... But I'm dying to know how you use FFT for machine failures. Is it just a matter of looking for unwelcome vibrations? Or more?
• codethief 9mo ago
  Uhh… What does Design Thinking have to do with UX? Sure, it could be used to come up with novel ideas for user interfaces but DT (nowadays) is an approach that's several orders of magnitude more general.
  • bsoles 9mo ago
    Sure. Let me then call it this way: "Design Thinking is the Data Science of design: an attempt to gain influence in fields that you don't have expertise in."
    • IOT_Apprentice 9mo ago
      I’d retort that software developers aren’t domain experts either. At the end of the day you either luck out if domain experts and actual users are involved in eliminating toil (in the sense that Google defines that) and optimizing the user experience, while reducing friction in applications and providing insights into data.
  • layer8 9mo ago
    The fact that it’s mostly being pushed by UX people.
    • codethief 9mo ago
      Is it? Personally, I've never even encountered it in that context, and I have attended several workshops on Design Thinking.
• hliyan 9mo ago
  Isn't design thinking just... thinking? There may be different design methodologies you apply in different domains (e.g. civil, aeronautics, automotive, electronics, software), but once you abstract that away, what you get is thinking. I once attended a design thinking workshop many years ago, and no one there was able to adequately explain what design thinking was, except by means of jargon, metaphor, or example. My understanding of the subject has not advanced much further in the intervening years.
  • gnosis67 9mo ago
    I got the same reaction from that “how intelligence agencies think” YouTube video. Come now, “situational awareness”? Who needs a conspiracy to pay attention to their environment? And other mental tricks that people who must be told what to do may not come up with for themselves. Design however is a highly praiseworthy contemplation. There are those who do it well, and those who best learn to rip off what works as faithfully as means allow.
    • mcmcmc 9mo ago
      I think you’re doing situational awareness a disservice, and I’m guessing you’ve never worked in a field where it is a trained discipline. It is not just paying attention to your surroundings, it is actively scanning and evaluating to anticipate changes to your situation. Big difference between standing on a hill taking in the view versus keeping your head on a swivel, identify avenues of approach and egress, all while looking, listening, and smelling for anything out of place. It is more applicable to the physical world than any software domain.
      • gnosis67 9mo ago
        Okay soldier, can you tell you are not alone in your own mind, and that American Thought Control is running an extortion racket on the United States Military? Can you tell Bannon looted the intelligence community and exposed the envelope of every clandestine military secret by getting Trump to gather all of those commanders into one room? You’re screwed and you don’t even know it.
• HillRat 9mo ago
  Design thinking, at least in its formal STS approach, is essentially applied sociology; it's about using various toolkits to build a sufficient understanding of a domain from the "inside out" (using desk and field research) so that you can design valuable experiences that build upon the expertise of those actually inside the domain. In this, it's a bridge between UX/product and users/stakeholders (technical stakeholders are admittedly too often an afterthought, but that's a process problem). If anyone comes in and attempts to blindly shove workshops at you without first conducting in-depth research, interviews, and field studies in your domain, then they are (without resorting to the One True Scotsman) not doing design thinking, they're doing cargo-cult brainstorming. (It's also a process orthogonal to agile development, since by definition it's a linear process that needs to be conducted prior to developing the actual product features and requirements.) The books and papers the OP cites are solid (Rittel and Webber, Buchanan, etc., though TRIZ, I think, is rather oversold), but in my experience the problem with most design thinking practitioners is that they aren't qualified sociologists and ethnographers, so a lot of design thinking is basically a reinvention of the last century of sociological middle-range theory and ethnographic principles, without being strongly informed by either, likely due to the field's foundation in early software requirements studies.
  • randcraw 9mo ago
    That's a great answer that offers concrete insight into what design thinkers are trying to achieve. And it seems like they have a chance to succeed if they also employ iterative experimental methods to learn whether their mental model of user experience is incorrect or incomplete. Do they?
    • HillRat 9mo ago
      Traditionally you use a lot of paper and experiential prototypes to iterate on, which doesn't cover everything but helps refine assumptions (I sometimes like starting with mocking downstream output like reports and report data, which is a quick way to test specific assumptions about the client's operations and strategic goals, which then can affect the detailed project). When I can, I also try to iterate using scenario-based wargaming, especially for complex processes with a lot of handoffs and edge cases; it lets us "chaos monkey" situations and stress-test our assumptions. More than once early iterations have led me to call off a project and tell the client that they'd be wasting their money with us; these were problems that either could be solved more effectively internally (with process, education, or cultural changes), weren't going to be effectively addressed by the proposed project, or, quite often, because what they wanted was not what they actually needed. Increasingly, AI technical/functional prototyping's making it into the early design process where traditionally we'd be doing clickable prototypes, letting us get cheap working prototypes in place for users to test drive and provide feedback on. I like to iterate aggressively on the data schema up front, so this fits in well with my bias towards getting the database and query models largely created during the design effort based on domain research and collaboration.
• jjtheblunt 9mo ago
  > people think that they can just come in and ... SOC2 is like this: a collection of security ideas thought up by a group of CPAs, so they can partake in software engineering. It's beyond bizarre.
• b00ty4breakfast 9mo ago
  when Idea Guys™ never get told to buzz off
• tengbretson 9mo ago
  > "I like your design thinking, I do not like your design thinking people. Your design thinking people are so unlike your design thinking." - Gandhi
• uxcolumbo 9mo ago
  Not sure what your definition of 'Design Thinking' is. Design Thinking isn't about people thinking "that they can just come in and design user interfaces, etc. without really having an expertise in the particular field." It's a problem solving approach using UCD methods amongst others and working with experts in the field to come up with solutions and ideas to a given problem space. Key thing is you work with the people who are experts in the field, for example working with medical experts to design a new health related application etc.
  • bsoles 9mo ago
    It is the practice that matters, which is the "designers" trying to elevate their position to something more special by inserting their special rules into the design process, often at the expense of other people involved, including the experts. "Working with the experts" always turns into weird formalized brainstorming sessions or other rituals, where the designer defines the process and the rules, and others' role is just to be little players in the game, but not the referee. This is nothing new. We have seen the same thing with PMs and "scrum masters" inserting themselves into the software development process with shit like Agile, Scrum, etc. If design thinking is just a problem solving approach, experts and practitioners in the field are perfectly capable of doing that. We don't need the shamans of Design Thinking to guide the process.
    • uxcolumbo 9mo ago
      Those experts and stakeholders have a day job (i.e. don't have time to do this) and are usually in silos. They are not experts in workshop facilitation, user testing, usability, rapid prototyping to iterate on ideas and to think more broadly. It helps to avoid parts of the innovator's dilemma and to break out of siloed thinking, i.e. involve stakeholders from other functions of the org. Not sure what you've been sold, but there are no special rules or rigid methods. But you're right, unfortunately there are consultants who use this term to sell you a new wunder method to solve all your product problems, but they are not really design practitioners. Same way as people took the Agile Manifesto and bastardized it to create SAFE.
• Mentlo 9mo ago
  Having read the other comments in reply to this one (and your subsequent replies) - I believe you might be falling into a "No True Scotsman" situation. First of - I don't know what circles you've been around, but I've not been in work collectives where either designers, UX-ers or data scientists try to insert themselves to do things instead of software engineers. If anything, in any collective I worked in, if a software engineer was to say a peep everyone would retreat like there's no tomorrow and thank god that they don't have to deal with it and the software engineer will. Secondly - I think you are mistaking a structuring and outlining of a process with that being a mandate or an order to follow the process. When I work with software engineers, I expect them to be agile - not to follow an agile process, but to achieve the objectives of the agile manifesto - namely, to iterate ruthlessly, keep an eye on usage signals and lead with MVP's rather than over-design. Good software engineers do that, bad software engineers don't. Ultimately, I don't even judge software engineers by that - I judge them by the ability to produce results. I think the implication of your thinking is that this is all nonsense because software engineers innately solve data science problems and design thinking problems when appropriate with appropriate methods - to which I'd reply - there's a shocking amount of software engineers who can't do anything with data and are useless in fitting a linear regression to predict something, let alone doing a Fourier transform - to which, presumably, your response would be "No true software engineer is like that". That's great, but it's not true in the real world. Same with design thinking - there's software engineers who just can't solve problems from first principles (but can, say, create a fail-proof CRUD app to automate a business process). The real world is messy and full of people who can't structure their thoughts, or can't structure them in all domains at the least - and things like design thinking - or generalists who can be thrown at any data problem and produce something (i.e. data scientists) - are useful. They're not the best solution always, sure, and if they start being protective of territory - it's a problem - but in a normal collective that doesn't happen. Basically - your objection can be boiled down to "generalists are shit, because they impose process on everyone, including people who understand the domain better" - which tells me more about the collectives you've worked in than the nature of those jobs. In every collective I've worked in, generalists are what you throw at an ambiguous problem to produce some results before you get domain specialists in.
• kwanbix 9mo ago
  Design Thinking is NOT about UX design.
• rrm1977 8mo ago
  You have a veyr good point here. Sadly many people try to sell design thinking as a product without digging into its underpinning philosophy at all. This is driven by many business and egineering schools that tend to turn it into a creativity-making machine. Again sadly, it doesn't work. In order to benefit from design thinking, it is important look at it from the perspective of problem framing before the solution framing. You can check the Frame Innovation by Kees Dorst, who is built on the philosophy of Thomas Khun. Another thing is that design thinking is sold as a process where we as desigenrs never think this way. The IDEO drove this approach to make it easy to understand. This is why I teach my students that design is an arena where all the factors and stages blend. You can check the last paper in the article about the Memoranda and Artfect as it sreflects on other proceeses such as the Agile.