LukeTold.com

Luke told about UX – blog

Author: Luke

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.

Kickoff meeting – best time to setup UX work

I’ve been inspired to talk about it after the last kickoff meeting organized with the client. Please keep in mind that all the experiences can be quite specific in a software house when there is hundreds clients from various domains and specific requirements.

How many times did you have an opportunity to meet with whole Scrum Team, Product Owner and key stakeholders during the project in one room? Never? That’s the common situation. It shows how important can be the kickoff meeting. I will try to show you how to squeeze as much as possible from the kickoff.

Prepare yourself before the meeting

Know anything about the client’s company. The more the better. Explore his website, look at his products, find some screenshots from the software they produce. It can help you in at least two cases: you can start a conversation weaving in specific, domain language. Or you can just better understand what is he talking about during the meeting.

But it can be one more thing – especially if it is extremely hard to “sell UX” in this case. The most spectacular can be choosing any part of any of his product – website, single screen of an application. Whatever. Then just redesign it. Of course, it will be without any practical knowledge, a context of using and an customer-environment-oriented or investigating users needs and goals. But still – it will be something that client can refer to – he knows his business the most. How to find the optimal way to present it? It will be on further part of the post.

Get your dedicated time slot

In general, the major aim of such a meeting is to outline a high-level vision of the product, present a roadmap, choose the technology and sometimes plan the first sprint(s). There are some contact points for business and developers. But where is the place for pure UX stuff? It’s your job to create an area during the meeting.

Usually, the whole agenda is fulfilled until the last minute. In an ideal world, it should be at least a whole day dedicated to User Experience area. Great opportunity to organize some workshops, focus group interviews and to gather the necessary information to start working in the most optimal way. Because we are not living in an ideal world it would be good to have at least 1 hours time slot to set up major things. If you feel there is no chance even for that option there is a time to apply secret weapon.

Send your redesigns to the customer. Such things arouse so much emotion that it will certainly not be without a response from his side. Even if you did some wrong assumptions (and there is a 95% chance that you did) during the design process, a client will want to explain it and discuss your work. The very fact of seeing your product in a different form is so exciting that it never goes unnoticed.

How to optimally use the hour to discuss UX things?

Let’s assume you have got an hour. Keep in mind that after your secret weapon did the job, the client will want to burn whole your time to talk about your new designs. And yet it was just a reason to create a time slot. There are more important topics to discuss. The good way to get back on the right track is to explain that your work is based only on your assumption, without any knowledge about the context of using it, information about the goals and problems (regarding of current version) of users, work environment constraints etc. And you would like to get to know about all of these things before you’re discussing the actual work.

Here is the clue: list of crucial things that you have to discuss within an hour:

  1. Do you have direct access to your end users?
  2. Do you consider some user research phase before the actual design?
  3. Do you consider some usability testing and evaluating design output by the users during the development?
  4. Do you have some existing style guide, branding book or any Corporate Identity document that the UX team should stick to?
  5. What devices, screen resolutions, and browsers should be compatible with the new solution?
  6. (if there is a current version of the product) What are the major problems and concerns of the users about the product?
  7. (if there is a current version of the product) Do you have any reports of usage or statistics / Google Analytics?
  8. Are there any work environment constraints which may occur while using the app? (working outside the building, noise level, etc)
  9. What will be the basis of UX work – User Stories (what is the level of its details), functional documentation, calls with Product Owner or something else?
  10. Who will be responsible from the client side to review UX work – please ensure it will be a single point of contact (!) (and what is the decision level on your side – should you ask for acceptance according to minor changes also?)
  11. A primary communication channel between UX and PO
  12. Availability of PO (in purposes of cooperation with UX guy(s))
  13. Is there a way to start at least 2 weeks ahead of the actual development? (with your explanation of the huge advantages of this approach)

Because we had assumed that you have only 1 hour – don’t let to discuss longer than 5 minutes on 1 topic. It’s crucial to complete the whole list. The details of every position can be discussed after the meeting.

Ensure that everyone is on the same page by sending short summary after the kickoff.

At the end I would like to share you another immortal article. You may know it. It’s “A Stakeholder Interview Checklist” by Kim Goodwin. If you are thinking about organising at least whole day meeting at the beginning of the project – it should be absolutely the basics. You can find it here.

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

Context

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.

Summary

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 luketold.com? 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