Most experienced software developers have an innate idea regarding this principle of designing outside-in and developing inside-out. I myself had quite some difficulty in coming to terms with this idea but after a few false starts, I am finally able to express it better.
When we write software we write it for a reason: "what is this software for?". We can further split this question up into its constituent parts: "who will be using this?" and "what data will this operate on/store?". Thus, a successful software product requires a tight feedback loop with whoever/whatever will be using it and a very careful consideration of its data model. Interestingly, both these aspects seem slightly contrary to one another - should one design the data model first or should one mock up the interface as a first step? As this post's title suggests, the answer actually lies in doing both at the same time!
Depending upon what are the basic software requirements, the first step should be to mock up the software interface. For user facing products, this can mean doing some UI mockups which focus on the minimum viable product (MVP). At the same time, work should begin on designing the data model so that the storage and handling of data is clear. Based on user feedback, the UI/UX will most likely be refactored which means that the data model will also need to be refactored. Keeping a very flexible initial schema will sometimes result in fewer initial schema changes but beware of taking on technical debt at this point.
For non-user facing software such as services, the interface is usually easier to nail down. In this case one can devote more time to clarifying the data model. On the flip-side, for software that does not store data, one can devote more time to fleshing out the UI/UX. If you are really lucky, you are writing a service that takes data transforms it and spits it out. It's no wonder that everyone is all excited about FaaS these days!
Once a somewhat clear picture of of the design and data has emerged, one can begin writing code to wire up the UI with the data to build a working system. This is usually the easiest part as the sketch is done and all that is needed is to color it in!
Given a solid data model, I personally prefer a functional style of programming as it enables me to write better tests and stay close to the data model via basic data structures. Regarding UI/UX, nothing beats user interviews and tweaking based on production metrics.
References: The faster you unlearn OOP, the better for you and your software