I think this is great question and one that many people are actually faced with. It's actually a product management question and I agree that a lot of times an example of a user interface is where it all starts. But we have to be careful that that is not where it ends.
Vision
Before you start, there needs to exist a vision for the website, and that needs to be communicated with the development team. You might already have this but its worth mentioning as it gives the stories context. For example, is the website B2C or B2B, what do you sell? are you a reseller or marketplace website ? Some essential domain knowledge is important too, so things like what product variations are there ? Include something about your buyers, are they trade ( in which case prices might be ex-VAT ) or general public ? Also talk about how the business makes money, your pricing and marketing strategy, etc.
Users
You also need to decide on the types of users you are serving. You might have, first time users, members, admins, high-value, low-value, any buyer, trader etc. This is normally done with the product manager, but the product owner or UX person can do it too.
Features
So, assuming you already have all that in place, the first thing to do is to think about the types of stories, you will have business stories ( stuff that the end user sees ) and technical stories ( stuff that needs to be built to support the business stories ). The trick is to start with the business stories. You can organise these stories into features remembering business features can have business and technical stories whereas technical features contain mostly technical stories.
Business Stories
So in the business stories, there are some obvious things like "add to basket" and that is another trap, what is obvious and what is not!! I don't know what your role is but you should really encourage the product manager to decide that and write it down.
Now, you can facilitate your PO in writing out some requirements such as
Story: Add product to basket
As a [user type], given I have chosen [variation] of product, then I can see the price and add it to my basket.
Depending on your particular domain this story might actually need to be broken out into smaller chunks, for example.
Story: Select product variation to see price
As a "general public user", when I am on a product information page, given I have selected a product variation, then I can see the price.
Story: Select quantity after product variation
As a "general public user", when I am on a product information page, given I have selected a product variation, then I can select a quantity.
Story: Product in stock
As a "general public user", when I am on a product information page, given that the product is in stock, then I can add it to my basket.
Story: Add product to basket
As a "general public user", when I am on a product information page, given I can see a price, then I can add it to my basket.
MVP
You will end up with a massive list of stories so organising by feature is important. At that point, the product owner will prioritise and define the potential MVP. So for, example, you might not include the "in stock" story in the MVP. This is the first sweep, because we don't have any technical stories.
Technical Stories
I normally recommend that technical stories are added after you have a vague outline of a MVP. So now the PO gets together with the development team and technical stories are added. There may well be research stories needed or architecture decisions that need to be captured at this stage depending on the maturity of your system.
Estimates
Now all the the stories which are potentially in the MVP can be estimated.
Final MVP
This will naturally mean there is an iteration of what can be accomplished in the MVP, so the team decide together, given the constraints in time and skills available what should be the target for the MVP.
et voila, you have an MVP with prioritised stories. Depending on current state of team and backlog, this process can take up to 2 weeks.
