August 2018

Applying ‘Product Thinking’ to UX

Life’s too short to build something nobody wants.

Ash Maurya in “Running Lean: Iterate from Plan A to a Plan that Works”

UX/UI in Xpand IT

During recent years, Xpand IT has been investing in supplying UX/UI services, which has resulted in significant growth of our HCI (Human Computer Interaction) portfolio in B2B and B2C application software and mobile apps to both Portuguese and international clients.

Our interfaces and user experience design have always been based on the User-Centred Design concept and have been delivered in almost all industries: retail, banking, telecommunications, insurance, health, transportation, e-commerce, mobility, public utility, and others.

We are prepared for the next challenges concerning user experience in digital products  –  for example, we increasingly propose and design CUI (Conversational User Interfaces). However, we still find traces of a mentality that is not completely receptive to the idea of the digital product, and is more worried about lining up a huge number of functional requirements that sometimes are completely inappropriate to the needs of the final user of the product.

The immediacy experience offered mainly by social media apps is transforming our expectations concerning the way we want to use products and digital services. As UX designers, we feel the need to analyse the complete ecosystem that brands and users share, in order to define how a business can still be relevant in a world where immediacy is king.

User-Centred Design – with its concept of bringing users into the design process – exists to reduce the gaps between those who create a product and those who use it. The UX team from Xpand IT is focused on finding these gaps, preventing them and eliminating them.

Thinking about the product

In its traditional approach, UX/UI design is focused on the functionality of a digital product: the appearance of the interface (UI) and how users interact with it (UX).

However, a group of functionalities is just a small and fragile part of a product: it is just some of the many possible solutions to the problem the product is trying to solve.

It is not that functionality is not important, but it is usually secondary to the reason why people use a product. The reason is simple: the user uses the product to solve a specific problem in the real world.

In practice, this means we have to understand the product first. A particular function may (or may not) be a useful part of a product, but without the product, that functionality may be wasted.

For example, Uber’s app is frequently used as a good example of user experience design: one of the functions that creates the most empathy is the countdown that shows the time until the car is due to arrive, which is certainly convenient and is related to the goal of the app. However, what makes Uber so attractive is the ability to obtain quick and easy transportation in your area at any time. Even if the countdown functionality did not exist, the app would still be useful. In other words, Uber was conceived having in mind the goal of the product and not the resources that came with it.

Applying Product Thinking to the user experience has been experiencing increasing adherence by UX designers worldwide and expanded when well-known international professionals – such as the German Nikkel Blaase – brought it to a wider sphere of public disclosure. By the way, this talk might be a good starting point to learn more about the subject.

Defining the product

All in all, companies tend to assume that the more functions, the more useful the product will be; that the broader the target audience, the more people will use it; that the more use scenarios are mapped out, the more it will be present in people’s lives.

Which is not necessarily true: there are plenty of products out there with loads of functions that are not used by anyone.

A very common mistake is to start immediately by designing any kind of interface.

However, if the user’s problem has not yet been identified, why are functions and interfaces already being thought about?

It is precisely in this aspect that a lot of digital products fail: they try to solve a problem that does not exist.

A few things need to come before the solution that will be found to solve it: deeply understanding the problem, who the user is, and how the product is going to solve this problem.

However, the process of creation of digital products tend to be a little chaotic: inside a company, there are different departments, areas and businesses that have different opinions about what the product must be, for whom it must be designed and, mainly, which functionalities it must have.

That is why a thorough reflection to clearly define the scope and requirements of a digital product should be done:

  • Why are we investing in this product? What is the business deal in creating this product? Which data and statistics prove that the product is viable?
  • What is the product? What is its primary function? How does it stand out from the competition?
  • For whom is the product being created? What is the profile of the typical user? Which specific behaviours or needs of this user should be considered?
  • Where and when will the product be used? At what time and how much? At home, in traffic, at work? Is it a product for constant use or a one-time use product?
  • How do we want people to use the product? What do we want people to feel when using it? What problems do we want to solve?

Finding the correct answers to these questions constitutes the basic strategy to define a product and causes alignment between the various business areas of companies. This process, when well driven and supported by UX designers, brings huge advantages:

  • Build the right functions and interfaces for the user.
  • Understand the experience as a whole and not just a visual and interaction layer the user will see.
  • Ensure that the product solves real problems for its target users.
  • Minimize the risk of building something nobody would want to use, or that does not last a long time.

Conclusion

When this kind of thought about the product is part of the process from the beginning, UX designers can ask the right questions, communicate more efficiently and suggest appropriate functionalities.

It is easy to be overwhelmed with infinite functionality possibilities and ignore some of the important parts of the design process.

Avoid the potential traps when focusing only on functionality instead of on product usability, thereby turning the thinking about the product into part of the UX design process of the mobile or web app. There is nothing wrong with functionality, but it should not be more important than the real goal of the product.

Have this in mind, and the final result will be a digital product that is created, tested and personalised for the defined target audience, with greater probabilities of becoming essential and making users’ lives easier.

Carlos Neves

Senior Ux & UI Consultant, Xpand IT

Carlos NevesApplying ‘Product Thinking’ to UX
read more

Kotlin and a brighter future

Picture this odd world called The JVM.

(From here on, it’s better to read it with David Attenborough’s voice…)

At first there was only one living creature on it: its name was Java. Java was fun; Java was new; Java was simple; Java was powerful – yet Java wasn’t enough. Other species started to come to life, such as: Ceylon, Groovy, Scala, Clojure, Frege, Kotlin. Even Java itself evolved over time. “But why so many species?” is a question one might ask. Had the mighty creator failed with its own creation? Were the other Gods (the programmers) not pleased? Maybe they just weren’t happy enough…who knows!

Now, this is the case for Kotlin.

Enough with the “Life on Earth” analogy, but you can keep the David Attenborough voice – we all know how incredible it is.

Yes, the question is, indeed, why yet another programming language for the JVM? I can’t answer that, I really don’t know, but I believe I have some arguments that might help shed light on why this is a strong specimen.

Kotlin’s evolution

Although it seems like it is, Kotlin is not completely new. Its first commit dates back to 8 November 2010 and it has been slowly maturing over time, just like a fine whiskey.

General adoption has been increasing in recent months helped by major events such as Spring adoption in version 5 or Google I/O 2017, where Google announced official support for the Android platform. 2017 was also the year of the first KotlinConf, where it became noticeable how much Kotlin is reaching beyond the Android World.

It is also curious to see the number of StackOverflow questions related to Kotlin increasing after the Google I/O announcement and the fact that it now appears on the TIOBE Index.

As for public open source projects on GitHub, according to GitHut 2.0, for 2017/Q4 in the top 50 list, Kotlin scores:

  • 16th place for projects stars for a total of 0.480%
  • 17 th place for issues, totalling 0.489%
  • 23 rd place on pull requests making a total of 0.351%
  • 19 th place for pushes, totalling 0.424%

…with overall positive growth.

Java interoperability

Kotlin stands out amongst many, mainly because of its ability to interop easily with Java on the JVM runtime.

It compiles to Java Bytecode and adds practically zero overhead, it being possible to compile to versions 6, 7, 8 and 9 of Java bytecode and at the same time take advantage of the features of each version. One great example of Kotlin’s power is its support for Lambda Expressions even when compiling to Java Bytecode 6. Even the Java language doesn’t provide support for them.

Tooling

Kotlin is developed by JetBrains, making it a first-class citizen within IntelliJ IDE, Android Studio and CLion. Features such as refactoring, code generation, code completion, compiling to bytecode and sneak-peeking the bytecode on the fly – and even a Java to Kotlin converter – are all there for your delight.

The command-line compiler (kotlinc) has a REPL mode that can be used to easily try out Kotlin snippets of the fly.

Mutiplatform targets

Compilation for multiple platforms is supported. Using Kotlin you can target the JVM, Javascript and LLVM.

Let me try to rephrase that to get the point across:

“Program with Kotlin and get the server-side code deployed to JBoss; share business logic code with the Android client application and also the JS/HTML web client. Oh, let’s not forget that cute IoT device – share some code with it as well. What’s that? You want iOS? Sure, why not!”

Kotlin/Native leverages LLVM to ease natively targeting a vast number of platforms like Windows, Linux, MacOS, iOS, Android and WebAssembly.

Kotlin for Javascript enables you to transpile Kotlin into Javascript, making it possible to, for example, create React web apps.

A great showcase of this feature is the KotlinConf 2017 companion application, which is entirely implemented using Kotlin, covering backend, frontend and mobile applications.

Embracing Kotlin as a team

Starting to use Kotlin doesn’t have to be a risky decision! By nature, it works incredibly well with existing Java code and it’s even possible to have both Kotlin and Java code on the same project. Developing new features in Kotlin on an existing project can make it a good approach for adoption with low risk as there’s no need to scrap everything and start from the ground up with a new programming language/technology.

Using Kotlin has also become a day-to-day reality for Android developers. Most Android GDEs (Google Developer Experts) advocate and use Kotlin on a daily basis and it can even be found in Android’s Official documentation.

As for non-mobile developers, such as backend developers, Kotlin presents itself not only as a way to achieve current programming language standards on the JVM while targeting Java 6/7, but also as a replacement for Java as a whole. Projects such as TornadoFX, Ktor and Spring, among many others, provide the necessary foundations for Kotlin to thrive outside the realms of mobile. And since Kotlin is almost 100% interoperable with Java, you can keep using the same frameworks you’re used to but with the syntactic happiness of Kotlin!

The most common approaches to adopting Kotlin are:

  • Re-write Java unit tests with Kotlin. Some advocate this as a good approach to dip your toes into Kotlin while not putting your production code at risk. However, from my perspective, tests should be using production code. However, Kotlin does offer some neat tricks to make unit tests more legible and compact.
  • When starting new features, instead of using Java, use Kotlin!
  • If the project you’re working is due some refactoring, apply Kotlin into the new refactored version of the code base.
  • Go full Kotlin and leave the sad days behind by saying sayonara to Java!

Kotlin language

The language itself is beautiful. Kotlin is a statically typed language with conciseness and readability as major goals.

It also attempts to solve one of the biggest problems of the Java world: NullPointerException. It does so by making nullability part of the type system and enforcing the developers to think about it explicitly.

Another aspect that makes it a top tier language is the fact that the authors attempt to bring the best features available in other languages into Kotlin itself. To name a few:

  • Extension Functions
  • Destructuring declarations
  • High Order Functions
  • Type inference
  • Functional Facilities (map, filter, flatmap, etc.)
  • Custom DSLs
  • Named parameters
  • Pattern Matching
  • Operator overload

Kotlin syntax

Here are some Kotlin snippets as a sneak peek. These attempt to showcase the simplicity and conciseness of the Kotlin language in comparison to Java.

Java Kotlin

// Class definition

class Person {

private String name;

private int age;

public String getName(){

return name;
}

public int getAge(){
return this.age;
}

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String greet(){
return “Hi ” + this.name + “, how are you doing?”;
}
}

// Class definition

class Person(val name:String, val age:Int) {

public fun greet():String {

return “Hi $name, how are you doing?”

}

}

// A Typical unsafe Java Singleton

public class Singleton {

private static Singleton instance = null;

private String someProperty = “SOME_SINGLETON”;

private Singleton() {

}

public static Singleton getInstance() {

if (instance == null) {

instance = new Singleton();

}

return instance;

}

public String getSomeProperty() {

return someProperty;

}

public String appendSomethingToProperty(String something) {

return someProperty + something;

}

}

// A simple Kotlin Singleton

object Singleton {

val someProperty:String = “SOME_SINGLETON”

fun appendSomethingToProperty(something:String) = someProperty + something

}

What’s next?

If I’ve sold you on Kotlin and you want to try it out, here are some pointers to help you:

And keep an eye out for future Kotlin articles on this blog!

João Gonçalves

Mobile Consultant, Xpand IT

João GonçalvesKotlin and a brighter future
read more