Designing for absence of the interface
When designing a new product or feature, the most obvious things you'd think about are user experience - how things flow together, transition between states, and so on - and the user interface. The second part is why we spend time building elaborate design systems, create complicated prototypes and user test them. But as the company I work for started shifting more and more towards big, enterprise clients, I found that more and more UX work is shifting towards not having the interface part altogether.
The reason for the shift
As companies grow, they build up all sorts of processes and tools internally. Setting all of this machinery up usually costs a lot of effort (and money). Additionally, the systems and processes being built start depending on each other - in the case of my current role at Lilt, it may mean that getting your content translated means getting your budget approved, your linguistic check done by someone in Marketing who will use this content and so on. This might also have to happen asynchronously because of multiple offices in multiple timezones.
Selling to a company with established processes means one of two things - disrupting what they know, or squeezing neatly into their existing processes.
The intelligent disruption
Disruption is often talked about in startup circles. In a classical startup meaning, disruption is always good - you take an existing tool or process that's inefficient, and you disrupt it by making it better, easier, or faster to use. What people often forget when getting excited about building new things is the second part - are you actually making it easier, better, or faster to use?
This is where you have to pick your battles - if you're a disruptor in the market, what is it that you can do to have the most impact on the underlying success metric? Very often, a well-designed, seamless integration with the existing system is a better answer.
How do I know?
To decide whether you need a no-UI solution, start where you always should: with the users, their end goals, and their success. Then try to think clearly - what is the least invasive step we could introduce to make this process better? Try mapping out the current experience (Service Blueprints and User Journey Maps work well here) and try to find the path of least resistance to introduce your new product or feature. Think deeply about the goals and how the successful use looks for your users. Spend some time observing them as they work to get context - there is a chance there's an existing process or tool in their existing workflow that you can easily hook into that might not require building out an entire interface to do it - very often this lives in assignment logic or custom workflows supported by their tools.
You'll be surprised how often it involves minimum UI to make things better.