Just to add some further detail to kodlu's excellent answer:

To share some secret data using Shamir's secret sharing over the finite field $\mathrm{GF}(k)$, you first need to encode that data as $m ≥ 1$ elements of the field (which are naturally represented as integers ranging from $0$ to $k-1$), and also assign each share you want to generate a distinct non-zero element of the field as a share ID (i.e. the $x$ coordinate at which the share-generating polynomial is evaluated to produce that share).

You then apply the share generation process, which will give you several shares, each consisting of $m$ elements of the field $\mathrm{GF}(k)$ (plus the share ID). By construction, these shares are uniformly distributed and $t-1$ wise independent, where $t$ is the reconstruction threshold parameter of the scheme, meaning that any subset of $s < t$ of the shares is indistinguishable from $s$ sequences of $m$ field elements chosen independently uniformly at random. In particular, as a weak corollary of this, all of the field elements comprising the shares are necessarily uniformly distributed between $0$ and $k-1$, inclusive.

Now, let's say that the secret data that you want to share is binary, and encoded as a string of $n$ bits. If you happen to be using a binary field, such that $k = 2^b$ (and if $n$ is a multiple of $b$), then mapping the secret into a sequence of field elements is very simple: just cut the $n$-bit string into $m = \frac nb$ pieces of $b$ bits, each of which naturally maps to a field element. And since every element of $\mathrm{GF}(2^b)$ also maps unambiguously to a string of $b$ bits, your shares can also be represented as $n$-bit bitstrings (plus the share ID) simply by concatenating (the binary representations of) the field elements in each share.

(If the data length $n$ is variable, and not necessarily an integer multiple of $b$, you might need to apply some padding to unambiguously indicate its length before sharing it, but that's still only a minor complication. And if your data is encoded as eight-bit bytes, and you don't need more than 255 shares, then you can just use $\mathrm{GF}(2^8)$ and skip the padding.)

What if you *don't* want to use a binary field, though? Then you have a couple of options:

Choose the largest $b$ such that $2^b < k$, split the data into $b$-bit pieces, map those into field elements and share them. The main down side of this is that the random field elements in the shares will *not* fit in $b$ bits (since $2^b < k$), so you'll need to encode them using $b+1$ bits each, wasting at least $m$ bits per share. (Variable-length encoding after sharing will not help here, since you can't compress uniformly random data. Variable-length encoding *before* sharing is insecure, since then your share length would leak information about the secret.)

You also cannot arrange both $b$ and $b+1$ to be convenient "round" values like 8, 16, 32, 64, 128 or 256, which means that either your data pieces or share pieces will inevitable have a awkward length. For example, let's say you wanted to want to share 256-bit encryption keys; you could either choose $b = 256$, in which case your shares would be 257 bits long (and, if you wanted to use a prime field, you'd need to do the calculations modulo a 257-bit prime), or $b = 255$, in which case you'd need to split your keys over two field elements, resulting in 512 bit shares. Or you could use, say, $b = 32$ (and, say, the prime field $\mathrm{GF}(2^{32}+15)$, which is a little awkward to work with using 64-bit arithmetic, but not impossibly so, especially if you don't need constant-time execution) and end up with $33 \times 8 = 264$ bit shares after some bit shuffling, which might be a decent middle ground.

Use a general radix conversion from binary to base $k$ to optimally encode your data (i.e. interpret the $n$-bit binary data as a number from $0$ to $2^n-1$, then express that number in base $k$), and an inverse radix conversion from base $k$ to convert the shares back to binary. You'll still waste some bits, so your shares will be longer than the data, but only by a constant amount. The down side is that the radix conversion is slower and more complicated to implement than simple bit shuffling. Also, you'll almost certainly need some kind of a padding scheme if your secret length isn't fixed. (And make sure to always use $m = \lceil n \log_k 2 \rceil$, even if your secret value would fit into fewer base $k$ digits, to avoid the share length leaking information about the secret.)

Now, none of these complications is insurmountable, but they *do* complicate the implementation and make the share encoding less efficient. In comparison, even if you have to implement $\mathrm{GF}(2^b)$ arithmetic from scratch yourself, using a binary field is still simpler.