User Story - possible issues

You're absolutely correct Katharina. A user story describes a small piece of functionality and are often part of a bigger picture. 

The Product Backlog can (and should) contain more items than just user stories. I always encourage teams to find what is best to describe and understand their work. That could be a business process flow with user stories tied to it, a user story map, technical documents or UML diagrams, etc. 

Roman Pichler wrote a great blog post around user stories not being enough for a great user experience. It's a great read if you have a few minutes. 

https://www.romanpichler.com/blog/user-stories-enough-for-a-great-user-experience/

Which issues do you see regarding following user story: "As a user, I want to have the whole work flow unified according latest design guidelines, so it feels modern."

For me the story is not concrete enough, it's too "big", it's more an epic then a user story. Right? What else. Thank you so much.

@Katharina Kluge, Who is the user?

As a user I want to have the whole work flow unified according latest design guidelines, so it feels modern.

I agree with Steve, when the user is not identified and if every user story begins "As a user..." then what is the point?

The way way this is written, sounds more like a solution. Would a user really ask for latest design guidelines? What problem will this solve? The user story should help build empathy and a connection for the Scrum Team doing the work.

And as others have stated, you don't always have to use a 'user story', Scrum doesn't prescribe it. I would encourage experimentation with other formats, such as hypothesis drive development. Example format:

We believe [doing this] for [these people] will achieve [this outcome].

We will know that this is true when we see [this measure changed]

It's sometimes said that user stories are a placeholder for a conversation.

And maybe your example is enough to start a useful conversation within the Scrum Team or with stakeholders.

Some teams find it useful to adjust user stories throughout refinement, in order to validate their continuously enhanced understanding of the problem and solution.

e.g it may evolve into something like:

As a manager, who only occasionally logs into the software, I want a modern, consistent, and well designed work flow, so that I am able to get the 5 pieces of data I need within 30 seconds.

Or:

As the decision maker who will make the final call on whether we purchase the software, I want to experience a modern, consistent, and well designed work flow, so that I have strong evidence that my team are going to be able to use the product effectively.

It's debatable whether these are great user stories, but they could be useful in helping a team align around requirements and objectives, and may form the basis of some measurable outcomes that the Scrum Team will want to achieve.

Whether they're too big or not to be a single item on the Product Backlog is something I'd expect the Scrum Team to discuss. The Development Team should be the ones to estimate the size of work. The Product Owner is likely to consider the potential return on investment, and how to maximize the flow of value; and this collaboration would often see large Product Backlog Items broken down into multiple smaller ones.

Whether each smaller item would be expressed as a user story, is likely to depend on what the Product Owner considers appropriate for the Product Backlog, and that could be based on what enables the most effective communication within the Scrum Team and with stakeholders.

In any case, it's very unlikely that a complex problem can be solved just by expressing one or two sentences. Whether done during refinement, or later, it's likely that other techniques will also be needed, such as producing wireframes and mockups, or expressing behaviours in a Given-When-Then format.

My first reaction was how would the user know the "latest design guidelines"?  

It is way to broad but as other have said, it is enough to start a refinement conversation.  I wouldn't expect this story to be refined quickly because of it vagueness. In reality, the question you asked all of us should be directed toward the Scrum Team that would be dealing with solving the problem.  As a group, refine it to a point where everyone understands it.  That refinement may include breaking it into multiple smaller stories so that they can be accomplished during Sprints.

Crafting User Stories is not a science.  It is an art.  And artists get better by attempting things, learning from it and refining their skills over time.