This diagram is unfortunately ambiguous and misleading.

• Login screen sends a message like Redirect to AppDashBoard to the actor. Does this mean that your system just tells the user that he/she should go to AppDashBoard ? In fact, does the actor do anything with the message at all: isn't it your system that will display another windows or another page regardless of what the user is doing? You have to avoid this.
• More generally, by the book, actors should in principle not appear in a sequence diagram, even if it's a common practice. When you use actors in sequence diagram as explained here, then be at least careful with messages exchanged with the actor. If you have some clear messages that correspond to information content provided to or by the actor, the sequence diagram stays understandable. But otherwise, it's quickly only wishful thinking that has nothing to do with UML semantics.
• By the way, a minor issue in your diagram: The interaction constraint that guard operands in an alt fragment (e.g. [if user authenticated] ) shall cover the lifeline that should react first, as explained here. In your case this is a minor issue, since we can easily find out that it should be the account database.
• Finally, if Registration and AppDashBoard are UI elements, it would be helpful to distinguish them from other elements that are not visible to the user. You may for example use a stereotype such as «Boundary», or even more concrete ones like «Dialogue window» or «Webpage» (you may freely define those in an ad-hoc profile).

Not fully clear how you want this scenario to work. I wonder if there would not be a nested alt block.

Edit: your second diagram

You're revised diagram

Your revised diagram is much more understandable: first messages for the user now correspond to feedback made by the UI. Then it shows immediately the interaction between UI elements and classes behind the scene. Finally, it also allows to check robustness (see the wikipedia link: database coordinates application logic behind the scene and it would in the BCE logic be a “controller”, and controller should not speak to actors).

Now, I think you are ready to continue with your modelling and your project.

Some further suggestions

• I’d put the second alternate in a nested box in the else operand (i.e. the dotted region) of the first one. This makes the relationship clearer.
• Then I wonder if the user could not anyhow click on "Sign up" instead of starting entering the login information. I wonder if it would not make it much clearer, then, to have two separate (and simpler to read diagrams).
• Last but not least security experts would advise you never to tell that the user name is ok but password incorrect.

It would then look somewhat like this:

Don't design UI with UML

UML is great! But it's the wrong tool for UI design. It's like typeing text with a hammer on the keyboard: a very simple UI design like here looks terribly complicated in UML.

Design the big picture of the user journey using wireframes, storyboards, or a combination of several techniques and easy-to-understand user flows. This will facilitate discussion with more stakeholders and allow to show much faster the interaction between user-interface elements and the actor. Then, in a separate step you can design in UML the interaction between classes involved. You may prefer to focus on the more difficult interactions and the less obvious ones between boundaries and controls) and not loose too much time for very trivial ones.