The topic for this article is a situation that I’ve now faced quite a few times in my professional career. And with Organizations of different levels of UX maturity. It’s also a question that has prompted some very heated discussions between different stakeholders and one that I’m happy to volunteer my thoughts on the topic. This article is both a reflection on what I believe to be a sound decision, and also what actually has unfolded in my professional experiences.

Should there be a differentiation between internal facing and external facing applications. Typically associated with this conversation, there’s a few items to consider in order to get a better perception of what is at stake. Firstly, there’s typically a problem that is felt by an organization and some of its departments, one that is usually considered very particular to that same organization (and which invariably, when research starts being done, is not that unique). It’s a problem that usually manifests itself in lack of efficiency, or performance (or both), something that is deemed a great opportunity for improvement (as well as it should). Secondly, while this problem is relevant and pertinent, its pain level has yet to be clarified, since there’s various competing initiatives each one of them claiming for their primacy for both resources and funding. And thirdly, the timeliness of addressing the problem and figuring out a solution. How long will it take to address the problem, and craft a solution that resonates and ultimately alleviates the guttering friction that is occurring.

In my professional experience, when it comes to internal tools, there’s always an immediate and visceral reaction to these, deeming them unimportant, or secondary to everything else the Organization is doing. Typically the premise is “If the client isn’t using it, it doesn’t have to be very good”. And that of course is where the problem immediately lies. Those who utter those words never truly consider the team members who need to have their problems solved, neither as a client or as a user. They’re simply colleagues, whose problems ultimately don’t really have to be addressed, even if as a result, the value of what they deliver to Clients actually suffers as a result of that same friction.

The whole aspect of classifying an application or project as internal versus external, immediately creates a bias for some teams, where the level of investment they want to devote to that problem solving process is non existent or at least not that significant if indeed the solution is going to be user by internal team members. As I mentioned earlier, these individuals who immediately revert to their mental model of “internal = subpar”, they all invariably seem to forget that if one team is indeed experiencing a problem in their process or in their tasks, chances are other Organizations are too, therefore why not create a strategy for problem solving that starts with internal team members as their first clients, and progressively expand that solution and understand how much dissemination it can have in the market itself. The lack of perspective and vision always seems to be one of the main issues, with the secondary one of course being “it doesn’t have to look good, it just needs to get the work done”. Again, a statement which is supposed to firstly reduce the role of Design to making products aesthetically pleasing, and secondly, that the Design process itself is lengthy and possibly aims to solve for more than what is effectively needed. These of course are typically erroneous suppositions, since in fact the Design Process can move as fast as needed, while still addressing the problem that needs to be solved, the users themselves, the activities performed and the testing needed. Ultimately, problems are problems, and users who experience them should be treated as a priority, while also seeking to understand that therein lies both an opportunity to delight and also further solidify an Organization’s approach to problem solving.

Where does Service Design sit on this topic. The Nielsen Norman Group defines Service Design the following way: “Service design is the activity of planning and organizing a business’s resources (people, props, and processes) in order to (1) directly improve the employee’s experience, and (2) indirectly, the customer’s experience.” You can read more detail on this topic on their site here. Which is to say, a large focus of Service Design is indeed process improvement and making sure tasks that are performed internally are efficiently done, so that the value that is in turn delivered to the customer is that much more gratifying/rewarding and ultimately leads to longevity and retention of those relationships. I just recently went on a journey of delivering product solutions in a Service Design ecosystem, and while at times the discussion of the value and cost of creating satisfactory solutions for internal teams did come up, it quickly became very apparent that without solutions that truly addressed the problems identified, the value that was ultimately transmitted to the clients was compromised in the long run. All this to say, compromising on the quality of internal product solutions since they’re not deemed “client facing”, it invariably causes more damages in the long run, including reverting back to those same teams (and once more, costing more for the Organization), since the problem was never truly addressed, and only partially solved for. Always solve the problem for what it is, dismissing the bias of being internal versus external, since everything eventually has an impact on the customer experience itself.

Solve Problems. Personally I’ve always thought the whole concept of solving for “internal versus external” problems slightly puzzling. Problems are problems, and Design as a discipline is at its core, a problem solving practice. Our goal should always be to truly understand the problem and the people/users/customers impacted by that problem. And place those pieces of information as part of a process which aims to provide solutions that pierce through the issues that are identified. While understanding the context of utilization, the circumstances in which solutions can be leveraged, becomes clearer, but independently of being internal facing or external facing, problems should be solved with the same amount of thoroughness and attention. And those solutions should be tested and iterated upon. The issues with many applications eventually not working or being awkward, is typically a result of them being crafted in a myopic manner, where teams make large assumptions, without testing and iterating as much as needed to effectively learn what users are telling them. And once more to reiterate: the process can be as swift as needed, ultimately depending on the teams involved, and also resources that are available.

Reality Check. When coming to terms with this type of discussion, Designers should always have a question prepared for the originators of the conversation: “is this problem something that is only specific to us or is this something that happens with other Organizations”. As much as everyone likes to think they’re so unique in their processes and ways, chances are when solving problems, if done thoroughly and hopefully with innovation, a solution can account for both the large majority of scenarios, and still address more fringe ones as well. That’s what testing and iterating is all about, about finessing, creating inclusion and making sure the footprint created does resonate with clients. And those clients can be internal and external. Because ultimately it’s all about problem solving.

I’ll conclude with a quote from Karl Popperon the topic of problem solving:

“All life is problem solving.”