As well as the visual design, discussed in other answers, it's worth thinking about how back-end choices in the optimisation model can make for a more intuitive system.
One thing that can sometimes be helpful is to consider how the system will react to user decisions, and to try to make that as intuitive as possible.
For example, a couple of years ago I implemented an optimisation-based solution to an economic accounts balancing problem:
- We have tables containing tens of thousands of economic data points.
- This data should satisfy certain consistency rules (if you add up how much every economic sector spends buying cars, and add up how much every sector gets from selling cars, those should be the same number)
- Because of various measurement error issues, the initial estimates don't satisfy those rules.
- Subject matter experts resolve major discrepancies manually, but we need to remove thousands of small discrepancies by automated adjustment.
So the optimisation problem is "find values that satisfy consistency constraints (mostly linear) while minimising changes from the initial values". The big challenge here is that "minimising changes" is fuzzily defined:
- Do we use an absolute-value (linear) measure of change, or squared change (quadratic) for our OF?
- We need to weight these adjustments, because some values are more reliable than others, but this information isn't written down - we can set some reasonable default values but the end users (economic subject matter experts) will need to be able to fine-tune these weights when they spot unreasonable behaviour.
So I wanted to design the system in a way that would make it as intuitive as possible for the users in understanding how their weighting choices would affect the outputs.
This has a couple of implications:
From a usability perspective, a quadratic OF is better than a linear (abs-value) OF here. With a linear OF, solutions will always lie on the vertices of the feasible region. This means that when you make changes to the objective function weights, you might see no change at all to the solution. Or you might see a very large change as the solution moves from one vertex to another, even in response to a very small change in the weights.
By contrast, with a quadratic OF, solutions move gradually as you change the weights. In general, a small change in weights will result in a small but non-zero change to the outputs, and larger changes in weights will drive larger changes to the outputs.
This makes the quadratic OF much more intuitive for a user whose interest is "how do my decisions about the weights affect the final results?"
(There are other good reasons for using a quadratic OF in this problem, but those don't relate to usability.)
The next question is, how should weights be specified? Some back-of-the-envelope work suggests that on average, adjustments to an item will be roughly in proportion to 1/weight for that item. Since my users are more likely to think in terms of "how much can we adjust this?" than "how much should an adjustment cost?" I set things up so that they provide the weighting info in terms of "adjustability" and this is internally transformed into a weight.
Baking these choices into the optimisation model made it a lot easier to provide users with an intuitive interface.
Obviously, there will be many problems where you don't have the luxury of letting usability considerations influence the objective function, but when you do it's worth exploring!
Edit: as requested, some more info on weighting.
The data in question is a system of interrelated tables. The full representation is about five dimensions, but users are normally looking at a two-dimensional slice of the problem. Rows = products (different kinds of goods and services), columns = economic sectors (household, government, export/import, non-profits, 67 different industries, etc. etc.)
Each cell represents the total value bought or sold for that product for that sector in the reference period. In any one of these two-dimensional slices, there are about 24,000 cells, each of which needs a weight.
Our users are familiar with spreadsheets, so that's how they interact with this. For each cell, they specify an "adjustability rating" indicating what they would consider a reasonable adjustment, in percentage terms, relative to the unadjusted value. (Rather than specifying 24,000 values individually, a lot of this is filled in by general rules - "all data from this source gets 10% adjustability", that sort of thing - with the most significant cells getting closer attention.)
A heatmap visualisation of adjustability ratings makes it easier to eyeball the weighting information and see a general pattern of weighting choices.
A macro then converts all the data from the spreadsheet to something the optimisation code can work with. "Percentage adjustability" is multiplied by the unadjusted value to get adjustability in dollars, and then weights are set as 1/adjustability.
In a simple system where we have one constraint $x_1+...+x_n=c$, and our objective function is a sum of $w_ih_i^2$ where $h_i$ is the adjustment made to each value, the $h_i$ will be in proportion to $1/w_i$.
In this complex economic system, any one cell is involved in several different constraints, so this relationship doesn't hold exactly, but it's good enough for an order-of-magnitude approximation.
Once the optimisation is done, we can then "score" the actual adjustments relative to expected adjustments, and then use another heat-map visualisation to give the big picture on what's going on in the table. For example, if we see a prominent horizontal red stripe, that means we're making a lot of big adjustments for one product (rows = products), so our analysts might want to double-check that product and see if anything weird is going on - for instance, there might be some issue that requires manual intervention. OTOH, a vertical stripe means something going on within the sector rather than the product.
Along with that, we do produce a list of unusually large adjustments at sector x product level. But often these are driven by something happening elsewhere, so the heat-map visualisation is helpful in understanding how these individual adjustments relate to the big picture.
The way I approached weighting is to ask users to indicate what they would consider a "reasonable adjustment" for each of these cells, as a percentage of the original value. .
