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 raywenderlich.com 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) {
someThing.doSomething();
}

Turns into:

someThing?.doSomething()

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 (https://kotlinlang.org/docs/reference/object-declarations.html). Object expressions are similar to Java’s anonymous inner classes, and object declarations are Kotlin’s singletons.

Kotlin’s Lambda expressions (https://kotlinlang.org/docs/reference/lambdas.html) 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() }
mViewFacebook.setOnClickListener(settingsClickListener)
mViewTwitter.setOnClickListener(settingsClickListener)

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) -> {

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

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

      }

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

          intent.data = 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!



A Better Way to Deliver Digital Products


Eric Soto

Our work at MJD Interactive is fast paced. We deliver digital experiences that have an impact on large audiences for well-known brands. We are entrusted with a brand’s reputation and are expected to succeed every single time. We juggle projects, requirements, dates and budgets to make sure we provide the best experience for our partners. However, we also are expected to wow them, delivering impactful solutions that go beyond what everyone thought possible and that few others would be able to deliver!

Amidst all this organized chaos, we have a not-so-secret weapon that we consistently wield to succeed. The secret is the Agile Methodology.


There are many flavors of Agile, but Scrum is the most popular, so that’s our focus for this article.

Agile/Scrum (or Scrum, for short), is a liberating management style for teams that has revolutionized how we create digital projects. Initially, a methodology employed for software engineering, the Agile method can be used for many projects due to its simplicity.

Though this is not a complete definition of Scrum, at its core, a Scrum Team has no manager, and no one is assigned work. Instead, in a Scrum Team (which usually consists of 4-7 people), members look at a prioritized backlog and collaboratively pick the work they know they can deliver in a calendar period called a Sprint, which is usually two weeks.

The Backlog is the responsibility of the Product Owner, who also sets the priorities for the tasks in the backlog. Officially, the backlog defines the requirements for the project but is generally not all encompassing. Think of the backlog as “what” is being built in the short term, but most definitely not the “how” it is built, nor is it everything that will be built. The backlog generally has enough work to keep the team busy for several sprints, but one of the key concepts of Scrum is that the team does not wait for a full backlog before they can begin to work.

The Scrum Team also has a Scrum Master, who is the person responsible for ensuring the smooth operation of the team. Notice how the Scrum Master is not a team leader nor a manager of the team’s work. The Scrum Master is a facilitator of the process because the team members and the product owner collaboratively decide how and when the team tackles product features. Yes, the team follows the prioritized backlog, but any team member can bring up anything at any time for discussion. It is not uncommon in projects for the backlog to contain many items that the team members themselves bring up, and that the product owner accepts and prioritizes into the mix.

Contrast this with the classic Waterfall Model of project management, where teams of experts might spend months carefully defining what a project’s requirements might be. They might spend so much time in this endeavor that by the time there is a finished specification, some of the requirements might not even be valid due to changing business, environment and competitive forces. Even worse, if some of the later requirements depend on early decisions, the entire requirements document might be obsolete or based on incorrect assumptions. For this reason, we could think of the Waterfall Model as the House-of-Cards model. A card at the bottom of the structure (a changing requirement) might topple the entire structure.

Finally, in the classic Waterfall Model, there is no product to see for a long time. It might be months or more before a product owner gets to see a hint of the product being built. By the time the business starts to see the product, it is often too late to make any meaningful changes, again contributing to the high failure rate of classic projects.

In an Agile project, the product owner (and the business) generally start to see results even after the first or second Sprint (in weeks, not months). Furthermore, the entire team (and the business) can see early on how features might really work and can quickly adjust. More importantly, we are accountable as a team.

Note, Agile teams are not “the wild west,” and they do indeed follow established patterns and practices in an organization. Just because the team is empowered to make decisions for the implementation of a project does not mean they act in a vacuum. It is very common for organizations that have central architecture groups to provide at least one member of an agile team.


Many read this and immediately think “there’s no way this works.” We can attest to the fact that it does indeed work, and very well. Furthermore, it works not just for the team members, but also for product owners, stakeholders and the people using the digital product or experience.

Imagine “seeing” progress every two weeks? What is more tangible than seeing results, regularly and consistently? Imagine delivering new features to your customers regularly (maybe once a month or more)? Then contrast that with a project where a year goes by before a new version is ready for customers – and when it is, has a much larger potential to cause disruption and anxiety (because generally, the product changed so much since the last product iteration.)

By the way, we are not alone! See the ‘State of Scrum Report 2015’ where nearly 5,000 respondents, on average, felt that Scrum is successful 62% of the time! And if a Project Management Organization (PMO) was involved, success rates jumped to over 90%. Wow!

Plus, thousands of companies create and maintain projects this way. You generally can tell who they are because they are always updating their software or product (imagine that!)

Have you noticed that your Facebook app updates, more or less every two weeks? Now you know why.

Interestingly enough, Agile is not a new concept and has been written about extensively. See Agile: The World’s Most Popular Innovation Engine and countless other articles that have been published in the last few years.


As with any concept, there are those that don’t agree with the praises of Agile.

I’ve heard folks say that Agile is an excuse for teams to avoid deadlines or engage in proper planning. These could not be farther from the truth, of course. Once you understand what Agile is, you know that Agile does indeed provide for planning (lots of it and regularly actually) as well as deadlines (every two weeks). Sure, you might not spend months in planning at the beginning of a project, but we’ve presented how that’s actually a good thing because you are planning all the time in Agile and can, therefore, learn from early small mistakes and make your digital product better. And sure, you might not deliver every single product iteration to end-customers, but you bet you’ll be delivering many more when you are incrementally producing an iteration every Sprint.

I’m not saying Agile is perfect. There are plenty of ways to screw up any project (Agile or not). What I am saying, though, is that in our practice and in what we’ve seen with others, Agile projects have a higher likelihood of producing solid results, cost-effectively and with less risk than the classic waterfall model.


To me, Scrum is second nature. To me, Agile is how you build projects. To me, Agile/Scrum is liberating and empowering, and I am apprehensive to participate in projects using a non-agile process. Honestly, working with an organization now that does not follow an Agile practice makes me question the organization and whether or not I want to be involved with them. (I wonder how successful they are. Judgmental? Absolutely! When you’ve “seen” better, it’s hard not to be judgmental.)

However, I can personally attest to the fact that Agile/Scrum has brought back joy and self-fulfillment to my projects. I’ve seen this in myself as well as my teammates who feel that they are now part of something, not just an extra hand on a project.

I can also attest to many happy clients that also feel like they participate in projects and are in full control of the process at every step. Contrast with the classic model where you give someone your requirements, they go away for three months, then come back with something that is nowhere near what you thought it would be.


If you are a leader, non-technical manager, product owner, marketing manager, C-level executive, etc., I recommend you start with ‘The Scrum Guide.’ It’s a short read, so don’t delay. Then, share this with your technical team. Getting this knowledge will allow you to support them and encourage them to move in this direction. Make it clear this is the direction you want to go in (because some Engineering teams can be stubborn about ‘a new thing.’) Also, review Introducing An Agile Process to an Organization and follow some of the ideas.

What’s in it for you? How about seeing “your product” improve every two weeks? No, you might not ship it to clients every two weeks, but YOU (and your stakeholders) will see progress, quickly, regularly. How’s that for accountability and measuring ROI?

If you are a Software Engineer, Developer, Project Team Member (or an Engineering Manager, Team Manager) you must immediately become familiar with Scrum. It will change your life (and your teammate’s lives) – believe me! Start with The Scrum Guide. It’s not very long and it’s easy to understand. Then, perhaps try How To Implement Scrum in 10 Easy Steps.

Then, JUST DO IT. Sure, you might need some buy-in from the business, but I’ve seen where Engineering teams can start moving in the direction of Scrum on their own initiative. The point is: saying “we’ll do this one day” won’t change anything. You have to start one-day, so “one-day” might as well be today!

If you hire outside resources or outsource your project development, start with The Scrum Guide but then ask your partner company about their Agile process and what role you will be playing. You should likely be the Product Owner, but if you are also contributing team members, they too need to participate in the Agile ceremonies and processes. In some cases, you also might want to provide the Scrum Master as well (even better if that person is in your PMO.)

One important consideration is that as Product Owner, you retain a critical role but it is one that comes with great responsibility considering your ongoing attention will be needed. Whereas in a waterfall project, you might work hard initially to create requirements then hand them off to a team, in an Agile project, you’ll be participating on an ongoing basis. The work might even be a little more considering you are factoring in changes and unknown factors, but it is spread throughout the life of the project as opposed to front-loaded. However, the potential for success is also much higher (and easily makes up for the extra work) since you will be able to make adjustments very quickly when compared to a classic project.


With technology moving as fast as it does these days, every organization engaged in digital projects, that wants to stay competitive and relevant, has to take a serious look at Agile. The consideration is no longer if to adopt Agile, but rather why are you not already using this method of project management.

Consider this: if internal motivation is not enough, it is very likely that your competition is already using an Agile methodology and also likely that they are outperforming you – every two weeks!


This article is by no means a full and complete definition of Agile/Scrum. For the full definition, please visit Scrum.orgScrumAlliance.org or Google “Agile Scrum Methodology.”