Sascha,

Is this for a system you've already implemented? It sounds like it might be, as you mention 'already implemented use cases', which to me sound like they could be called 'features'.

You mention SMEs; are these customers or just experts at large?

Our use cases are devised by interviewing customers, and in the process gaining an understanding of problems the customer is encountering with our product, or even things he would like our product to do, instead of using his manual workaround.

The goal of this interview is to develop use cases that are solutions to the problems the customer has identified.

The fact that we have worked together with customers in effect validates our use cases, as it gives us the market evidence we need.

Hope that helps.

Hi Sascha, welcome to UX Exchange.

Firstly, I'm unsure what you mean by dependencies between new and already implemented use cases. What dependencies could there be? Sounds like what you're described is evaluating the alignment of an existing system with user goals to determine if the product is fit for purpose; and then out of that gap analysis you would generate your new use cases to modify and extent the system.

How do the use cases tie in to user research and testing? Are you just dealing with hypothetical? What evidence do you draw upon to help define the user modelling?

Bit concerned about your reference to birds eye view - conceptual modelling and increasing detail iterative design is ok, but if you're locking in system architecture prior to considering users then that's going to limit the scope of your user archetype exploration activities.

Hi Sascha

Overall it sounds to me like you have a pretty strong approach.

In my experience the methods used to validate use cases is much less important than the methods used to generate them in the first place. The key to success is that your use cases (scenarios/user stories) have been derived from solid user research, align to strategic business objectives and account for technical constraints.

The validation workshop with SMEs sounds like a really good method to make sure that the project is heading in the right direction and should ensure that key stakeholders are engaged and informed. If you are defining and communicating a UX strategy and sharing research insight, this would be the opportunity to get buy-in.

I'd make sure that the SMEs you invite are truly representative and include individuals from all stakeholder groups (end users, project team, technical staff, business sponsors, etc). The trick is to include the right people at the right time and to ensure that the sessions do not turn into 'design by committee'. It also helps to keep the same people involved throughout the project to maintain momentum and so that you achieve consistency in terms of vision and approach.

Cheers
R