Designer & Engineer: A Power Couple

Lindsey Harris

The landscape has changed; technology moves extremely fast. With powerful tools now are at our fingertips, a small team is capable of more than ever before. There are certain attributes needed to make this powerful duo perform. There should be talent, creativity, passion and foresight, and then theoretically – magic happens. But the designer/engineer relationship can be a struggle. One filled with tension, ego, and misunderstanding.

A designer uses creativity to invent something that doesn’t yet exist, bringing something beautiful into the world. An engineer does exactly the same thing, but instead of using a visual, right-brained vocabulary, they use the left-brained language of math and logic. How do you bridge this gap? How do you walk across that chunk of fatty tissue between the two lobes?

As a creative, I’ve worked closely with engineers for years. Sometimes we were creating original products like some of the first iPhone Apps. Sometimes I was a hired gun designer on an engineering team. Now, I lead creative teams including internal designers, vendors, and engineers. Each of those scenarios has a method to the madness, but below are some overall tips I’ve learned to make the designer/engineer relationship as dynamic (design term) and robust (engineering term) as it can be.

Talented designers aren’t trying to make something look pretty, cool or custom for the sake of it. Just like good engineers aren’t saying something can’t be done because it never has been done. One does not exist to make the other’s work harder.

You can gain respect and advance collaboration by living in each others world a bit, or a lot. By treating your team member like a client you can begin to understand his/her challenges and approach. A talented designer that understands engineering principles, the way he/she might approach a problem, and the reasons why, will profoundly benefit the team. Understanding engineering resourcing issues, how long a development task should take, or what work is even possible is incredibly helpful in a creative environment. The same goes for an engineer that understands design principles.

You don’t always have control over the team that’s assembled. In some cases, you might need to educate people on why the work you do is imperative, as well as the reasons for the decisions you make. Put in the time. This should be easy. There are strong reasoning, research, and design principles that go into any good designer’s work, while strong logic, analysis, architecture, and best practices go into any good engineer’s.

Education also happens organically when someone is being challenged. The work is better when the group is smarter. It’s important to ask constructive questions, to ask “why”. Listen. Teach. Question. Share insights and processes to instill trust between each other and elevate the work.

Designers and engineers think differently. It sounds obvious, but it’s important to remember this while trying to get your ideas across. How does their thinking differ?

A designer’s questions on user interactions

How do we get the user to engage and how do we tap into their emotions?

An engineer’s questions on user interactions

How does the app react to human input and how does it communicate back?

Designers and engineers each have a distinct focus. In this example, one focuses on human engagement, one focuses on functionality. Understanding where the focus lies is a helpful jumping off point. From there, talk less about deliverables and more about project goals. It’s easy to get into the weeds if you’re trying to take on someone else’s focus. A designer may not totally understand the engineer’s details of a project’s logic, and that’s okay. Because the guiding light should be the project’s goals.

There’s a tangible mindset shift when the team thinks first in goals like ‘encourage more engagement through freedom of expression’ vs. a tactic like ‘build/design a home screen’. Then individually, how can everyone deliver on that?

Designers make engineers look good. Engineers make designers look good. In our industry, substance is not more important than how something looks. Both are important and need to be treated that way. Design dictates how a user feels while using a product. This feeling, whether subconscious or not, helps a user decide whether it’s your product they use or someone else’s.

I was talking with an engineer once about his frustration with not having a designer on his team to make the super-awesome product he was working on, look indeed, super-awesome. It’s true, people are visual. In order to believe and trust in a product it has to look and feel as good as it works. Getting people to rally around a product takes powerful functionality, meaningful features, and design that speaks to them.

Take, for instance, the Apple App Store when it opened in 2008. The first apps to hit the store were built by forward thinking engineers. Because some of these engineers were independent or a small team, design was left on the curb. They ended up making fantastic apps that looked less than fantastic. People didn’t know what to expect in the beginning, but they quickly became accustomed to the superior design aesthetic that the iPhone epitomizes. This opened up the door for someone to do the exact same fantastic app, but one that was well designed and won the hearts of the competition’s users. A prime example is the array of weather and news apps that have the same essential functionality but riff over and over in design and UX.

Stop thinking in terms of a design ‘hand-off’ that happens once final design is approved and engineering starts. Design and engineering start at the same time; from strategy through the build. It’s helpful to create space for designers to think in code and engineers to think in design. Engineers can moodboard and designers can prototype. The work will be better for it.

Also forget about ‘final design’. We need overarching guidelines to hit deadlines, but we need to allow room for flexibility and change. You can’t always see the forest for the trees. Don’t allow early decisions to bind a project up. Try hard to kill the mindset that what’s being built today will never change. Real-time user testing will inform and cause needed iteration.

Style guides; interaction guides; vector assets; animation prototypes: These items take up a lot of a designers’ time to produce. But they’re worth it.  

The more designers do to inform an engineer, the better the outcome will be. Yes, the idea is to work closely during the whole process, but so much of that time is verbal communication through scrums, brainstorms, etc. When the details and design decisions are only explained verbally, it leaves room for a large gap in understanding. This could lead to let down and frustration on both sides. Reference is a powerful tool to keep the common vision clear.

Lay this groundwork, and with the right people, you will see the work and individuals advance. The right people is key. This kind of collaboration is not for everyone. Not everyone has the ability or desire to venture outside their cozy silo. At MJD we cultivate an environment of cross-pollination and seek out people who thrive on this kind of collaboration. These types of people tend to gravitate toward each other.
Lay this groundwork, and with the right people, you will see the work and individuals advance. The right people is key. This kind of collaboration is not for everyone. Not everyone has the ability or desire to venture outside their cozy silo. At MJD we cultivate an environment of cross-pollination and seek out people who thrive on this kind of collaboration. These types of people tend to gravitate toward each other.

Android Kotlin Tips For Beginners

Austin Humes

While the Android team here at MJD had heard of Kotlin before and began to dabble in it, it wasn’t until we attended AnDevCon Boston 2016 that we became more familiar with it and started thinking about using it in a production project. A few weeks ago we started our first Kotlin app for a client. As with picking up any new language, there was a bit of a learning curve. If you’re new to Kotlin and are considering using it in one of your projects, here’s some things I wish I would have known that will hopefully help you

Prepare to Dig Around.

The Kotlin official documentation is amazing, and there’s a great Kotlin/Android introduction on that recently came out, but there is not much out there for specific questions you may have about working with Kotlin in Android. This can be pretty frustrating when you just want to create something that you have done hundreds of times in Java, but can’t figure out how it works in Kotlin, and the few examples you come across online don’t quite apply to your situation. One example I can think of where this happened for me was in hooking up a RecyclerView to a custom adapter and item click listener.

Convert Java File to Kotlin File = Life Saver.

While trudging through a situation like the RecyclerView/custom adapter, sometimes I just bit the bullet and wrote everything in Java, then used the “Convert Java File to Kotlin File” functionality in Android Studio (under the Code menu). This is a really helpful tool to see how something could be done in Kotlin. I say could because as we’ll see, there is more than one way to write something in Kotlin.

The most time consuming part of working with Kotlin is getting used to the things that will save you time.

Kotlin is a very concise language, allowing you to achieve the same result with less code, especially boilerplate code. Because of that, I found myself writing code that seemed to be the same length as Java code, and then later slimming it down to take advantage of Kotlin’s strengths. For example, there is no more wrapping a statement in a null check:

If (someThing != null) {

Turns into:


What is that question mark doing there you ask? Another cool, but initially strange thing to wrap your mind around about Kotlin is how NULL is handled. Kotlin uses “nullable” and “non-null” variable types. When a variable is created and set to null, you have to put a “?” after it, and when you access that variable later, you use the “?” after it (a “nullable” variable). The variable’s property or method won’t be called if the variable is null, which avoids a NullPointerException.

There is also a “!!” operator, which is usually referred to as the “bang bang” operator (ie someThing!!.length). It’s used when you say there’s no way the variable can be null (you guessed it, a “non-null” variable). This is one place where there can actually be a NPE in Kotlin if that variable actually is NULL. There really doesn’t seem to be much benefit in using non-null objects, at least none that I’ve come across yet. Even the Kotlin docs don’t seem to like it that much: “The third option is for NPE-lovers…Thus, if you want an NPE, you can have it, but you have to ask for it explicitly, and it does not appear out of the blue”. That’s not to say that you won’t come across them, sometimes you will have to for example if an API call returns an object marked as non-null. But if you’ve initialized an object with a value, it’s safe to use !!.

Another example of how Kotlin streamlines code, by inference:

fun sum(a: Int, b: Int): Int {
   return a + b

Can be rewritten as:

fun sum(a: Int, b: Int) = a + b

That three line function turned into one because the Int return type is inferred by the result of a+b.

Object expressions and declarations are something you’ll see a lot that will be good to be familiar with ( Object expressions are similar to Java’s anonymous inner classes, and object declarations are Kotlin’s singletons.

Kotlin’s Lambda expressions ( are also convenient to use but can take a bit to understand. Take this example:

val sum: (Int, Int) -> Int = { x, y -> x + y }

This looks like it could get hairy, but all it’s doing is declaring a variable ‘sum’ that takes two Integers, adds them together, and returns the total as an Integer. Then you would just use sum(1, 2). Pretty cool huh? And then to slim it down even more, you could use inference to modify sum to be:

val sum = { x: Int, y: Int -> x + y }

Speaking of Lambdas, take a look at this code example of Kotlin in an Android fragment:

mViewClose.setOnClickListener { fragmentManager.popBackStack() }

private val settingsClickListener = { view: View ->

val settingName = (view.findViewWithTag(resources.getString(R.string.setting_name_tag)) as TextView).text

  val intent = Intent()

  intent.action = Intent.ACTION_VIEW

  when (settingName) {

      resources.getString(R.string.facebook) -> {

 = Uri.parse(resources.getString(R.string.facebook_app_link))

          openSocialLink(intent, resources.getString(R.string.facebook_site_link))


      resources.getString(R.string.twitter) -> {

 = Uri.parse(resources.getString(R.string.twitter_app_link))

          openSocialLink(intent, resources.getString(R.string.twitter_site_link))



      else -> Toast.makeText(view.context, "clicked " + settingName, Toast.LENGTH_SHORT).show()



You may notice that the first setOnClickListener has a statement in curly braces, while the second and third have parenthesis. The first is creating an inline function statement that acts as the OnClickListener’s action. The next two are using a reference to the val settingsClickListener. settingsClickListener is creating a Lambda expression as it’s value, but you’ll notice it’s also using a View. What’s that all about? Because we’re creating an OnClickListener which takes a View as a parameter, we declare an object named “view” of type View, which is passed into the function. We are then able to use the view object in our function.

Kotlin’s custom getters and setters are pretty slick and convenient. Let’s look at an example of a custom getter:

val hasCookies: Boolean
    get() = mCookieManager?.cookieStore.cookies.filter { it.domain == mDomain && !it.hasExpired() } .size > 0

There’s a whole lot of Kotlin going on in that statement, which at first may look confusing but is a great example of how Kotlin can condense your code (Special thanks to my teammate Brigham Toskin for providing that example!). First, we’re declaring a boolean value hasCookies. We also have a custom getter. A check is done on the cookie manager’s cookies list, and is running a filter that checks if the domain matches and the expiration date hasn’t occurred. If it finds any cookies in the list that match the criteria, then hasCookies is set to TRUE. Why is this done as a custom getter versus just a statement? As a custom getter, anytime hasCookies is accessed, the get() is called and the current state of the cookies is checked instead of just when it was declared.

So Far So Good (for the most part)

After working with Kotlin the past few weeks, I’ve definitely had my ups and downs with it. I can definitely see the potential of how it can lead to smaller code and quicker development time. Also, Kotlin is a lot more similar to Swift, so if necessary our iOS team can jump in and follow along if they need to, and eventually vice versa. The hardest part of acclimating to it is just getting used to the syntax and conventions since it’s different from Java’s syntax and conventions. Sometimes it feels like you’re trying to read hieroglyphics because there’s so much going on in not a lot of code, with unfamiliar symbols and keywords, where Java feels like things are more spelled out. But like anything, it takes time and focus to understand it.

All in all, I am glad our team here at MJD decided to try out Kotlin on a project. I think Kotlin has a great future in Android development, and now that we have this experience under our belt I’m confident our future Kotlin projects will be even more efficient.

Interested in more content like this? We publish everything on LinkedIn, all you have to do is follow us by clicking below!

The Evolution of Retail, Pt. 1

Jeremy Duimstra

The convenience of shopping from home and getting a guaranteed lowest price are powerful incentives for consumers to skip the store visit. Very few retailers can operate more efficiently on price and convenience than Amazon. This is the macro-level challenge facing traditional retailers today. How can brick and mortar stores beat the experience of endless aisles of product options, predictable delivery, no traffic, no waiting in line, all while offering the least expensive option?

We believe that the answer lies in evolving the role of the store in the customer journey. Traditionally, stores have been points of conversion. Advertising drove traffic, specialty stores and department stores allowed for feature and price comparison, and sales folks helped in the conversion which allowed consumers to leave that very day with the item of their choice. Today, social media relationships drive the most influential product awareness, purchases convert on smartphones, and customer’s behavior online helps companies predict what a customer needs before they know they need it. The fully controlled retail funnel has sprung leaks.

That’s what retailers are up against today. The comfort zone of the store as the sole point of conversion has left most retailers exposed. And it begs the question, how has the store evolved in the eyes of the customer? And what does that mean for retailing in the future?

Before retail’s digital revolution, the physical store was where the “first moment of truth” happened. Crest over Colgate. Tide over Cheer. People were made aware of the products through marketer’s pushed communications which drove store traffic and in-store conversion. Because that linear path to purchase no longer exists, it changes how the store could be utilized as a marketing tactic. A couple examples:

Starbucks has turned all of its coffee shops into micro-fulfillment centers powered with their ‘Order & Pay’ app. Imagine the operational efficiency and expedited service it can now provide with a way to track and manage inbound orders. Contrast that with the stress and missed sales due to a line out the door.

American Girl is turning their flagship store into a place where girls and their dolls can bond and create memories together. This is a store they want families to visit long after the star of the show, the doll, is purchased.

This short list demonstrates the new ways of thinking about the role of the store in the marketing mix. It meets consumers needs, conforming to their lifestyle instead of conforming to the brand’s established business operations.

MJD has explored some micro-concepts that, in aggregate, can help push back on the “Amazon Effect” and help retailers reinvent themselves.

Areas of focus include:

  • The Digital Tactics of the ‘Store of the Future’: Let’s not introduce technology for technology’s sake. We’ll examine the toolbox of tactics and the appropriate times to use them to create a useful omni-channel program.
  • Enhancing the Customer JourneyHow customer journeys can be enhanced with new ideas and technology to increase sales and profit and, in turn, begin to fix the cracks in the retail world as we know it.
  • Consumer Expectations: What digital experiences are customers looking for in retail store designs? We will be looking at these wants and needs from a digital perspective while highlighting in-store design implications.

Retail isn’t dead. People need and want products and services that make their lives better. And the purveyors of those products and services still need outlets to get those items and experiences to the public. But why, how, when, where and what is no longer dictated by the retailer. The consumer is now dictating and it’s up to the retailer and its partners to figure out this omni-channel puzzle and evolve. It’s tantamount to their survival and prolonged success.

Check out Part 2 of the Evolution of Retail series: The Digital Tactics of the ‘Store of the Future’

Click here for more information on MJD’s Digital Retail Offering.

Interested in more content like this? We publish everything on LinkedIn, all you have to do is follow us by clicking below!