A special thank you to all the attendees, vendors, and partners who have supported AT&T SHAPE. There are currently no planned dates for future SHAPE events, this site will be retired in 2021.
Published: Nov 12, 2019
Updated: Dec 18, 2019

Looking Ahead to the Future of Mixed Reality Design

Author: Ed Schmit

Man wearing MR goggles manipulating imaginary content

Bridging the gap between creatives and developers—what’s not working, why, and how to fix it for your organization

Ed SchmitEd Schmit, AVP Product Marketing Management, AT&T Developer Program

Ed tracks new technologies for the AT&T Developer Program. His specialties include network technologies, technology enablement, and strategic marketing.

Software developers, visual designers, user-interface and production folk. They’re (or you’re) rather different from each other.

They think differently about problems, about solutions. They talk differently. Often, they work in different spaces, floors, and buildings, too, from one another.

They make their appearances during different times of a project (or product).

None of this is bad.

Unless you ignore these differences. Then problems mount.

You know what I mean.

We wrote this post to help you, your developers, and your creatives work better together.

So then…

What’s the problem?

Not to be all negative with a list of what’s-not-workings. But, better to be clear on what’s going on before describing how to improve things.

Companies silo creatives and developers

It’s common for developers, creatives and others to work in different locations.

Even more, some dev teams are separated, say by front-end and back-end responsibilities.

Collaboration often suffers.

Ad-hoc conversations at desks, in the halls, and by the microwaves, can be the most productive talks.

Of course, they can also be distractions. There’s a lot of varying opinions on this one. Together or apart? Open or closed workspaces?

But one thing’s certain- closed communications creates non-optimal working relationships.

That’s what silos can do.

It becomes ‘about the teams’ vs. ‘about the project’

When we silo teams it’s easier for a divide to appear… and widen.

Teams start doing, and validating what they’re doing, because of ‘the way they do things’.

It’s easy for teams to defend and justify their ways-and-means. But the project flails and fails when this happens.

They work differently

For a long time now, developers have been using an agile (vs waterfall) model for developing software.

Agile focuses on a more iterative approach:

  • Define a little
  • Design a little
  • Build a little
  • Test a little
  • Deploy a little
  • Lather, rinse, repeat

The result?

A bunch of small iterations delivering features and value to users- timely, frequently and in doses.

Versus, one big mega-delivery way later than sooner.

But here’s the thing.

First, there’s debate out there around agile (and scrum). So many ways to do it, yet so many opinions how. And that’s just in the development community.

Second, add to that, those on the creative side work differently – now you have even more ways to disagree on:

  • How to work a project?
  • When and how to do design?
  • When and how to test?
  • When and how to deliver?
  • When to meet and review?
  • What defines ‘done’?
  • How to track bugs, issues, and change requests?
  • Where to go for beers on Fridays?
  • Add a few or a slew of your own items

By nature and by business evolution, developers and creatives have ways that have worked for them. Sometimes there’s conflict when combining styles.

They use different tools

In traditional software related projects, there’s an evolution of refined products and tools, for thinking, designing, building, testing, managing, and deploying products.

Not so much (yet) for 3d, mixed reality, and other new forms of content.

Sure, there’s many tools.

Like Blender, Maya, Sketch, Cinema 4D, and Rhino for 3D. And Unity, Unreal Engine, CryEngine and A-Frame for mixed reality.

But how should teams choose and use the right tools?

They think differently

Designers create visual aspects of products and apps, like layout, fonts, images, and colors. It’s all about how things appear to delight users. Very right brain- using imagination, intuition, imagination, daydreaming, and other more free-form thinking.

Developers code, publish, trouble shoot, test, iterate, architect, write down, tinker, and configure. More left brain and linear than creatives- thinking in words, sequencing, math, facts, and logic.

We all do right and left brain thinking. Yet most of us are wired as dominant in one or the other.

It’s useful to be aware of this. Got a brainstorming meeting tomorrow? Consider shutting down left brain, to come up with as many ideas as possible, no matter how zany.

Then, open the left brain valve to organize the ideas into buckets.

But do both at the same time- things can get heated, and ideas get tossed and lost.

Some more about left versus right brain thinking.

Here’s one for you.

A senior designer walks up to the screen behind a developer. He says, “Hey, there’s no gradients or drop-shadows for that window.”

But the developer was working on how to make it scroll faster, sideways and says, “I’ll add them later.”

Easy to see how the designer might feel a bit disappointed. And, the developer wondering if their input were even needed.

See how this can affect a project?

Sharing work is difficult

At any time, there is a lot going on, and changing, for any project or product. Such as…

  • Requirements change
  • Code changes
  • Design changes
  • Timelines change
  • Goals change
  • Feedback gets lost
  • Same for updates
  • Emails cross
  • Attachments never make it to the right eyes

In other words, with no central hub for sharing work:

  • Communication suffers
  • Knowledge doesn’t spread
  • Team members aren’t in the know


  • Productivity decreases
  • Anxiety increases
  • Projects stall
  • Quality lessens
  • Costs rise

Yikes. Quite the list when we look at it this way.

Having several (vs. unified) ways and tools to track, manage, view, update, share and approve work items makes life harder than need be.

“That was gloomy. How is it we’re still here?”

There are commonalities

Plenty. Developers and creatives:

  • Like to design
  • Like to build
  • Like to learn
  • Like their work to be seen, used, and adored
  • Got passion (lots)
  • Love to innovate and use the latest tools, technologies, and approaches

Here’s an example of how a project came together.

A lion eating words and roaring AI-generated poetry

There’s lion sitting in London’s Trafalgar Square.

Because Es Devlin, a sculptor, asked, “What if we could invest the lion with a diversely crowd-sourced single collective poetic voice?”

The technologist, Ross Goodwin, teamed up with Es to create Please Feed The Lions.

People approach the sculpture and say a word into a tablet (like ‘eat’). The 169 foot-long lion then roars at the crowd. Everyone looks at the screen inside its mouth, seeing a snippet of AI-generated poetry.

Beautiful visuals, AI technology, machine learning systems, special effects, and a huge data set of 25 million words, resulting in coherent poetry (mostly).

Developers, visual designers, user-interface, video and production people working together to delight the public.

Nice work, all.

How to bridge the gap

There are several practical approaches, tools, and mindsets for working well together. Here’s some.

Create product, not functional, teams

Imagine a team of 20 people or so, like designers, developers, UX specialists, videographers, testers, and project managers working on different floors.

All working on the same product.

If you can, get the band together. When they sit nearby, they talk more often, they create better solutions. Better software, better films, better mixed reality programs, and anything else requiring the expertise of your specialists.

“Hey, Jacqueline, can you look at this for a sec? Why do you think this video looks grainy when I run it through my code?”. Says the developer to the video gal at her desk 10 feet away. Or walking by. Or in the lunchroom.

When people are close together, focused on the product, the odds for the right communication, at the right time, with the right people increase. Big time.

Can’t get everyone in the same room or floor? Maybe they’re across the campus, city, country or globe?

Got it. Then create, configure, and share dedicated communication channels for your virtual team. Some great tools include:

There’s more, but you get the idea.

Physically or virtually together, a focus on the product (or project) sways everyone towards achieving the same goals.

Involve developers from the start

Remember that piece above, about agile? Define, design, build, test, deploy… all in smaller amounts?

This keeps everyone working closer together. Earlier, too.

Get the team together to define an agile process. Scrum is certainly the flavor of the past several years.

Agile or not, design is about co-creating. You want development’s input early in the process.

Maybe not from the whole team. But bringing in the project manager, dev manager, or architect could be just right. They can invite other team members as needed.

At the least, people will feel included- an excellent way to build relationships. Even more, you’ll gain valuable insights early for:

  • What can or can’t be done
  • What are the big risks
  • Next steps to reduce those risks
  • What to research next
  • Which other experts to involve

Many designers and front-end developers share similar tasks. Designers write code, too. While developers build wireframes, prototypes, and other visual designs.

This might be even more applicable with mixed, augmented, virtual reality, and AI solutions. Many of the tools are pick-and-click, making it available for techies, creators, biz folk and more. To learn more, see our recent blog on Getting Started with Mixed Reality.

With so many shared skills, better they consult with each other versus indirect communication through a manager, right?

Having a tight team, you’ll uncover issues sooner than later. Why wait months to find out a certain feature takes weeks to build, when you thought it might only takes hours?

Visualize the requirements

When possible, create a simple interaction prototype. Then everyone can easily understand the requirements- visually.

Because as the idiom says…

“If a picture is worth 1000 words, a prototype is worth 1000 meetings.” ~Tom & David Kelley, founders of international design firm IDEO.

Business people, product managers, analysts, developers, designers and everyone else that needs to be in the know will ‘get it’ when looking at visuals, not words.

Balsamiq and Draw.io are good tools for creating wireframe screens that talk to each other. Use it (or something similar) to show the flow before writing a line of code or doing a lick of design.

Getting early feedback, then making changes in a prototype is easy, cheap, and fast.

Without visuals, requirements are a vague concept.

With visuals, everyone’s head and eyes are looking at the same things.

Less hand-waving, less explaining, more showing. Now people can point at, and talk about, the same things.

Don’t underestimate this power for getting and keeping people’s attention. And creating more clarity.

Works great in the room together, or online. Save the prototype online so people can explore it further on their own time.

Also, this will go a long way for achieving item one above, involving developers early.

Annotate the prototype

So you don’t miss anything. And to ask and get answers to the right questions.

Sketch Notebook is a good tool for doing this. For instance:

  • How should the buttons look?
  • What should happen when the user sees the last search result? Remove the ‘Load More…” button?
  • What kind of progress bar should we use?

Many questions might seem obvious for the designer, but not so for the others. Annotating can help make everything clear for everyone working on the project.

And, to start the right conversations.

You want the right people to chime in as needed. Maybe there’s already ways of doing some of those things. An expert can readily jump in to share elements in their library.

Reuse, not redo.

Create overlap

Sharing is caring, right? Share what you know about what you do.

Developers, meet with others to:

  • Share the basics of coding (intro to web development, HTML, CSS)
  • Show how the design is translated into HTML
  • Show how to test the pieces

Designers, now it’s your turn:

  • Teach how you create a graphic
  • Show the details, too- developers love the nitty-gritty
  • Contrast and compare your HTML with the developer’s HTML for a recent hand-off

And for those of you creating 3D and virtual experiences:

  • Give a demo on how to use Unity, Unreal Engine, or A-Frame
  • Create a real working model before their ears and eyes, or…
  • Give them a wearable headset to experience something you already created

Share trends, too.

Do this in the moment -or- schedule regular meetings to create team unity for your next project.

Check in, adapt, and refine the process

Hopefully, the times are gone by defining a monolithic process for a new project.

Meaning- researching, deciding, then mandating the tools and methodology for upcoming projects within your company.

Too much is changing. Too many choices.


  • Do some time-blocked research
  • Pick a few tools that make sense
  • Same for any new methodology
  • Try everything out
  • Do frequent check ins with the team
  • Learn what’s working, what’s not, what to change and try next- together

Iterate, refine, and improve to create great solutions, teams, and experiences- for you and your customers.

Share this post