Answering your question requires knowing why you were asked to write those tests. Unlike solving applied math problems, we usually do not write automated UI tests for the sheer pleasure or the intellectual challenge. I assume you were asked to write them, in that style, for a reason. If there is a reason to believe the UI is particularly buggy and that it is easier to test the UI automatically than manually, it may make sense to write them.
Sometimes testers resort to automatic UI testing for the wrong reasons. The reasoning usually goes something like this: the UI is ultimately the interface the user will interact with, bugs in the business logic will not necessarily be triggered by how the UI uses it, and when you test the UI, you test the business logic at the same time. However, a well-architected application will separate the UI from the business logic. It is usually better to use API-level tests for the business logic; the tests will be faster and better able to take advantage of API-level diagnostics that are not available in the UI. They will also be insulated from UI changes (although of course they will not be insulated from API changes).
You have been in SQA for a while, so I suspect you already know this, but I will mention it for completeness. A line of reasoning promoted by some tool vendors and UI automation evangelists goes like this: automation is hard because it requires programming, but these days there are great capture/playback tools that enable creating automated UI test suites quickly with a minimum of programming knowledge. You did not say what kind of technology you would use to write those tests, but if you are considering using capture/playback, you may want to read some other questions on that subject in this forum.