LIVE NOW
What is implemented
A Streamlit page loads data, calculates suggested quantities, shows a replenishment table, lets Tim edit final quantities, exports an order CSV, and stores open-order notes.
14 Aug 2026
Tim’s dashboard — current state
The app is a buying workbench.
It is trying to turn stock, sales, supplier files, and ordering rules into a short list of products Tim can review and order. It is not yet a full inventory system, customer relationship manager, or automatic purchasing system.
Implemented now: replenishment recommendationsAPI + uploadsPilot: Tim reviews and gives feedbackHuman approval stays in the loop
Three things to keep separate
Live app, intended pilot, future redesign
The current page is useful but overloaded because it mixes the working tool, technical controls, and future product ideas. This is the clean distinction.
INTENDED PILOT USE
What Tim is expected to do
Open the app, check the data, review the short list, change anything that looks wrong, send the order, and tell us what was confusing or inaccurate.
NOT LIVE YET
What the redesign should do
Start with “To order,” hide technical detail, show management signals in “Overview,” and make “Inventory” the place to investigate a product.
Current function set
What the app can do today
These are the current functions, translated into the job they perform for Tim.
01 / DATA
Load the product list
Use the data-center API for the MYOB item master, or upload an item export as an override or fallback.
02 / DATA
Load current stock
Bring in on-hand, on-order, committed, and available quantities from MYOB stock data.
03 / DATA
Load sales history
Use API sales data, a local cache, or uploaded sales files to estimate how quickly each product sells.
04 / SETTINGS
Set the planning rules
Choose lead time, safety stock, and the sales period used to estimate demand.
05 / DECISION
Suggest what to buy
Compare target stock with current coverage and apply MYOB reorder quantities to produce a suggested quantity.
06 / TRUST
Flag problems
Call out negative available stock, suspicious inputs, order mismatches, and items that cannot be matched safely.
07 / ACTION
Review and edit
Filter the replenishment table, inspect a product, and change the final quantity before sending anything.
08 / FOLLOW-THROUGH
Export and track
Download a supplier-ready CSV, optionally save it as an open order, then update received quantity, ETA, status, and notes.
The current UI
What Tim sees today
The page is one long workbench. The left sidebar contains setup and data controls. The main area contains the decision table and several technical or follow-up sections below it.
Derwent Ordering DashboardStreamlit page — one long workbench
—Total SKUs
—Need reorder
—Negative available
—Total suggested qty
Review may be needed. Some rows have flags or unusual inputs.Inspect flagged SKUs
Replenishment table
SKUProductAvailableIncomingSuggestedFinal qty
ITEM-001Example product401212
ITEM-002Another product181000
ITEM-003Flagged product——Review—
This is a structural map, not a screenshot. The exact counts and rows change with Tim’s data.
Intended pilot workflow
How we expect Tim to use it now
The pilot asks Tim to test the proposed order.
01OPEN
Load the dashboard
The API should load items, stock, and sales. Uploads remain available when a source needs to be overridden.
02CHECK
Confirm the data
Look for source errors, missing sales, stale cache information, or an unexpected stock picture.
03FOCUS
Find the buy list
Use Need Reorder, the flagged inspector, and table filters to focus on products that need a decision.
04REVIEW
Use judgment
Check the product, available stock, incoming stock, demand, and suggested quantity. Edit Final qty when needed.
05SEND
Export the order
Download the supplier CSV. Save it to the tracker if it represents an order Tim has sent.
06REPORT
Give feedback
Tell us what was right, wrong, missing, slow, or harder than the old process. That feedback shapes the next version.
The expected behavior is not “trust the number.”
It is “use the number as a starting proposal, then tell us whether the facts and the workflow match how Derwent actually buys.”
Feedback we need
What Tim’s use should teach us
Signal
- Did the right products appear on the buy list?
- Were products missing that Tim expected to see?
- Were products included that should be ignored?
Quantity
- Did the suggested quantity make sense?
- What did Tim change?
- Was the reason a formula issue, a data issue, or business judgment?
Data and trust
- Did stock, sales, and incoming quantities look current?
- Could Tim understand why a row was flagged?
- Did the API and supplier file disagree?
Workflow
- Could Tim find the first useful action without help?
- Which controls did he ignore or misunderstand?
- Did export and tracking fit the real buying routine?
Current UI versus intended use
Why the current page feels overwhelming
| What is on the page | What it is for | What Tim should do in the pilot |
|---|---|---|
| Planning inputs in the sidebar | Control lead time, safety stock, and demand assumptions. | Accept the saved defaults unless a real Derwent policy needs changing. Do not treat every control as a required setup step. |
| API status, cache details, and uploads | Make the data source visible and provide a fallback. | Confirm that the data is usable. Upload only when the source needs an override or the API is incomplete. |
| KPI row and flagged warning | Summarize the catalogue and surface possible data problems. | Use “Need reorder” and flags as the entry point. The totals are context, not the work itself. |
| Replenishment table | Put one decision row per product in front of Tim. | Review the short list, inspect why, edit Final qty, and select lines for export. |
| Reconciliation, planner, formulas, diagnostics | Support follow-up, explanation, and troubleshooting. | Use these when a decision needs investigation. They are not supposed to be read top-to-bottom every time. |
JTBD analysis
What job is Tim hiring this app to do?
When it is time to place the next supplier order, Tim wants to know what to buy and why, so he can send an accurate order quickly without checking several reports by hand.
FUNCTIONAL JOB
Make the buying decision
Turn stock, sales, reorder rules, supplier status, and Tim’s judgment into a short list of proposed buys.
EMOTIONAL JOB
Feel safe enough to send
Reduce the fear of missing a product, ordering the wrong quantity, or sending a supplier an order that cannot be explained.
OPERATIONAL JOB
Keep the business moving
Prevent avoidable stockouts while remembering what has already been ordered and what is still coming.
The job sequence and its current friction
| Job step | What Tim needs | Current friction |
|---|---|---|
| Start | Know where to begin today. | The page opens with settings, data-source status, uploads, metrics, and the table competing for attention. |
| Prepare | Know whether the numbers are current enough to use. | API, cache, upload, and fallback states are visible, but they read like technical controls rather than a simple “ready to review” answer. |
| Prioritize | See the products that need a decision first. | The full workbench exposes the whole catalogue and many table controls before Tim reaches the short list. |
| Explain | Understand why the quantity was suggested. | The calculation explanation exists, but the rationale is separated from the row Tim is reviewing. |
| Commit | Change the number if business judgment says so, then send it. | Final quantity editing and export are lower in the page and share space with configuration and diagnostics. |
| Follow through | Remember what was ordered and what arrived. | The tracker and supplier reconciliation are present, but they feel like secondary expanders instead of the next part of the same job. |
UI / UX redesign case
Why the redesign is better
The redesign is better because it organizes the interface around Tim’s job instead of around the system’s internal capabilities. It keeps the calculations and data sources, but changes what receives attention first.
| Current pattern | Redesign pattern | Why it improves the experience |
|---|---|---|
| One long page with everything exposed | Action-first home: “Your next order” | Tim can orient himself immediately. The first screen answers what needs attention instead of asking him to assemble the answer. |
| Settings look like required setup | Saved defaults with a compact “Planning” control | Reduces cognitive load and prevents Tim from feeling that he must understand every assumption before starting. |
| Full catalogue is the main table | Reorder exceptions first; full products are secondary | Matches the weekly job. Tim works the exceptions rather than scanning thousands of rows. |
| Technical flags such as `CHECK_INPUTS` | Plain-language states: Ready to order, Check before ordering, Covered | Uses language that describes the decision Tim must make, not the internal reason code. |
| Calculation explanation is distant from the row | Each line shows a compact “Why this quantity?” detail | Supports trust at the moment of decision and reduces the need to search the page for an explanation. |
| Export and order tracking are lower sections | To order → prepare → track open orders | Closes the real work loop without turning one decision into several duplicated screens. |
| Technical diagnostics are part of the same visual weight | Progressive disclosure under More / Data details | Preserves transparency for troubleshooting without making every user navigate the machinery. |
LESS COGNITIVE LOAD
Orient in seconds
A clear first answer—“17 lines ready to order” or “Nothing needs ordering”—replaces the need to interpret the whole page.
MORE TRUST
See the reason beside the action
Tim can compare available, incoming, demand, and suggested quantity without leaving the decision row.
FASTER REPEAT USE
Keep expertise, hide machinery
Experienced users can still open settings and diagnostics, but the normal weekly path stays short.
The redesign is not “make it prettier.” It is “make the next correct action easier to see, while keeping Tim in control of the final order.”
The redesign target
What should change next
The redesign should keep the current calculation and data integration while changing the first impression and the order of attention.
Start with the decision
Open on “To order” or “Nothing needs ordering,” not on a catalogue of controls.
Use progressive disclosure
Keep settings, uploads, formulas, mapping, and technical logs available but out of the main path.
Keep management close
Give Tim an Overview for signals and trends, while keeping the buying workflow focused on the next correct action.
Bottom line: the current app is a working pilot instrument. Its job is to generate real buying decisions and learn from Tim’s corrections. The next UI should make that loop obvious without changing the underlying goal.
Metric framework
What we can measure now
Effective inventory management balances customer service, money tied up in stock, and ordering discipline. Derwent can show the ordering drivers now. It should wait to show business outcome measures until the underlying events and history are reliable.
| Measure | What it tells Tim | Status | Basis |
|---|---|---|---|
| Products ready to order | How many lines can move straight to quantity review. | Now | Positive suggested quantity with no blocking issue. |
| Products to check | How many lines need a human decision before ordering. | Now | Missing, unusual, negative, unmatched, or conflicting data. |
| Units in this order | The size of the current buying run. | Now | Sum of the editable final order quantities. |
| Stock counted toward target | How much stock can cover demand after commitments and deliveries are counted. | Now | Stock on hand minus committed stock plus incoming stock, counted once. |
| Weeks left | How long the stock counted toward the target may last at the recent sales pace. | Now | Stock counted toward target divided by average units sold per week. |
| Products that may run out soon | Which products may run out before the next delivery. | Now | Derived from stock counted toward target, sales per week, and time before delivery. This is a warning, not a measured stockout rate. |
| Products with extra stock | Which products may have more stock than their current limit. | Now | Requires sales per week and a defined maximum stock horizon. Show as candidates, not confirmed waste. |
| Sales per week | Whether demand is steady, rising, falling, or absent. | Now | Units sold, average per week, last sale date, and monthly history. |
| Orders needing follow-up | What has been ordered, received, or left without a delivery date. | Partly available | Order tracker and supplier files. Not yet a complete supplier record. |
| Data age | Whether Tim can trust the current picture. | Now | Fetch time, sales date range, row counts, and where the data came from. |
| Measure | Why it matters | What is missing |
|---|---|---|
| Orders supplied from stock | Direct service measure: did customers get what was promised from available stock? | Customer orders, delivery outcomes, and approved-stock rules. |
| Stockout rate | Shows how often demand was missed because stock was unavailable. | Lost demand or backorder records. Sales history alone cannot show demand that never happened. |
| How quickly stock sells | Shows how quickly money invested in stock becomes cost of goods sold. | Cost of goods sold, item cost, and historical stock values. |
| Value of extra stock | Shows how much cash may be tied up in stock beyond a sensible limit. | Landed cost, a stock limit, and historical snapshots. |
| Supplier delivery reliability | Shows whether suppliers deliver the right quantity when promised. | Confirmed promise dates, actual receipt dates, and received quantities. |
| Reorder decision quality | Shows whether suggestions and Tim’s overrides lead to better outcomes. | Saved proposals, Tim’s changes, receipts, and later stock or service results. |
Do not show EOQ yet. Economic order quantity needs a credible ordering cost, carrying-cost rate, landed unit cost, and quantity constraints. Those inputs are not complete in the current MYOB-backed model. First measure the current policy and compare it with Tim’s decisions.
Chart placement: a visual sits above the detail it helps the user interpret. Overview puts the product-status bar above its current issues. Inventory puts stock against target above the selected product’s facts. The sales bars stay beside that product’s facts because they explain one order suggestion rather than summarise the whole business.
Customer demand layer
Use customer data to protect demand
Customer sales should add context to an inventory decision, not turn the weekly buying page into a CRM. Start inside product detail. Add a separate customer view only when Tim has a recurring follow-up job and the data is trustworthy.
| Metric | What it tells Tim | Status | Needs |
|---|---|---|---|
| Active customers | How many customers bought during the selected period. | Needs customer data | A customer ID that stays the same across imports and a sale date. |
| Days since last order | Which customers may be overdue based on their usual buying pattern. | Needs customer data | Customer ID and separate order dates. |
| Usual order interval | How often a customer normally orders, and whether the gap is changing. | Needs customer data | Customer ID and order or invoice ID so several product lines count as one order. |
| Product demand by customer | Which customers rely on a particular product. | Needs customer data | Customer ID, product code, date, and units. |
| Customer demand at risk | Which customer-product relationships may be affected before the next delivery. | Needs customer data | Customer demand plus stock counted toward target, delivery time, and any customer priority or commitment. |
| Metric | Why it matters | What is missing |
|---|---|---|
| Dependence on large customers | Shows how much of the business depends on the largest customers. | Customer ID plus reliable sales amount; units are a weaker fallback. |
| Average order size | Shows the normal size of a customer order and unusual changes. | Order or invoice ID plus units or sales amount. |
| Sales by customer and product | Shows where revenue comes from and which products support each account. | Customer ID, product code, and line amount. |
| Gross margin by customer and product | Shows which demand is commercially valuable, not just large. | Line amount, item cost, discounts, and returns. |
| Orders supplied from stock | Shows whether important customers received what they ordered. | Customer orders, promised quantities, delivery outcomes, and backorders. |
Important: customer demand is a breakdown of total demand, not extra demand to add to the reorder formula. Use it to prioritise a review, explain a risk, or trigger outreach. Do not count the same units twice.
Data boundary: the current MYOB sales API feed keeps product, date, and units but drops customer, invoice, amount, cost, and transaction identity. The next data-model change should preserve those fields before we display customer KPIs.
High-fidelity target prototype
Four work destinations, one inventory loop
The controls below switch the preview. Inside the app, Tim navigates with the left sidebar. Weekly work lives in To order and Open orders. Management review lives in Overview. Investigation lives in Inventory. Sales history and customer demand stay inside product detail, while Settings stays secondary. The counts below are illustrative; the live app will calculate them from current data.
Data is up to dateStock updated 13 Aug 2026Sales through 31 Jul 2026
To order
Supplier: Michelin Australia
Review the quantities before you send the order.
17 products ready to order7 need a check312 units in this order
ProductAvailable nowComing inWeeks leftSuggested orderOrder quantityStatus
205/55R16Michelin Primacy 4722.0 wks88Ready to order
175/65R15Michelin Energy Saver401.2 wks1212Ready to order
225/45R17Michelin Pilot Sport—————Check before ordering
Products with enough stock are hidden. Choose All active products to see them.
17 products selected312 units in this order
To order: each row is one product decision. Prepare order creates the supplier order file from this same page.
3 open ordersLast updated 13 Aug 2026
Open orders
Track what suppliers have sent and what has arrived.
3 open orders55 units not yet received1 needs checking
OrderSupplierSentReceivedExpected dateStatus
ORD-071212 products, 42 unitsMichelin Australia12 Aug 24 received, 18 open18 AugPart received
ORD-07285 products, 27 unitsMichelin Australia11 Aug 27 open22 AugOpen
ORD-07313 products, 15 unitsMichelin Australia08 Aug 5 received, 10 openUnknownNeeds checking
Needs checking: ORD-0731 has no confirmed delivery date. Select the order to see its products or record a delivery.
Open orders: a separate follow-up job. Add delivery updates and record what arrived here when needed.
What needs attentionStock and sales through 31 Jul 2026Order tracker updated 13 Aug 2026
Overview
See what needs attention across stock, orders, and sales.
Active product status1,248 active products
No order needed 1,224 Ready to order 17 Check before ordering 7
Needs attentionCurrent issues
Each issue leads to the products or data that need attention.
MR
May run out soon12 products may run out before the next delivery.
12SL
Stock above limit84 products are above the current stock limit.
84OF
Orders to follow up2 open orders have no confirmed delivery date.
2SH
Sales history31 products have old or missing sales history.
31Measures to add laterWhen the data is ready
These measures show whether customer service and money tied up in stock are improving. They need more history than this prototype has.
Orders supplied from stockNeeds customer orders and delivery records.
LaterHow quickly stock sellsNeeds item cost and historical stock values.
LaterValue of extra stockNeeds item cost and a stock limit.
LaterSupplier delivery reliabilityNeeds promised dates and delivery records.
LaterHow to use Overview: current issues lead to action now. Longer-term measures appear only when the underlying events and counts are trustworthy.
Overview: a short management view, not a wall of numbers. Current issues lead to action; historical measures arrive when the data supports them.
Current stock1,248 active productsStock updated 13 Aug 2026
Inventory
Find a product and see what to do next.
1,248 active products17 ready to order7 check before ordering
ProductSupplierAvailable nowComing inWeeks leftNext action
205/55R16Michelin Primacy 4Michelin Australia722.0Ready to order
175/65R15Michelin Energy SaverMichelin Australia401.2Ready to order
225/45R17Michelin Pilot SportMichelin Australia———Check before ordering
235/45R18Michelin Primacy SUVMichelin Australia12248.2No order needed
Inactive products are hidden. Sales history and customer demand appear here because they help explain what to do next.
Inventory: search and inspect a product. Sales history explains the quantity; customer demand shows who may be affected.
Connected dataMYOB product, stock, and sales dataSupplier updates are manual
Settings
Manage data connections and planning rules.
MYOB product listLive
1,248 active products. Code, name, supplier, and reorder settings.
Updated 13 Aug 2026MYOB stockLive
Stock on hand, committed stock, and quantities already on order in MYOB.
Fetched 13 Aug 2026MYOB sales historyLatest saved copy
Units sold through 31 Jul 2026. Used to estimate sales per week.
Last refreshed 13 Aug 2026Supplier delivery updatesAdded manually
Delivery files and confirmed dates are not connected yet.
The order tracker is the current recordPlanning rulesUsed for this order list
Time until delivery6 weeks
Extra stock2 weeks
Sales periodSelected period
How order quantity is setTarget minus stock already counted
What MYOB provides: product, stock, and sales facts. Supplier confirmation, delivery status, and quantities received still need a separate source.
Settings: a secondary page for checking data freshness and the rules behind the order list.
Design decision:the dashboard has four primary work destinations plus Settings. To order and Open orders support weekly work. Overview supports management review. Inventory supports investigation. Sales history and customer context stay inside Inventory detail, and Settings stays secondary. A separate Customers page waits until customer follow-up is a validated recurring job.
Design test: if Tim can buy from To order, follow the result in Open orders, understand business risk in Overview, investigate any product and its affected customers in Inventory, and check the data when needed, the information architecture is doing its job.