Luke told about UX – blog

Category: Cooperation with developers

Everyone wants to be the UX guy. And that’s a trap!

In this post I would like to touch the problem of a chaos factor during working as a member of the development team.

It is gonna be the short one – just to point out potential threats that can effectively hamper the delivery of good user experience.

Everyone is the UX specialist

If you think about this phenomenon broader you can notice that everyone has his own benefit on it.

Developers just would like to avoid the situation of complex implementation, with some fancy animations, etc. That is why theirs main goal will be to simplify everything (btw – who needs a GUI? The terminal UI is so easy to use ;-)).

Generally, the client is on the opposite side here. But still – generally. If he understands the power of the design he will be forcing fancy solutions with lots of micro-interactions inside that can make the difference. And to be honest – there is nothing wrong with it. It may be toxic if the client has absolutely no knowledge neither about UX and design in general. Then, as a stakeholder with the decision-making powers, he can decide about things that may have a destructive influence on the final shape of the project. “Make the logo bigger”, “There is too much of white space – I don’t pay for empty pixels!”, “Users don’t need it”. Have you heard it before? If it is based on nothing – you are in the trouble!

To be fully objective – I have witnessed many situations where both client or developers had right. Their noncommittal glance on the UI equals fresh and better ideas often. There is nothing bad to have four eyes for the final look. Moreover – it should work like that.

The final clue for this topic should sound like:
Take note of the opinions of all UX-wannabe-advisers. Just try to differentiate between ideas taken from nowhere or reported for their own benefit and these ones which put the good of the end user on the pedestal.

UX Guidelines document – when it is creation worth?

Today I would like to touch the Guidelines documents topic. When you can be sure about its usefulness and when it’s completely (or partially) without any value.

Let me not to explain details about the document as itself. It’s a perfect topic for another post. (for the most interested designers – one of the best UX Guidelines are created by Mailchimp)

There are three main factors which you should consider making up your mind:

  1. A phase of the project
    If there is before the actual development of the product and you have some time to think about the whole design, you can consider creating such a document. It’s good to have some time without any pressure of delivering another view for developers.
    If you are in the middle of development, you probably have not enough time both to create and maintain UX Guidelines and to design regular screens.
  2. A level of UI diversity
    There is one rule here: if you expect rather linear UI (repeatable screen types like data table with a list of items and details screen on the major part of an application) creating Guidelines will be an enormous time saver for you. It’s easier to describe and present some patterns, styles and behaviors which can be applied to hundreds of views than design it screen by screen.
    If you feel that is not so easy in this case and diversity level will cause creating 300 pages document (so many cases to describe), it means that in this time the document is not worth that effort.
  3. Front-end skills of the developers
    Last but not least. Sometimes the front-end part of the application is treated with neglect. It’s 2019 and I’m still experiencing such situations while developing huge back-office systems. Sometimes the highest priority has a back-end, security and performance. That’s OK until you are not responsible for the final design. If you know that it may be the issue, it’s better to create UX Guidelines and describe all the rules into a document which should be the only source of truth in terms of the GUI.
    On the other hand, if you are sure about front-end skills and you are working with the same team who “passed the test” earlier – that’s the reason for resignation for document creation.

To create or not to create

There is no clear answer to that. I’ve presented a simplified list of 3 main factors that can help in making the final decision. Black and white doesn’t exist in this case – there are thousands of shades of grey. Additionally, you should keep in mind one more thing: UX Guidelines should be updated after every single change (you should keep it living) and the more minutely you describe the rules, the more work will be to maintain it.

Traditionally feel free to comment and share your experience on this topic!

Powered by WordPress & Theme by Anders Norén