During development of computer software you will, hopefully, get to know the domain to which you are making the software for. Actually you should know your domain before you start making the software. Nevertheless, you will gain deeper knowledge of the domain as the project proceeds. Eric Evans in his book Domain Driven Design stress the importance of having a common understanding of that domain and the language you use in it to drive the implementation, hence the title of the book. When someone says "Car" in a software system for a auto repair shop it means something different than in a software system for handling cars in a parking lot on an airport. Granted a car is a car but the granularity of what you mean depends on your domain. Car in the first example could have an extremely precise definition with a lot of properties, while in the other could be the same as a vehicle that just takes up place. The book goes into several different aspects of modelling a domain. Having an ubiquitous language is just one part of it, but arguably the easiest to start with.
A benefit of having the ubiquitous language stored and written down is that new people on the project can look up the terms and understand quicker the discussions going on the domain itself. Developers and business experts will start to use the same terms meaning exactly the same thing and hopefully the code will reflect it. Developers could make up their own terms and talk their own language if the domain language is not well understood or accessible. It is a possibility that the focus comes on code structure, which by all means is important, instead of the domain and bringing value to the customer. The ubiquitous language reduces the risk of that. Instead the developers who are committed to using this language in the context of implementation will point out imprecisions or contradictions that can be brought back to the domain experts. This creates a loop which deepens the collaboration and common understanding.
First step for defining an ubiquitous language can be to set up a wiki with the terms and their meaning. Quick and easy. It is no excuse to procrastinate. As the project goes on the list and terms will be more and more refined. Every time you here a new term which you do not understand, look it up in the list and add it if it is not present. When adding items bring together the entire team with domain experts and agree upon a precise and common definition of the term. Often the discussion of the precise meaning of a new term will illuminate other terms and sharpen their definition. In that case, update the other terms as well. Note that the definition of the terms can become recursive, i.e., the definition of a terms can include another term that also has a precise definition in the domain.
When defining terms in the ubiquitous language it is often tempting to include business rules as well. My experience is that it is best to keep those in other places in the domain model and only concentrate on the meaning of the terms in the list of terms.
An entry example for the definition of "bought" in an application for a toy store could be:
Bought: A status for a product in store, the physical or online, that has been paid for by the customer.
A couple of questions still reside. Does the payment transaction have to go through before the product is bought? Does a product that is returned still bought? Does the customer have to be the one and only that paid for the product?
Regarding the payment transaction we have to bring in the element in domain driven design called bounded context. Our bounded context does not include the payment transaction, in this example at least, i.e., we do not care or introduce any of the complexity of the payment transaction. That is another bounded context.