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.
13 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 “Your next order,” hide technical detail, show only decisions that need attention, and make inbound orders part of the same simple loop.
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: Buy, Review, No action | 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 | Review → approve/edit → send → track incoming | Closes the real work loop and makes the next action obvious after Tim sends the order. |
| 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—“24 products need review” or “Nothing urgent”—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 “Your next order” or “Nothing urgent,” 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 the loop visible
Make review, export, sent orders, incoming stock, and reconciliation feel like one continuous task.
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.
High-fidelity target prototype
What the redesigned flow could feel like
Target screens for the weekly buying flow. Use the numbered tabs to preview each stage.
● Data is ready Items, stock and sales updated todayRefresh
Your next order
24 products need review — Tuesday, 13 August
24Need ordering
7Review first
3Orders incoming
Ready to reviewSorted by urgency — 24 lines
SKUProductAvailableCoverSuggestedState
175/65R15Michelin Energy Saver41.2 wks12BUY
205/55R16Michelin Primacy 472.0 wks8BUY
225/45R17Michelin Pilot Sport——CheckREVIEW
Select a line for details.
Purpose: answer “What needs my attention today?” before Tim sees configuration, diagnostics, or the full catalogue.
Suggested buys
Review and edit quantities.
Products to reviewMichelin Australia
SKUProductCoverSuggestedFinalState
175/65R15Energy Saver1.2 wks1212BUY
205/55R16Primacy 42.0 wks88BUY
225/45R17Pilot Sport———REVIEW
235/45R18Primacy SUV9.4 wks00NO ACTION
Nothing sends until you export.
Purpose: compare proposed quantities in one table; select a line when Tim needs the calculation.
Review and send
Check quantities before export.
SupplierMichelin Australia
Order lines24
Total units312
Order linesFinal quantities
SKUProductSupplierQtyReason
175/65R15Energy SaverMichelin12Below target
205/55R16Primacy 4Michelin8Below target
235/45R18Primacy SUVMichelin0No action
Purpose: make the commitment point explicit. Tim sees the supplier, line count, final quantities, and what will happen when he exports.
Incoming
Track open orders and outstanding units.
3Open orders
84Units incoming
1Needs checking
Open supplier ordersLast updated today
OrderSupplierETAProgressStatus
ORD-071212 lines, 42 unitsMichelin Australia18 Aug
24 received, 18 openPART RECEIVED
ORD-07285 lines, 27 unitsMichelin Australia22 Aug
27 openOPEN
ORD-07313 lines, 15 unitsMichelin AustraliaUnknown
5 received, 10 openCHECK
Incoming stock is counted once. Mismatches need review.
Purpose: make the follow-through part of the same product. Tim can see open orders, update receipts, and resolve supplier differences without hunting through a technical expander.
Design test: if Tim can open the Today screen, understand what needs attention, explain one suggested quantity, export the order, and find it later under Incoming, the redesign is doing its job.