Findings report · 30 July 2026
We wanted to see what we would learn by taking feature requests beyond a title and vote count. So we collected 380 ideas, chose eleven, built a working mockup for each one, and filmed the result. This report covers what changed once we tried to make the ideas real, and what the process taught us about Nolan.
Votes showed us where there was interest. Building showed us what each request would involve.
The same pattern appeared across all eleven requests. A vote count can show that people want a problem addressed, but it says little about the work or trade-offs involved. The board sorts requests by votes, so it is easy to read a high number as a reason to build something next. But the ranking did not predict which ideas were simple, which needed a different solution, or which affected other parts of the product.
The results do not follow the vote count. Requests with 694 and 142 votes both came with wider trade-offs. Requests with 444 and 103 votes both worked much as written. Adding a second approval level to bills was the largest change in this set, even though it had the fewest votes. It would affect bill statuses, audit history, and bills that had already been approved.
That makes sense once the two measures are separated. Votes reflect interest in a problem. The effort and risk depend on how much of the product a change touches. Looking at votes alone leaves that second part of the decision unexplored.
Two requests worked as written, four led us to a different solution, and five had wider consequences.
Before making the mockups, we agreed that each request would end with one of three results. We could build it as requested, keep the problem but change the proposed solution, or show a consequence that would need a product decision.
Payer names on a reconciliation row and a default for the Approve button are both small changes with clear precedents elsewhere in the product. Neither required a larger redesign. The Approve default, for example, is a setting and a button-label change that makes the safer action easier to choose.
In these cases, the problem was clear but the suggested interface change would not do enough to solve it. Payment method on bills is the clearest example. Another column would display the method, but the mistake described in the request happens earlier. The mockup moves the decision to the point where the person can still prevent the error.
These requests are possible to build, but each one affects more than the original description suggests. Unapproving a sales invoice can leave Xero out of step with a document the customer already holds. Custom fields would be of limited use if they appeared in the editor but not on the PDF sent to the customer. Splitting a batch payment changes the identity of a payment after a remittance advice may already have been sent.
Two requests also overlap with work Xero has already committed to. Switching autosave off sits awkwardly beside a separate plan to move the Save button to the bottom of the invoice. That idea is In development with 247 votes. Xero has also Accepted an unapprove option for bills, so the question is why the same action may be suitable for bills but more complicated for invoices.
Similar requests can appear in different forums and receive different answers.
We found this while comparing requests across the seven forums in our sample. The board ranks ideas by votes within each forum. When the same need is filed in two places, each version is counted and considered separately. The two requests can even receive different decisions without either page referring to the other.
Simply merging similar requests and adding their votes would create a new problem: it would treat different requests as if everyone had supported the same proposal. Software can help find possible matches, but it cannot make that judgement reliably. Our comparison of 380 titles found roughly fifty possible pairs, and only about six were genuine matches. Small changes to the matching rules also changed which pairs appeared.
The useful improvement would be to show related requests together. That would let people see when the same need appears in several places, and when those requests have received different answers, without pretending they are identical.
We copied individual facts accurately. We made mistakes when we combined and compared them.
Before publishing, we checked roughly 190 source details: vote counts, statuses, titles, links, forum names, and 36 direct quotations. None of those source details was wrong.
We were much less reliable when we started combining those facts. Of 38 statements involving totals, rankings, group sizes, or percentages, ten were wrong. Six of eight claims about the structure of the dataset were also wrong. We made four incorrect claims that something was the highest or largest, and another six went beyond what our sample could support. In three places, we called one request the highest-voted in the sample when it was actually second.
The mistakes appeared when we moved from facts to comparisons. A total, ranking, or claim about the largest item depends on what has been included. Our sample contains 380 of roughly 6,000 ideas, so it cannot support a claim about the whole board. We now state the limits of the sample alongside the numbers instead of leaving the reader to infer them.
Moving setup text out of the captions made every film shorter and easier to follow.
Nolan is the browser-filming tool used to make these walkthroughs. It can put text in several places, including title frames and timed captions. Our first versions put all of the introductory context into captions.
That made the films longer and forced each caption to explain the request while the interface was already moving. Once we moved the setup to a title frame, the average film became 22 seconds shorter. It also left the captions free to explain what was happening on screen.
| Approach | Mean film | Longest | Review result |
|---|---|---|---|
| Setup in captions | 87s | 113s | Repeated warnings |
| Setup on a title frame | 65s | 75s | Passed |
| As shipped | 67s | 79s | Passed in strict mode |
We did not need a new feature in the filming tool. We needed a clearer job for each kind of text. Title frames now explain the request, captions describe the action, and the final frame explains what the walkthrough revealed.
Each page includes the original problem, the filmed walkthrough, and the reasoning behind our response.
| Request | Votes | Board status | Assessment | Film |
|---|---|---|---|---|
| Payer names instead of “multiple items” | 103 | submitted | As requested | 61.4s |
| Select default for the Approve button | 444 | Not in pipeline | As requested | 58.3s |
| Payment method on bills | 222 | submitted | Different solution | 69.3s |
| Add subtotals | 348 | Not in pipeline | Different solution | 63.6s |
| Search across all bank accounts | 250 | Not in pipeline | Different solution | 61.7s |
| Demand split across forums | — | Not on the board | Different solution | 68.2s |
| Multiple levels of approval for bills | 142 | submitted | Wider trade-offs | 78.7s |
| Split a batch payment when reconciling | 345 | Not in pipeline | Wider trade-offs | 70.6s |
| Option to switch autosave off | 480 | Not in pipeline | Wider trade-offs | 68.9s |
| Unapprove option | 518 | Not in pipeline | Wider trade-offs | 71.6s |
| Custom fields on invoices and contacts | 694 | Not in pipeline | Wider trade-offs | 68.1s |
It shows interest in a problem. The rest still needs investigation.
A vote shows that someone wants the problem addressed. More votes show that more people chose to support the request. The number does not tell us how serious the problem is, whether the suggested solution is the right one, or what else would need to change. The walkthroughs add that missing context by placing each request inside the product and making its benefits and trade-offs easier to discuss.