“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, for most people in perpetuity. Convention over configuration rules the day. To me, everything it could possibly do is less interesting than what it does right now, factory fresh.
At 37signals we call this The Golden Path and we discuss it often. If a customer followed our lead, stayed in the grooves, and did exactly as the software suggested, what would that experience be like? That’s the one nearly everyone will have, so making it great is our top priority.
Certainly some will take the path least traveled. Others will head to whatever gear icon they can find and start turning the dials and pulling the levers. And then there are those who enjoy figuring out how to break things by imagining every exception or edge case, and seeing how the app handles it. It’s great to have these customers too! But they aren’t the ones that pay the bills.
Most buy something they just want to work. Configuration is a drag, not a desire. Setting something up brings them down. They just want their struggle out of the way, and choosing and buying the thing was the majority of the work they signed up for. The rest should just glide.
Defaults aren’t just about nailing The Golden Path, it’s also about choosing one. What experience do we want people to have? What opinions do we want to carve into the product?”
Jason Fried (on a LinkedIn article here)
I love this concept of the Golden Path from Jason Fried as a way of describing a way to design a piece of software. It talks to having an end in mind (an activity performed, a problem solved, a use-case instantiated, etc) and designing a user experience through the software that delivers a super-efficient pathway to achieving it.
It’s the thing I love about most early iterations of OSS and BSS tools (I’ll call them the MVP – or Minimum Viable Product – in this article for simplicity even though they might be much more than an MVP).
The creators are usually quite clear about what their software is trying to achieve and the UI / UX / CX is also quite clear / concise. The Golden Path/s designed into an MVP version normally focuses on the most important features and flows, as represented by Pareto and the red box in the long-tail diagram below (where the X-axis is features and the Y-axis is “value” of some sort).
However, as time goes on, product managers then have a tendency of adding more and more features (the blue arrow). These can lead to a distraction from the Golden Path. The more features that are added, the more clutter, the more distractions. And rather than re-considering the Golden Path experience with each new functionality addition, there is a tendency to just bolt them on. A bolt on layered onto a bolt on, layered onto a bolt on. Soon the Golden Path has devolved into a Frankenstein Path.
But when it comes to carriers having to build an OSS/BSS stack (there’s almost never just one OSS/BSS product as a monolith these days, it’s almost always a collection of integrated tools), the Golden Path is more difficult to achieve. This requires much more careful planning.
Think about your OSS/BSS stack for a moment. I assume it’s comprised of a number of different solutions. Even if those solutions all come from a single vendor, chances are they were all conceived of separately, by different teams at different times with limited (or no) design coordination between them. It’s more likely that the integrations were devised afterwards based on APIs that were also designed in isolation. If the solutions all come from different vendors then there’s even less chance of having customer experience (CX) cohesion.
That’s partly where high-level process mapping comes into play. You may have noticed that we just released a new OSS/BSS Process Mapping Guide last week. It has over 50 starter processes for you to refine to meet your organisation’s unique needs and structures. Click on the image below, or here, to be taken to the download page.
These starter processes provide the basis for designing your multi-product “Golden Path” (hopefully). That is, they provide the really high-level intent for workflows such as Order to Activate (O2A), Trouble to Resolve (T2R) and around 50 other examples. They then need to be refined to trace user journeys and workgroup hand-offs through the various solutions that make up your unique OSS/BSS stack. Your applications, data flows and integrations also need careful design / configuration to ensure Golden Paths rather than Frankenstein Paths (sadly, too many probably end up as the latter).
What’s interesting too is that when most organisations evaluate products during a procurement event, they tend to focus on evaluating the functions (the individual bars in the long-tail diagram above). They don’t tend to focus on the flows through the product they’re evaluating or the flows into the existing tools that the new product will integrate with.
I’d love to hear your thoughts. How do you ensure workflow effectiveness with your OSS/BSS (products or stacks)? How do you ensure you’re building “paths paved in gold” and not “scary monster” workflows?
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
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.
