I find that writing these blog articles is a fantastic way of assembling a variety of ideas and distilling them into coherent stories / concepts (well, hopefully they’re coherent). I always welcome feedback and corrections because it helps to round out my understanding of concepts relating to OSS. Feedback from you, dear readers, is highly valued.
In this article, I’m even more in need of your help and input because there’s a concept that really vexes me.
When I start a transformation, I try to be really customer-centric, aware of, and empathetic for the users of the OSS we’re trying to build.
For our assignments, this generally means starting by understanding the user personas – the people who will use the solution.
The persona map is often multi-dimensional. It’s not just the different types of users (such as the 70+ examples in our freely downloadable Use-case Template) but can also be categorised into the layers of organisations that the users are associated with, such as:
After mapping the personas, we then look at the workflows, actions and data that these people need to work with. We also need to be particularly cognisant of the handoffs to other personas / systems as part of end-to-end flows.
So. That’s our approach. Outward-facing. Start with the customers, the customer experience (CX) and the User Interfaces (UI/UX) and work out to built the required solution architecture (the technology) from there.
But here’s the part that has me vexed and I desperately need your opinions and suggestions.
Standards bodies have done an outstanding job of creating architectural frameworks that are full of building blocks. They’re really valuable for the industry so they receive high praise from me. However, have you noticed that almost all models used by industry start from the architecture (the technology) first and then we have to map that to the CX later? They’re inward-facing models. Most models are created for designing the structural components – the applications, the APIs, the integrations, the infrastructure, even the functional and non-functional requirements.
They start with an inward-facing view, and even when they consider users, it’s more about the internal users (eg ops teams, admins) rather than the end users (#1 in the list above).
Am I missing something? Am I having a new-year holiday mind fade? Apart from Design Thinking, are there common CX / UX/UI architectural models that are used in the world of OSS that I’m forgetting about?
What model do you start with? Which building blocks?
If you’re starting with an inward-facing / technological design, how do you make sure you’re still putting the customers / users first?
I’d love to hear your comments.
Standing out in a highly saturated and fragmented OSS market can be really difficult. We’re regularly involved in bake-offs where we see dozens of OSS
One of the things I love about my job is all the vendor demos I get to see. Product demos are one of the four
Have you read the book, “The 4-hour work week” by Tim Ferris? It was one of those relatively rare books that inspired a complete mindset
Over the years, we’ve been involved in many OSS procurement events and have seen a variety of different pricing models proposed by vendors. Being software,
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.
