Does UX design have a good future?

Yes and no. The label “UX” may fall out of fashion or become permanently and unhappily glued to UI in “UX/UI”, but don’t worry about the label. Worry about the skill set. The skillset will still be needed a hundred years from now.

The label itself, “UX”, is so badly abused now that it’s practically meaningless. Depending on who’s writing the job description, it could mean any number of things:

  • Person who takes requirements and makes wireframes for the graphic designers.
  • “Hey, we need a button on this page, what color should it be?”
  • Web designer who also writes the front-end code.
  • Graphic designer.
  • Person who makes the mock-ups.
  • Person who breaks the tie when stakeholders and developers disagree on what’s more “intuitive”.
  • Person who slows down development by asking for things that are more difficult to code.

The full scope of user-experience design, however, is the — you guessed it — entire user experience. It’s not a little value-added widget stamped “UX” you just bolt on to the product to make it more “intuitive”.

As a UX designer, you need to be competent in usability and ergonomics but also the emotional effect of the design, primarily but not only aesthetic design. You must be a competent interaction designer and information architect, and you must know how to validate your design choices with usability or A/B testing and other real-world methods. You don’t necessarily need to be a graphic designer, but you do need to know how to evaluate a design aesthetically. You don’t necessarily need to be a writer, but you do need to know how to evaluate labels and copy. You don’t necessarily need to have a degree in business, but you do need to understand how to balance business objectives, resource constraints, and user needs.

If you have that competence, you are a valuable asset to any product regardless of your label. It means you can affect outcomes like customer satisfaction, sales, retention, error rates, customer-service calls, and brand perception. Importantly, that competence is not specific to any technology. It’s not “Web UX” as opposed to “mobile UX”. It’s a good design optimized for people, context, and goals.

Be a designer, not a label, and your future will be just fine.


1. Design for the users and their tasks

Isolation does not work for interactive computer systems since they have to support those using them to perform what is required. Centered for support to the users which is key in making them user-centered and task-oriented. During development and this includes the whole period, it is important for the developer to consider the characteristics of the user population, the tasks involved in the real world and the specified environment.

2. Maintain consistency

The users need a system that is easy to learn with minimal and understandable requirements. The behavior of interface elements should be consistent. In fact, consistency will start at the designing phase so as to integrate with the existing components in a computer system. You can have a new design approach to counter interaction but what is most important is for you to look at how well it contributes to consistency issues. This will determine how users will view your approach and the time taken to learn.

3. Use simple and natural dialogue

The core application of a system should be incorporated with proper interaction to enable a dialogue with the user. The user should see only the relevant information that is essential for task completion because each time irrelevant information is added, it puts the user in a more complicated situation. It is advisable for the developer to use plain English and use vocabulary that is relevant to the targeted audience. Define the terminology so that it carries the same meaning.

4. Reduce unnecessary mental effort by the user

Users like to concentrate on the task at hand and worry less or not at all of the tool and its interaction with the designed application. They are more frustrated with complicated interaction with the computer or any other mobile device compatible with the application. Why? They are distracted from the main work.

Too much effort invested in learning the operation part makes them less efficient and prone to errors. This can certainly cost a business that heavily relies on the outcome of a task. The frequency of tasks is necessary since users don’t have to memorize information from a previous part of the system that is to be used in the next part. Instructions on how to use should be clearly defined and can be retrieved when needed.

5. Provide adequate feedback

Users need assurance that their actions have been successfully executed. This can be made evident by a change in appearance when completion is achieved successfully. If it takes longer, an indicator is useful to show that processing is still in progress, and this keeps the confidence of a user in shape. What is kept away is the information providing status about the internal affairs of the system.

Various levels of interaction should be backed up by feedback. At a lower level, confirmation can be received when a control operation is successful. A good example is a button appearing somehow pressed in to indicate that the user has already pressed it. Long operations can be verified by the system upon completion.

6. Provide adequate navigation mechanisms

Users being able to navigate with ease are another vital principle for them to know their position. This is made possible by the application of an efficient and consistent mechanism that assigns titles to the current windows and use of indicators like page numbers and bars for scrolling. Other things that can be included are an overview, history of visited areas and a navigation map.

You need to provide clear routes between the different windows that the user is engaged in. The form of provision should be appropriate for the user while at each stage of the intended task.

Sometimes, users can find themselves in areas that they do not intend to be in. There should be a clear emergency exit that can be used to leave an unwanted state without having to go through it like a Cancel button.

7. Let the user take charge

The user knows what he or she needs, and the developed system provides the solution. For the user to do what is required, they should be able only to take what is required and leave the rest to support an individual request. Constraints evoked by the system should as minimal as possible which prompts the developers to provide easy ways to achieve what is frequently needed.

8. Present information clearly

The arrangement of information is essential to the user while on-screen which enables the user to single out the different elements and data groups. This can be achieved by using boxes, spaces, and visual coding proficiency. Again, developers should not provide more than the necessary information to process a task.

9. Offer Assistance

A user should get all the help needed from a system with minimal use of the document provided. In other words, they should be self-explanatory. Information provided on the window should be in line with the user’s tasks. It is important for you to provide tooltips for icon-labeled buttons.

Online help should be related to whatever interaction is provided on the window. Task-oriented should be the tone with a list of steps to be followed.

10. Error-free

Minimize errors by directing the users towards the right way to achieve their goals. Feedback from users should be constrained to prevent error, were necessary to the task. However, this shouldn’t apply in situations that will end up limiting your users’ the choice in how to accomplish their tasks. Ensure that the system validates data entry as close as possible to the point of input.

Consider expressing error messages in plain language to avoid the use of codes, point out the exact problem, and offer a solution suggestion to the problem.

How to Maximize Usability

To maximize usability, you can employ iterative design, which gradually enhances the design through assessment from the early design stages. These steps enable you to incorporate feedback from the user and client until the system attains an ideal usability level.

The preferred approach for you to ensure usability is by testing actual users on an operating system. For you to achieve significant levels of usability, it necessitates you to focus on the design efforts for the specified system end-user.

Some of the methods to determine the primary users, how they work, and what duties they should accomplish, include user testing on system prototypes, a usability audit performed by specialists, and cognitive modeling.

Is Web Development Dead?

Personally, I’d give it about 5 to 7 more years, maximum 10. I’d even kill off web design alongside it. I am talking about website development, specifically where the developer is concentrating on writing code that manifests directly on a website, rendering HTML and Javascript.

Web development is a broad term though because API development that manifests as JSON data across HTTP requests could also be considered web development.

When web design was a top role for designers, about 12-15 years ago, it was because design demands were rooted in print design. This was before mobile phones were a viable browsing tool, so you could bank on having consistent screen sizes. This was also at the time when broadband for the home was common enough that the average person could view a complex website that was so abundant with a skeuomorphic design that the bandwidth requirements were high, but the quality was high as well. As a result of complex design, web development was also a dominant role, because it was a lot of work to develop alongside that complexity of the design.

But as mobile device usage has grown, and the separation of concerns from websites being king, to instead a combination of websites, apps, and other services, the website’s need for being gloriously designed decreased. Given that we continue to have an increase in device variety, this trend is not going to reverse itself. A simple, clean design is best suited to auto-adapt to the variety of screen sizes and types that will be available for decades: visually, this is all the way from a wristwatch to a billboard.

Based on that, the majority of website development has already shifted to more data-centric work, above design-centric. If I’m viewing website content on my computer, the design might matter to me. But when I switch to my phone, design (at least, heavy graphical design) is only going to get in my way. The design components that will matter on my phone are color, typography, readability, etc. There will still be a need for designers, but far less than what we needed a decade ago, and certainly less than we need now. Designers will need to branch into more cross-device creative direction than simply “website design.”

And developers are already heading that way, by avoiding design and focusing on API development, which is critical for driving website content while also driving the two other most important technologies needed right now:

  • Apps, which are currently manifesting primarily as mobile apps, but which also include voice-activated apps, and VR apps (through independent devices like what Google tried with Glass), and
  • Integration, which is the data-sharing aspect of API development that allows the data from one app to be integrated with the service of another app to provide suite-like features across disparate systems.

When a design is needed, most of the existing frameworks can already handle 95% of the design needs a company has. What we’ll be lacking though, unless the trend changes, is qualified business experts who can properly capture web application needs from business owners to develop solutions that fit company requirements. The demand will be on making custom applications at a fraction of the cost of what it used to be. The more APIs there are out there to perform the functions we need, with integration at their core, the more a website is just going to be a clean merger of technologies from a variety of sources, and design is going to remain minimal, because that same content needs to adapt to varying phone sizes, a watch, a lens over my face, an audio interface reading back to me, VR projections from a headset, and so forth.

So web design and development as we know it today, is going to be mostly gone within a decade. API development, app development (in many forms) and systems integration will be the primary focus.

Understanding Dependency Injection using PHP

Dependency Injection is a software design pattern that allows avoiding hard-coding dependencies and makes possible to change the dependencies both at runtime and compile time.

By using Dependency Injection we can write more maintainable, testable, and modular code. All projects have dependencies. The larger the project the more dependencies is it bound to have; now having a great number of dependencies is nothing bad by itself however how those dependencies are managed and maintained is.

Dependency Injection is not a new pattern and it has been commonly used on many languages like Java, but this pattern is somewhat new in the PHP world and it’s gaining traction quickly thanks for frameworks like laravel

Let’s exemplify these concepts by creating a pair of classes first without dependency injection and then rewriting the code to use the dependency injection pattern; I’ll be really original (wink, wink) and create a Product and a StockItem class.



At first glance, the code looks pretty normal and it’s what many PHP developers would call good code, however, if we take a closer look at it using the S.O.L.I.D principle we can see that the code actually has many problems:

  • The StockItem is tightly coupled with the Product class, and while this might not look bad on this particular example. Let’s imagine that we made a change to the StockItem class to include a new parameter, we would then have to modify every single class where the StockItem object was created.
  • The Product class knows too much, in this case, the stock status and quantity, let’s say that our application can handle inventories from multiple sources and stores but for the same product. With that in mind, it would be in our best interest to make the Product class know less about its inventory.
  • We just made our life harder when it comes to unit testing the code. Since we are instantiating the stockItem inside the constructor it would be impossible to unit test the Product class without also testing the StockItem class.

Let’s Inject something!

On the other hand by using dependency injection we can correct most of these problems, let’s take at the same code but using dependency injection:



Constructor Injection

By using dependency injection we have a more maintainable code, in the previous example, we are using a type of dependency injection normally referred to as Constructor Injection. By doing a simple change we can reduce the level of complexity of our code and improve the overall quality; not to mention that now we can easily run unit tests.

Constructor injection is by far the most common method used and there are several advantages of using this particular type of injection:

  • If the dependency is required by the class and cannot work without it, by using constructor injection we guarantee that the required dependencies are present.
  • Since the constructor is only ever called when instantiating our object we can be sure that the dependency can’t be changed or altered during the object lifetime.

These two points make Constructor Injection extremely useful, however, there is also a few drawbacks that make it unsuitable for all scenarios:

  • Since all dependencies are required, it’s not suitable when optional dependencies are needed.
  • While using class inheritance trying to extend and override the constructor becomes difficult.

Setter Injection

Another common type of dependency injection is called setter injection and the same code as above would look something like this:



As we can see, with Setter Injection the dependencies are provided to our class after it has been instantiated using setter methods. Setter Injection has a few advantages:

  • Allows for optional dependencies and the class can be created with default values.
  • Adding new dependencies is as easy as adding a new setter method and it won’t break any existing code.

Setter Injection might be more suitable for situations where more flexibility is required.

So is Dependency Injection right for my application?

At the end of the day is up to each developer the one that has to make the decision about what design patterns are the right fit for his application be it Dependency Injection or something else; that being said from personal experience using patterns like this might be an overkill for smaller projects.

But if you are working on a large and long-running project, then there is a good chance that dependency injection might the right solution for your project.