An OSS design principle I need your guidance on

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:

  1. End user organisation
    1. User
    2. Business unit lead (in case there’s a department-level breakdown of cost-allocations)
    3. Admin / procurer (eg on behalf of the end-user organisation, the telco’s customer)
    4. etc
  2. Retail Service Provider (RSP) telco
    1. Customer facing
    2. Ops
    3. Super-user
    4. Admin
    5. etc
  3. Wholesale telco
    1. etc
  4. NetCo telco
  5. OpCo
  6. InfraCo
  7. Vendors / suppliers (eg OSS suppliers, solution integrators, etc)
  8. Product partners (eg UCaaS providers, etc)
  9. etc

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.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.