Collaboration Delivers an Immersive Customer Experience for $60B Retailer

A $60 billion retailer needs a comprehensive customer experience across all its digital channels. And they need it in only seven months.

That was the challenge proposed to projekt202 and Vice President of Technology Paul Tidwell. In this interview, Paul describes how the projekt202 team worked within this tight timeframe to successfully deliver a complete and rewarding omnichannel experience.

projekt202 recently built an omnichannel experience in about seven months for a major retailer. For anyone who’s unfamiliar, can you explain what omnichannel is?

VP of Technology Paul Tidwell
VP of Technology Paul Tidwell

It’s become a common trend in large businesses, especially in retail, to have your in-person, online and mobile experiences all aware of one another. Omnichannel means no matter how you “touch” the store, your experience is fairly synchronized across those channels: email, web, mobile, in-store talking to an employee at a service desk. All of those channels have some common awareness. As you do things, the store's understanding of you evolves in a meaningful way, so all of those touchpoints collectively lead to a more meaningful and deeper relationship as a consumer with that store. It's about the relevance of an experience.

What did projekt202 build for this omnichannel experience?

They had prototyped an experience around allowing consumers to move through the phases of playful experimentation around a remodel project or a refresh project into the actual planning and buying phases. They had thought of a lot of different ways and worked with another organization to conceptualize ideas. What they built was a kiosk prototype that allowed consumers to visualize, in a physical 3D space, different colors of walls, different types of vanities, different types of tile, all of the things that you would do in remodeling a bathroom. They also had an in-store stylist that the consumer could meet to help them further curate that concept.

All of these were great, but they were built as independent islands. They didn't sit on the internal IT infrastructure in any way. They didn't connect to the stores’ Wi-Fi. They were just a stand-alone prototype. The inventory was curated independently of stores’ actual inventory.

What we did was evolve that to the next step where we began to tie in these applications to enterprise APIs around inventory and scheduling. We worked with a third party to further develop the 3D immersive experience by building all the software related to that. The projection units and visualization side on the media server was done by another party, but we helped build out the solution for browsing all of the inventory and having it be projected into space as you selected items, and then tied that back through a common API to a central repository that became the hub of the omnichannel experience. Users could then continue to curate those experiences in those remodel projects from home, or by working with a stylist in-store.

There was also a mobile experience where, in the course of working with the stylist, you could walk around the store and scan items, and have those inserted into your project. It amounted to a database, a web-serviced tier, a native IOS application, the kiosk solution, and then the three web applications. We did this in about seven months, from design to deployment in the first store. They eventually rolled that out to almost 20 other stores in varying markets to test the success metrics, which were based on analytics instrumentation and tying into their back-end solution to equate those to eventual transactional results.

Why did this big box retailer reach out to projekt202 to help them with this solution?

They had an internal omnichannel team primarily focused on managing web properties. They had a very limited purview of actual channels. They collaborated with an email marketing team, but didn't fully own that channel and had loose collaboration.

We had the broader sense of omnichannel, widening that ecosystem for them through email marketing that brought people to the landing page to create projects initially, helped promote in-store kiosk and stylist experiences, and built the web service backbone that allowed all of these applications to have collective awareness of the projects and things that you been done to continue to evolve that project, like hopefully buying products and remodeling  the bathroom or kitchen at the end of the day.

What made this project stand out for you?

It really challenged the team in a lot of ways and allowed us to touch a lot of emergent technologies. Working with the vendor that provided the projection technology was really great. They were using seven projectors in each kiosk. They had Xbox Kinect systems within there that would do auto-calibration. There was a large 27-inch touchscreen for navigating the kiosk. That was a really beautiful, elegant and fun immersive experience that not every project typically needs.

Then there was the omnichannel aspect around having a lot of applications communicate through a common service tier. Also on the kiosk, we used a framework called Electron, which allows you to build applications that feel like native, browser-less applications, but they're really using web technologies. It was developed using Angular, but it lived in Electron, which gives you local file access. For all intents and purposes, it looks like a native application.

The way that we deployed the application using Docker on Azure was really exciting. Azure's Docker solution is fairly new. There were some hurdles, but some really exciting things around doing continuous deployment, continuous delivery, and more of an ops-focused solution for managing getting five apps out into the public space in a meaningful amount of time.

It was a quick turnaround getting them in front of users. Getting them in front of acceptance testers could have provided a drag for the team, but using these modern deployment technologies -- what's commonly referred to as DevOps now -- allowed us a lot of agility. It allowed the development team to focus on features instead of moving code through different environments.

It was a great mechanism for maintaining velocity and providing a lot of focus around the value-added features that we were being paid to deliver, as opposed to the kind of cold, hard mechanics of how you get things on the right computers.

This project required a lot of teamwork and communication among designers, developers and vendors, right?

Yeah, I think the collaboration was really exceptional on this project. One of the challenges was building a very holistic and consistent experience across all of these channels, but also realizing that we probably wouldn't be able to build all of it in the seven months that we had. We worked on a technique where we established key workflows through applications and used those in a scope management exercise that transformed the conversation from, "These are all the things that you can't have and here's the scope that we're cutting out," and changed it to a conversation about, "Here's what you’re getting and this is the important workflow through the application, and if you get this, is it a success?"

It cast a positive light, but also helped stakeholders who couldn't just look at a backlog and visualize what they were going to get at the end of the day, to really see a path forward That was a powerful technique that made it easier for development and design to collaborate around, "This is our marching order, this is really what we need to deliver on. If we can do this, everybody knows it will be a success."

What were some of the challenges?

Working with a $60 billion retail organization and their massive IT juggernaut posed its own challenges. In integrating with their enterprise scheduling solution for scheduling appointments with the stylist, we had to jump through a lot of hoops, because users had to be members of their active directory and had to be provisioned across three different systems and synchronized. Something that seems straightforward to us -- just getting test users and production users in place -- was really tough.

Likewise, integrating with some of the enterprise APIs just for inventory was really difficult, because we were extending that to support this projection-immersive experience. By doing so, we became kind of a downstream consumer. When items were removed from inventory, we had no notification. It would break that linkage almost at will, so we had to build in a lot of inherent resiliency there. That was interesting.

Also, working with the physical constraints was a challenge. These kiosks had to have fire suppression systems built in. There were these larger concerns about putting something into a big box environment that you don't initially consider, that we don't encounter on a lot of the line of business or standard web platforms that we develop.

And then working with their enterprise analytics team, too. They were moving at what was probably a normal pace for them as a large enterprise, and we were moving at a very rapid clip to get to our deadline. At the very last minute, we're still tuning analytics to make sure that they could build a viable business case around this. These were tying it back to determine the success in the future of this application and balancing that with trying to build an amazing user experience. There were a lot of trade-offs. I don't think we could have done it without really close collaboration between research, design and development.

This project came to projekt202 via a previous project. Other vendors were involved before projekt202, so your team inherited some work that these vendors had done. Why did the client pick projekt202?

Certainly, it was an interesting pre-sales experience. We went to see the prototypes and, in the course of looking at potentially what was maybe just a kiosk implementation or evolution, we were meeting the vendor who had created the prototype. It turned out at the end of the day they were there to help vet us and to shepherd their creation to that next evolution of enterprise integration.

We actually ended up having a very collaborative and non-competitive relationship with the previous vendor, which was great. Also, these big organizations don't move sometimes at the pace that we would like them to, so they went away for seven months. A lot of things changed internally before they came back and said, "We'd like to work with you on this project," and one of the things that we did in the meantime was think about a lot of ways that would make it very easy to get started.

We visualized these islands of functionality and how we would connect them, and found some small ways that you could start to chip away at that by establishing connectivity between one system or two systems, and how you could evolve that into this true omnichannel experience. It was a long conversation and a lot of collaboration.

So projekt202 was collaborative with them at the very start, and not just with them, but with the previous vendor. Then you already a plan of how to go about doing things. You were prepared, but what were some other offerings that really made them want to sign on the dotted line?

One thing that was important was the kind of integrated offering. Not only being able to build the solution, but also being able to process all the existing research and create the compelling user experiences, and then deliver on those items. That, and being able to collaborate with the existing vendor. Also, helping manage the hardware vendors and the fixture builders, and all of the other vendors that were at play when there wasn't any existing strong project leadership in place.

We were the first line of triage and kind of the surface area of the entire experience, for better or worse. That leadership and that ability to build a framework for issue management and resolution was a really valuable addition to the project at large, and probably one of the critical success factors.

Let's talk about the tech stack that was used. How was this actually built?

That was one of the things that was very exciting for my development organization. Not only were we using this modern ops-minded deployment mechanism through Docker, but we were using a full JavaScript stack for the entire solution. The client traditionally had third-party solutions that were cloud-based, so we felt like Node would be a good solution for some middleware services. The application service here was written in Node JS. All the client applications were written in Angular and, like I mentioned, we used Electron to create the thick client solution and then a native IOS solution.

The concentration around JavaScript was really powerful because we had front-end developers who could jump in and help on the back-end as needed. We had an architect building out that middleware and who was responsible for developing the database scheme, which was in MySQL.

It gave us a lot of flexibility, since our mentality was to effectively get all five applications to a minimum set of functionality and then advance that incrementally. We had people semi-specialized around each application type, but also the ability for people to reallocate as we needed to move forward in any particular application to meet the client's needs and to be truly Agile about the way we deliver the project.

That's a pretty common stack these days: Angular and Node and MySQL. The languages themselves facilitated really rapid evolution and deployment of the solution, and also complemented the kind of deployment mechanisms that we were using as well. It was holistically a great choice and also a lot of fun to work in.

It was really a blast. They were a great client. They were really collaborative. I think they deeply appreciated our ability to work within their own semi, sometimes, inflexible IT organization. They were interested in the way that we were doing things and also willing to consider different ways to get to their goals.

Stay up-to-speed on projekt202: Follow us on LinkedIn and Twitter.

collaborate with projekt202 for success in 2017 and beyond: contact us today.