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.

  • Possible duplicate, at the very least worth a read: pm.stackexchange.com/questions/20239/…
    – Sarov
    Commented Feb 6, 2017 at 21:53
  • The link concerns decomposing stories, but my questions is focusing on the topic of UI requirements and how to capture that in a story.
    – Hawwa
    Commented Feb 6, 2017 at 21:58
  • 1
    Is there a business value associated with each account type having a different UI design? Commented Feb 7, 2017 at 18:43
  • @BarnabyGolden It's just required by the client and they didn't really expand on any business value
    – Hawwa
    Commented Feb 8, 2017 at 14:36
  • 1
    That makes it difficult to answer the question. The 'so that...' part of a user story typically refers to the value the business derives from completing the story. I could imagine something like: "As a website user I want to easily identify I am logged in as a super user so that I don't accidentally delete a page". But without knowing what the client wants it is difficult to complete the story. Commented Feb 8, 2017 at 20:09

3 Answers 3


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.


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.


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.

  • is acceptance criteria linked to definition of done?
    – Hawwa
    Commented Feb 12, 2017 at 1:01
  • Acceptance criteria are the things that has been agreed upon and must be exhibited in the final delivery of the story. These can include negative requirements too (things that the software is not supposed to do). Acceptance criteria can also be used by your QA team and during the demo for acceptance by the product owner.
    – FrankO
    Commented Feb 14, 2017 at 1:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.