Do you apply Design Thinking to your OSS change?

Design Thinking appears to be “the great differentiator” for many consulting firms at the moment (the only problem is if everyone is using it as a differentiator, then is it really a differentiator?). Having said that, the principles of Design Thinking do highlight a couple of important steps that I’ve found to be lacking in many OSS design / architecture deliveries.

First, a Design Thinking recap courtesy of Stanford’s dschool.
Design Thinking
EMPATHIZE: Work to fully understand the experience of the user for whom you are designing. Do this through observation, interaction, and immersing yourself in their experiences.

DEFINE: Process and synthesize the findings from your empathy work in order to form a user point of view that you will address with your design.

IDEATE: Explore a wide variety of possible solutions through generating a large quantity of diverse possible solutions, allowing you to step beyond the obvious and explore a range of ideas.

PROTOTYPE: Transform your ideas into a physical form so that you can experience and interact with them and, in the process, learn and develop more empathy.

TEST: Try out high-resolution products and use observations and feedback to refine prototypes, learn more about the user, and refine your original point of view

The key differences with this approach compared with most (in my experience):

  • The emphathise stage – As highly experienced ICT / OSS experts, we can have the tendency of “knowing” what the customer wants where knowing actually equals assuming. I refer to it as the immersion phase, but empathy is probably a better description of understanding the customer
  • The define stage – The interesting part of this description is the singular, rather than plural, reference to forming “a user point of view.” The challenge is that there are multiple personas interacting with our OSS. We need to think in terms of user pointS of view in most cases
  • The ideate / prototype / test stage – Due to the time constraints weighing heavily on all OSS teams (or at least in every OSS environment I’ve ever worked in), the first prototype quickly evolves into the production solution in most cases. We don’t tend to be given the time to trial and refine multiple iterations / prototypes. If the first one performs the task, perhaps no matter how inefficiently, that tends to suffice and we move on to the next challenge. Perhaps later releases iron out the kinks. But that’s not the ideal at all is it?

Are you a convert to Design Thinking? How does its principles help you design a better OSS?

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

4 thoughts on “Do you apply Design Thinking to your OSS change?

  1. OSS product/projects are rarely UX led. And rarely agile enough to run a feedback loop like this.

    Which is a shame, because the result usually look dreadful and do not maximize efficiencies by ignoring the human element in the ‘OSS Transformation’.

    But, it isn’t necessarily all bad. So much of OSS is backend, server side and integration. Somewhat isolated from the UX (but not entirely isolated, I acknowledge).

    Which leads me to ask the questions, what would be the Design Thinking process for such a system, where the biggest gains are *not* from UX optimization?

  2. What a great question James!

    I wrote the blog from the perspective of OSS tools that have a means for humans to interact with (eg alarm lists, service orders, approval of inventory discovery, etc). You’re so right that this perspective doesn’t represent all of the changes that happen to OSS. As you rightly point out, there are many machine-to-machine changes, database changes, mediation integrations, etc. That’s the less sexy stuff, but vitally important to an efficient OSS.

    I may be missing some scenarios here (please highlight anything else that I’m overlooking!), but I see most of the back-end stuff to be able getting data from one point to another, possibly from one format to another – effectively data migration / transformation. Then the design becomes a question of what data do you need, what format does it need to be in and what sort of volumes of data do you need to handle, but ultimately it comes back to, “why is it needed?” There’s no point in collecting data if there’s no purpose. It just fills up storage (the diminishing cost of storage probably reduces that argument, but the integration costs of transforming the data still constrains us).

    So once you’re asking why do we need the data, why a human (or system) would interact with the data, you’re starting to get back to the empathise / immersion state (step 1), followed by the design / persona state (step 2) of Design Thinking. The cool thing about data is that it’s then usually quick to ideate / prototype / test / optimise with (steps 3, 4, 5).

    What do you think? It’s a looser tie-in to Design Thinking isn’t it?

    Thanks James! I love the lateral perspective of your question! Please keep them coming!

  3. OK, if we take a common OSS project that is mainly data-led (rather than process/task led or UI led), and take a stab at what the design steps might be:

    EMPATHIZE: Work to fully understand the value of the data to the system in terms of system needs and potential for ad-hoc quires. Do this through observation, interaction, and immersing yourself in the available data and understanding of what is (or could be) asked of the system.

    DEFINE: Process and synthesize the findings from your empathy work in order to form a point of view on how the system and the available data could add value to each other.

    IDEATE: Explore a wide variety of possible solutions through generating a large quantity of diverse possible solutions, allowing you to step beyond the obvious and explore a range of ideas.

    PROTOTYPE: Transform your ideas into a virtual form so that you can experience and interact with the data and, in the process, learn and develop more empathy. [Could use anything from Excel to Big Data tools to do this. A vital step for data-led project as it should start to uncover whether the data is readily available, able to be joined, filtered, collated etc]

    TEST: Try out ’email integration’, stubs and representative data model and use observations and feedback to refine prototypes, learn more about the system being developed and upstream/downstream data uses, and refine your original point of view. [Again, vital in data-led projects to understand not just how *this* systems processes data, but the life-cycle of the data before and after].

    Interesting. Usually data-led projects in OSS tend to by designed based on two systems’ object models and whatever APIs are available. This design approach makes me think that a greater emphasis up front on what can be done with the data, and how much data is enough data, could better scope the project both in terms of avoiding boiling the ocean while also maximizing the value of the system.

  4. Great work James! I love what you’ve done there. It’s worthy of a blog entry in its own right (you have my blessing to put it up on ossline.com by the way).

    The one thing to call out for other readers that you’re implying in the last paragraph – some people may wonder why you need to put in so much up-front effort when integrating two data models. Two reasons: The first is because you rarely map everything across an interface (eg you may only need a small sub-set of what the API can provide) and second is because you’ll usually do some sort of transformation and / or cross-validation of the data you pull across. It’s rarely a one-to-one mapping, so some thought needs to go into getting the right data across as James is suggesting.

Leave a Reply

Your email address will not be published. Required fields are marked *