Context & Constraints —
The deadline crept on us.
There was a plan to turn an outdated data market, that was planned and designed for internal usage, to a new one with easy customer access, open for various providers and it needed to be up and running in a year. The roadmap was tight as the plan was just to adjust an up and running API platform, but as the business requirements were pouring in it was slowly dawning on the team, "this will not be doable." "We'll need a new platform" that will merge the API and data marketplace and it will need to be built from the ground up.
4 months before deadline, there was a sudden realisation. We have no way to admin that platform. The business requirements for that part were vague, the ops team (team handling admin section of the app) weren't quite informed that this is happening, and didn't know they need to provide requirements. The notion was it'll be a quick and easy task.
Then the floodgate was opened with business requirements from ops. The complexity was just building on itself. I was tasked to do the design for it in 2 weeks. It went longer than that but you'll see why.
Research —
Large, friendly letters: do not panic
Beside business requirements and an access to the functioning web app we had nothing. No data was collected. Usage, painpoints, flows were not accessible via data. Next best thing: remote contextual inquiry. As the team was a couple hundred km from me, I ran video calls to observe how they work, what they actually use, and how. Watching over screenshare, asking questions as they went.
The info gathered was a bit shocking. The old app was built by engineers, and there were no plans to make it more user friendly. Beside that it was built with zero automation in mind. All manual. The naming in the lifecycle of an order was confusing. Functions that were dangerous. For instance re-activating deleted/canceled/refused order was one misclick away. While the webapp was internal only, fine, but this cannot happen with highly important/expensive data once we open for public. Some functions needed the operator to go back and forth a couple of times on pages, copy paste data to notepad and then fill in forms. And so much more. Oh my… This was not just capturing how the app works and fixing some friction points anymore. This was a huge task redesigning the whole flow to make it more secure/easier to use.
- Engineer-built UI, UX was not invited to the party
- 10 lifecycle states with names that made sense to... someone, probably
- One misclick away from reviving canceled orders (what could go wrong?)
- All manual — automation was a myth
- Entitlements added per user (50 users = 50 manual actions, yes really)
- User and company info split across screens — enjoy the scavenger hunt
- Copy-paste to notepad, back and forth, like it's 1999
Stakeholder Requirements —
No time to push, we're going to make it more complex…
Some parts needed to stay manual. Some for reasons understandable. We are selling trading data, with geo limitations we need to double-triple check who can access it — VPNs exist, company info can be faked, but a legit email is harder to spoof. We can fast track the process when we have that but until then some security processes stay.
Some for reasons not fathomable. Sales as stakeholder insisted that subscriptions need to be completely manual. User can request subscription but it is not just manual check of the user. It is manually set up. No automation (that record will change, but that is another story I can write about). Nada. Zip. Nothing. Not even prolongation of existing subscription.
Well we didn't want to build the app only to rebuild it in 6 months as we didn't think about making it better. "We are going to make it manual" but as easy as possible to make it automatic (again with security checks). Oh yeah some reading this are yelling in their mind check users when they sign up… Tech limit using 3rd party Auth. So no. "Complex it is"…
Technical Constraints —
Actually we need to cut down on complexity
Really. For f.....ox sake. I just got the reader with me. Well yes. I was working with tech lead on the project, he was slowly transitioning to be product owner and unfortunately PM also (poor guy was stretched across three roles). For first draft do the ideal flow in wireframes. And then "we'll see."
"We'll see" equalled to "it is excellent UX, but we cannot do screens nesting so functions need to open in new tab. We need to reuse as much as possible elements." What that meant was thinking like a sys admin. And fighting for some functions till I could. But letting go the ones that technically couldn't be done in 2 months…
The requirements were written per design, so I worked as free as I could in limits that sometimes felt like a straightjacket. But seniority also comes with knowledge. If there was no product, if it was cut, then there was nothing to improve. So cursing in languages no one can understand was the price to pay, but the job got done.
Design Solution —
Skip this part if you are easily bored, but it is important
Now I will focus on the requirements, because without them the screenshots will not make any sense. I will put in more screenshots than needed just to showcase the complexity of the task and to convey the feel of hopelessness in so tight a deadline, but this is nothing but maybe a 1/5th of all screens produced in that timeline, and I will focus only on orders happy path.
Orders can have different states:
- Created — Order is created by the user and this is just a safety state, if the system fails, it will not stay here it moves to a semi state confirmation needed. If ops wants they can see orders here only in their next semi state. If it is in created state there is an issue and flags need to be raised.
- Confirmed — Order passed the verification from ops, this is also a safety state if anything is there flags need to be raised, order needs to move to next state which can be either processing or completed.
- Processing — The order has manual entitlement, with special rules, operator needs to do it.
- Completed — Order was completed, user can enjoy his purchase. Ledgers are there for ops to see.
- Rejected — There was something fishy, ops rejected the order.
There are in between states when the order is waiting some input from ops. While this is the area where they work the most it is put together to one tab action required. It can be awaiting confirmation (which has no other tab on purpose) and processing.
Picture 1: Orders page
Order happy path
User makes an order. The order is created and goes immediately to action required - awaiting confirmation. All orders need to be confirmed. Fast tracking rules cut due to time limit. Operator opens the order, if needed verifies the account. Operator checks if the order is paid (orders exceeding 9500 euro pricetag are bank transfer only).
1. No manual entitlements
The operator sees the following screen and the button states confirm order and finish. This is made to make it clear confirming this order here and now is the last step operator will take regarding this order. After this it is confirmed and user can use the products.
On the image below you can see the information hierarchy based on ops input: what they need to verify first at the top, product/pricing details at the bottom.
Order creator needs verified email — if it doesn't match company, red flag. Users can enter any company name, so we check if they're actually part of that company on record. Separate sections make comparison easier.
They don't impact confirmation at all — security measures trigger before order is made, not here.
Operator confirms order, he is put back to main screen tab Action needed open.
2. Manual entitlements
This is the screen operator sees for confirming this order. The button states Confirm order and continue with entitlements. This informs operator there are more steps after this, this is not the last step. The information hierarchy is again focused on confirmation, the rest is here but less important.
It conveyed the message clearly and didn't confuse ops — other suggestions we tested did.
Operator confirms the order, he is moved to next screen. Now the tech limits come into play. The screen needed to stay as much the same as the previous. This would be less frequent (expected less than 5% of orders), we had no time to make special screens for this action. The on top button states set entitlements and finish, notifying users what is expected here.
That info isn't needed for this action. But due to tech limits, if operator wants to check something (though he shouldn't — he can't cancel anymore at this point), it's still accessible.
Entitlements granted section is now open where operator can add entitlements. It is done in a separate screen which also changes depending on the entitlement, unfortunately I have no screenshot of that screen called create entitlement.
Tech constraint. Embedding would require redoing frontend code across all pages. Separate screen uses the same code called from different points — entitlements are also used in subscriptions.
When he finishes those entitlements are created and user can enjoy them.
When order is created ops can always open a "ledger" what was ordered. The entitlements are not linked to this ledger also because of time and tech limits.
Picture 6 & 7: Orders ledger
- Ability to mark order by operator as claimed, so no confusion is there who is on top of that
- Comment section (leave comments on decisions)
- Linking entitlements (may be too hard)
- Fast tracking
- And some I may have forgot
Results & Impact —
Why is this better
You never showed us the original. I hear you.
The lifecycle flow is now one way — no accidental "revival" of canceled orders, streamlined from 10 confusing states to 5 clear ones.
Entitlements are now per company. A 50-person order went from 50 manual actions to one. Operator only approves once.
All details of users and company are in one place. Before they were in separate spaces — operator needed to check two places to confirm legitimacy.
Cut down time needed to confirm order on average. All because we listened. There are ideas to even improve this time cut further.
Option to link business id and thus verifying account from the order… it was not possible before. Some I may have forgot, it was a year ago.
Reflection —
All stories end, even boring ones like this
To recapitulate, even with strict time limits, not listening to users wasn't an option. Because of that we saw the pains of the process they have, I had the chance to make their life easier, sacrificing something along the way but all with clear vision what we need to do to make this start to work and then improve.
What would I do differently?
A lot... but hindsight is 20/20. The task was on the roadmap but its importance wasn't clearly communicated. Tbh we were in the dark, focusing on other tasks as the time clicked away. One thing I would skip is the "design the best flow" phase. Now knowing how much was cut, it was a waste of time. Also the wireframing for stakeholders... lost 3 days for nothing. We had a good design system, good building blocks — in those 3 days I could do almost pixel-perfect designs and fix them later. They were so focused on visuals that it hurt my brain. I guess "don't focus on visuals, it's bad on purpose so you can focus on functionality" at the beginning of that meeting didn't help.
What did this project teach me?
Stress management became a skill. Jokes aside: patience. I was aware that perfect design doesn't exist, but this deepened that. Made new levels with teammates — "foxhole friends."
Any surprises?
That's a standard question case studies have, and if it's not clear from the text, this was a barrage of slaps behind every corner. But now, behind it, I can say I lived through it.
Going forward?
I know how to handle impossible deadlines, learned when to push for a feature, when to "lose" one, and how to ask for help.