Luke told about UX – blog

Month: January 2019

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!

“Everything is an MVP” – about choosing the most important from the most important


Let’s imagine very beginning of large project or its another phase. There is a couple of long months of software development in front of you. Client is going to visit you at your office. You look together at a terribly long list of User Stories and then the client states that … everything is important! You know perfectly well that “everything” equals a few years of working on the product … It’s time for MVP – it may come with the help. “Yes, I have heard about it, but in this case everything is MVP” – the client responds.

How to get out of this horrible, but how common situation? Fortunately, there are a lot of tools that can save you. Some of them, however, require long-term preparation, which is why I would like to present one of the simplest.

What do we need?

  1. Printed list of features – yes, functional features, such that give a real value to the project. No, database optimization is not such a feature. When we have at least roughly defined User Stories, it should be easy to extract them.
  2. Printed “toy” bills of various denominations: preferably a dozen or so $ 1, $ 2, $ 5, $ 10 and a few $ 20, $ 50 and one $ 100. In the further part of the article, I will tell you why. Protip: we can also use banknotes from games like Monopoly.
  3. Customer (or customers) ready to make the final decision ;-).

Game rules

The rules are extremely simple. The customer has 100 $ at his disposal and has to “spend” (dispose of) the most important features. The variety of banknotes is extremely important. There are some clever players who can spend $ 1 per 100 features ;-). To prevent this, we limit the number of banknotes of the same denominations so as to enforce prioritization.

You will be surprised how the aspect of money works for customers. After a few minutes, it turns out that there are more and less important things

The exercise can be carried out with one person representing the client as well as with several – in the second case, the whole session may last longer due to stormy discussions. The effect at the end, however, is the same.

When it turns out that we get 30 features at the end and it is too much, we can try for the second round and choose only from thirty.


On the Internet you can find a lot of online tools to do this exercise without printing anything, but the physical use of banknotes in my opinion, introduces this additional factor that increases the effectiveness of the whole game.

Please share in the comments your experiences and thoughts on the subject.

Hello world ;)

2018 was enormously exciting year – both in the professional and private fields. It’s time to sum it up… But it another post.

Now it’s time to… Hello everyone! It’s my first post on my blog. I was wondering how to externalize my thoughts. I think a blog form can be optimal way to do that.

What can you expect from I would like to write about my job – all UX (both design and research part), UI and IT stuff (software project implemention with developers, PM, PO and client) will be frequent subject of thinking on this blog.

Feel free to comment everything – let’s make this place friendly for substantive discussion for everyone.

Powered by WordPress & Theme by Anders Norén