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.
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):
Are you a convert to Design Thinking? How does its principles help you design a better OSS?
In our “chasm” series of articles, we’ve talked about the gap that exists between OSS buyers (eg carriers or network operators) and OSS sellers (eg
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
4 Responses
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?
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!
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.
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.