User Interface Requirements in User Stories

Question

I'm not sure whether this should be on the ux.stackexchange forum or on here.

As part of a Uni project, the client has given us a brief of mandatory and optional features, from which we have to build user stories. One of the mandatory requirements is that each account type should have a different UI design.

How do you break this down into a user story and functionality before the development has begun? Could it simply be a high level user story that will be broken down later on? If so, I'm a bit confused as to what the 'so that..' would say.

It's worth noting that we have to follow the conventional user story structure.

Answer 1

There exist different kinds of requirements

• Functional requirements describe features or behaviour that the system must support
• Non-functional requirements describe capabilities of the system, such as performance, maintainability, security, etc.
• Constraints are requirements that limit your design freedom, such as requirements which technology stack to use or that it must be a web-application.

User stories are great for capturing functional requirements. They are a lot harder to apply on non-functional requirements and downright impossible for constraints. That is because constraints and certain types of non-functional requirements affect all user stories. They can't be worked on on their own and you can never say that they are "done."

The requirement that different types of users must have a different look-and-feel to their UI is a constraint type of requirement, because it does not describe something that benefits the user of the system (unless there are other requirements that add context to make the benefits clear), but it does restrict your freedom in designing the system.

As constraints don't lend themselves for user-story format, I would advise you to clearly label the requirement as a constraint and not try to re-write it as a user story.

Answer 2

I think this answer shows well what you could do. First ask yourself these questions:

Does this story, by itself, deliver value?

Is there any possible way to do anything less, and still deliver value?

If the answer to the first is 'no', then you've broken it down too far... or else it's something you shouldn't be working on at all. If the answer to the second is 'yes', then you haven't broken it down enough.

Once you've got yourself a minimum-sized story that, by itself, provides value, all you then need to do is answer (and document in the story) the following two questions:

To whom does this story provide value?

How does this story provide value?

If you cannot answer either of those questions, you may want to revisit the 'does this story, by itself, deliver value' question.

Answer 3

I would probably create separate user stories to capture each unique account type and its related UI design, Acceptance Criteria and dependencies. This way you could run each story separately and track the successful completion of each account type.

If there are some common code artifacts that each story can use and build upon, separate that work into its own story and run it first.

This break down would allow your QA team to be able to test each unique account type UI separately and determine if the work is complete and meets the acceptance criteria.