Who’s the most important marketing person at your company? Your CMO? Someone on her team? Maybe your CEO? What about your CIO? While your Chief Information Officer isn’t likely to craft your next campaign, the impact he or she has on customer experience is becoming more direct and more critical every day.
The reason is simple, and it has to do with insight. More and more, CIOs and their teams hold the keys to unlocking the customer understanding that designers and marketers crave. A convergence of trends — abundant customer data, demand for greater insight in defining and managing customer experiences and a growing need to empathize with a wider range of customers — are driving CIOs into the insights business. A question remains, however, in how effective marketing and IT teams will be in working together to uncover customer data and convert it into meaningful actions.
Insight into customer behavior is what separates good customer experiences from bad. Insight drives empathy, a raw ingredient in the effort to humanize technology and harness its brand-building potential. The astute use of customer insight is so vital that we include it as one of seven factors in Perficient’s CXIQ Assessment, our measure of an organization’s customer experience maturity. While every company offers its customers an experience, few understand what it takes to systematically turn customer insight into the superior experiences that lead to increased preference and loyalty.
From a PM/AM perspective, we are expected to keep the client happy (fulfill their objectives and vision), be the voice for our internal team and help produce a relevant and useful product while staying on time and in budget. Neglecting one and overdoing the others can cause issues with the overall success of the project, ultimately placing strain on the client relationship and internal morale. Catering to the client only can result in delivering a product solely focused on business objectives. This tends to overlook the user’s satisfaction, delays development and produces a less than successful product. It is our job to figure out what those objectives are and how they translate to the end-user. On the flip side, if we as the agency look out for our sole interests, rogue creativity may result in irrelevancy and dismiss the client’s primary business objectives. There is a balance, but how do we get there?
There was a similar discussion in the book, SCRUM: The Art of Doing Twice the Work in Half the Time, which sparked my interest on the topic. In software/web development, teams can be overwhelmed with a never-ending list of requirements that become irrelevant and outdated as the project develops, and they tend to serve more as roadblocks. Features become wasteful and not needed. These requirements are gathered at the beginning of the project and are thought to be essential to success. Things change, however, and we must be willing to be flexible.
To get to the overall purpose and desired outcome, we need to prioritize with our clients and internally: what is important, what is a must have, what is a nice to have, and what can get left out all together?
Look at the requirements through the lens of the Kano model, a method that has helped me wrangle in my own grandiose ideas.
Must-be Quality – Expected qualities of a deliverable. (The table stands up – woo hoo!)
One-dimensional Quality – User is satisfied when achieved, dissatisfied if not. (Table says it raises up and down. It does not – boo!)
Attractive Quality – Not expected or desired but a bonus. (Table was also made with recycled tires – cool) If it wasn’t, still cool table.
Indifferent Quality – Neither good nor bad, doesn’t really make much of a difference.
Reverse Quality – Too many features/options, not all customers are alike. (Table can also fold into a sofa, a ping-pong table, a sled and be used as a trampoline. I just want to put my computer on it!)
I’ll never forget a project that was delayed for one small feature that eventually was removed anyway. At the time for the client, they thought it was the make-or-break feature for the site. They had lost sight of their goals which cost them in the long run. (Of course, I tried to stop them, they just wouldn’t listen…LOL)
My Favorite Example of an Indifferent Quality
“Think about it: when was the last time you used Visual Basic Editor in Microsoft Word? …But it’s there, and someone spent time implementing it, but I guarantee you, it doesn’t increase the value of Word by much”
Here are two projects with the same intention (success and increased usage), yet two very different results:
FAIL: Windows 8 Metro UI
Here is a unique example of having the user experience in mind, so they thought. The Metro worked very well across mobile, tablets and the Xbox interface. The move to PC caused confusion as they forgot to examine what the experience would be like for the user and focused more on the continuity of look/feel between devices. Hidden gestures, a clunky start screen and other usability issues put the desktop user last, not remembering that desktop browsing is still very relevant. It solved the problem for creating the same interface to multiple devices, which is more of a design conflict, not solving a real problem for the user.
YAY: McDonald’s App (Netherlands)
This UX team had great attention to detail on what the users wanted (locations with directions, relevant coupons, favorites, build a meal with nutritional values) while still meeting the business needs. The app had delivered on its KPI’s, impact on sales. 2.1% of all McDonald’s customers brought in a mobile coupon, and there was a 47% increase in spending through upsells using the coupons. On top of that, it was the #1 download in the app store and Google play, downloaded by more than 1 million Dutch consumers, according to UX Magazine.
This thinking can be used throughout the project cycle; there is not one definitive moment that it is more useful than another. Project is off track? Look at where you are in the development cycle. What can be removed? Does it still have the same effectiveness without it? Will it still remain relevant and useful to the user? As we all know, projects are evolving pieces of work and have elements of upkeep to them. Does the product still engage the user? Have the business metrics flat-lined? Are there new technologies/techniques that we have access to now that will make this better? Moral of the story: take a step back from the chaos and reflect on what it is that you are trying to accomplish and how you are trying to get there.
People are impatient. They expect a lot of effort to be performed on their behalf, but without seeing that effort they can’t appreciate it, yet they want it all the same. According to recent research, making users wait may create the expectation that what they receive has greater value, and that more effort went into preparing it.
For content marketing professionals, the effort is often unseen; clients give us a directive, then we disappear to mine through data and research, and then construct something. But, for the client the deliverable just appears before them upon completion. This could make our work seem easier than it is, especially if you’re experienced enough to work exceptionally fast. So it becomes vital for us to tell the story of our work, and show our process. Otherwise we are trimmed for scope or left out all together on projects that really need us.
Read the rest of this post »
When designing and developing a website for mobile devices, there are many things one needs to consider. Are you using a responsive or adaptive approach? What devices / browsers should be supported? What are the major breakpoints? When trying to answer these questions, we as designers and developers tend to focus on mobile device resolutions as a deciding factor, but one thing that is often overlooked when considering the size of a mobile device is the CSS pixel ratio.
Put plainly, CSS pixel ratio (also referred to as device pixel ratio) is the relation between a device’s physical pixels and logical pixels. Especially with the advent of retina screens, the pixel resolution of modern mobile devices is growing at a fast rate. Consider that the iPhone 3g had a resolution of 320×480 px, the iPhone 4s’ resolution was 640×960 px, and now some phones like the LG Nexus 5 boast a resolution of 1080×1920 px. How is one supposed to design a website for all mobile devices when their screen sizes are so vastly different? That is precisely why the device-pixel-ratio was created. Read the rest of this post »
Today we announced our intent to acquire Zeon Solutions, a firm specializing in e-commerce, content management, product information management, mobile and digital marketing solutions.
Zeon Solutions is an excellent addition to our team, bringing a unique combination of strategy, engagement and technology services, a proven track record of growth and profitability, an impressive reputation and a strong client roster.
The addition of Zeon Solutions deepens Perficient’s e-commerce expertise and enables us to provide more powerful enterprise digital solutions for our customers. Perficient is better positioned than ever before to help clients effectively address market changes and realize lasting business results.
Additionally, this acquisition increases Perficient’s geographic footprint, adding U.S. market locations in Milwaukee and Ann Arbor, as well as an off-shore delivery center in Nagpur, India. Altogether, nearly 400 consulting, technology, sales and support professionals are joining our team.
It’s an exciting time at Perficient. As our business continues to grow, we see tremendous potential to leverage Zeon Solutions’ e-commerce knowledge, tools and experience, driving more opportunity across the enterprise. I’m confident Zeon Solutions makes Perficient an even stronger consulting partner and solutions provider.
You can learn more about Perficient’s acquisition of Zeon Solutions in our news release here.
…if you happen to live in China, that is.
According to a recent article from Fast Company,
In China, QR codes are everywhere, and most apps have their own QR code readers built-in.
What seems like a pointless piece of technology in the U.S., can be central to an entire infrastructure in another country.
Here’s another example: voicemail.
I’m one of those people who would like to change my voicemail message to say: “Thank you for calling. If you want to reach me, please send a text.” I find the entire process of calling my voicemail and listening to a lengthy message to be a time-waster. I’ll take 10 texts over one voicemail any day. But in China, it’s reversed. Writing and reading Chinese is very laborious. It’s even harder when there are multiple dialects. The solution?
When creating a technology or determining its usefulness, it’s vital to understand the culture of the people who will be using it. This is true whether you are creating an app for a specific country, a specific demographic or a specific industry.
Great UI design is only great if the end user says that it is, regardless if they say it via text or on voicemail.
Last week, I ventured to Anaheim, CA, for Forrester Research’s Why Good Is Not Good Enough conference. I wanted to find out how, in a world of same-day e-commerce, self-driving cars and ubiquitous Wi-Fi, the stewards of the world’s top brands were managing to keep their customers happy.
Across the two days, mic’ed-up presenters and tweeting colleagues agreed that customer experience (CX) couldn’t be left to chance. Like any business asset, it must be monitored, measured and optimized in accordance with shifting market demands. And now that we’re a few years into the optimizing, we sense that “good” just won’t cut it anymore.
But despite the agreement, two distinct camps emerged; one asserting that as customer demands grow, brands must keep pace by exerting maximum control over experiences, even extending their influence beyond traditional boundaries and into external ecosystems. The other held that doing too much planning and seeking too much control was impractical and unwise. Organizations should instead pursue a more enlightened path of responsiveness, flexibility and empowerment.
So who’s right? Here are my six takeaways from the conference…
#1. Mastering CX is not easy. Forrester VP John Dalton opened with a story of Walt Disney, pioneer of experiences for the pint-sized customer. Despite years of planning and a drive to control every detail, Disneyland’s opening was a near-disaster. On that sweltering day in 1955, throngs of parents and children endured hours-long wait times for rides. Newly paved asphalt melted under the July sun, devouring ladies’ heels. A plumber’s strike deprived the park of drinking water and a gas leak required much of it to be closed. Negative press followed. But Disney stayed true to his vision and eventually things turned around. With this tale, Mr. Dalton seemed to suggest: if Walt Disney had trouble with this customer experience thing, maybe the rest of us should lighten up a bit. As in most situations, progress is better than perfection.
“If Walt Disney had trouble with this customer experience thing, maybe the rest of us should lighten up a bit.” (tweet this)
#2. Firms are getting better at CX delivery. Forrester’s Megan Burns took the stage to talk about CX maturity. She reported that the concept of customer experience, which Forrester has tracked since 2007 with its annual Customer Experience Index, has now reached its gangly adolescence years. While great experiences are still rare (hence the title of the conference) truly awful ones are on the decline. Until recently, few organizations knew that measuring their CX maturity was something they should, or even could, do. Now with eight years of data as evidence, she offered three “universal drivers” for CX maturity and loyalty:
#3. We’re all competing with the best. Katy Keim of Lithium Social Web spoke about the social media revolution and its impact on customer experience. Noting that “CX = delivery – expectation,” Ms. Keim neatly distilled the challenge to its essence. As customer expectations have become more and more “extreme,” firms find it harder to stay ahead of their customers’ needs. And when it comes to expectations, companies no longer compete only with others in their industries. Instead they go head-to-head with the Netflixes, Ubers and Amazons of the world. These brands have redefined what customers should want, and in doing so, have recalibrated the CX benchmark for every category. Increasingly, firms that fail to live up to these extreme expectations will been seen as “unresponsive.”
CSS multi-language support
Chiuhua Chen, senior front end developer and prototyping expert at Perficient XD, is currently working on a web application that has a visual design supporting only english language. As with every other project, the business later on proposed support for multi-language support. When the application is in another language, spanish or Chinese, due to design constraints, the page appears messed up with some text occupying more width than what is actually allocated. On further research and checking with other peers, Chiu is working on implementing language specific stylesheet which would override the generic css file to take care of this issue. Lead front end developer Jacob Schulke has a few good points on the topic and has already shared his thoughts here. To learn more on how Chiu is tackling the multi-language css support issue, get in touch with her here.
Apache Virtual Hosts
Derek Montgomery, senior front end developer at Perficient XD, with a strong penchant for infrastructure setup and command line coding, is currently working on setting up a new virtual host for Perficient XD and doing further research on the topic, agrees that “If you have made a website, you have probably used Apache. One widely used application of virtual hosts is shared web hosting, whose prices are lower than a dedicated web server because many customers can be hosted on a single server”. He points out virtual hosts can potentially solve problems such as -
I was talking to a colleague a number of weeks ago and the topic came up of where mobile was headed now that smartphones/tablets have become “commonplace”. The three areas that seem to get a considerable degree of focus is wearables (whose hype will be even further boosted if Apple releases the rumored iWatch on September 9th), Google Glass, and Bluetooth Low Energy (the catchier-named “iBeacon” to you iOS types). As a mobile architect, trying to keep up with all the things going on with mobile, I try to keep the deluge from being overwhelming by focusing on those mobile technologies that have enterprise applicability and that clients may come to Perficient seeking expertise. Therefore, I told my colleague that I had dismissed both Google Glass and wearables as more consumer-focused and that my focus was on the possibilities of iBeacons in the enterprise.
However, after a number of subsequent conversations with other mobile architects and articles such as “Salesforce.com sees wearables catching on with customers, partners” has caused me to rethink my position. While I am not confident in Gartner’s claim that by 2017, wearable devices will drive 50 percent of total app interactions, I do believe there is a place where having access to data on your wrist (rather than digging into your pocket for your cell phone or having to have a tablet in one hand) or a headset will have advantages to various classes of enterprise users such as those who require hands-free access such as industrial (warehouse, transportation, etc.), healthcare or in the case of one enterprising firm, replacing access key cards with a wearable.
The challenge for mobile architects and enterprise IT in general is to understand how wearables could provide an advantage to the business (by actually going out and observing how warehouse workers may be using ruggedized tablets now rather than clipboards or rolling computer kiosks and how a wearable could provide an even more productive work environment) by starting to take a look at this technology. This means short R&D initiatives with minimal investments in both hardware and developer time (taking fail-fast to a new level) and developers open to new approaches in terms of screen size, data input, even further optimization of enterprise data access over what is needed for smartphones and processors/memory. In addition, after the issues that firms have had with BYOD in relation to security and mobile device management, determine if wearables create issues that smartphone access to the enterprise did not already expose. If so, better to address it now rather now in an R&D mode rather than later, when you are creating a true business application. The final issue of course is to determine which platforms will break out with many new watches (Apple iWatch, Moto 360, Samsung Gear ) being released and all of which are jockeying for position.
A mobile application has very little function without data to work with and enterprise business mobile applications, even more so. This has given rise to the visibility of application programming interfaces or APIs within the enterprise. Businesses are using APIs to allow visibility to certain business data to business partners outside the company. This concept is nothing new, businesses have been sharing data through Electronic Data Interchange (EDI) and Value-Added Networks (VANS) since the 1980s. However, in the last two years, the spotlight has again shown on APIs as the linchpin to support mobile development.
One facet of creating APIs to support mobile development is Microservices which are small, single-purpose, server applications and that can be composed together to form other server applications. The idea is that a microservice does one thing well and executes as a standalone application within a server container (which is one of the differentiators between microservices and their larger SOA brethren). A number of IT technologists have equated microservices with the idea of Unix shell pipeline apps in that they share characteristics such as “small”, independently deployed in their own container, may communicate with each other and are loosely-coupled. James Lewis and Martin Fowler of Thoughtworks published an excellent paper that covers Microservices 101:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
You can say that the above statement could also fit SOA but Lewis/Martin call out how microservices are different enough to stand as its own architecture.
One of the reasons that microservices is a popular choice for mobile development is that each service can start out small, the developer can work both sides of the effort, creating both the mobile app and the service to support it, iterating the services to meet the needs of the mobile app and simply deploy the changed service without coordinating with other developers or the service development team.
This leads into the second trend besides mobile development that has pushed Microservices to the forefront which is the shift to DevOps and Continuous Delivery as another key enabler. The reason for this is that microservices support the need for quicker, independent development (no teams), easy rollback, developer-owned (no handoff to the service support team, it follows more of the “you built it, you support it”), and frequent releases.
Microservice allows an easy and flexible way to integrate automatic deployment with Continuous Integration tools familiar to developers such as Jenkins. That is not to say that microservices provide some type of free-lunch; once the size, number and complexity of the services move out of infancy, a number of issues need to be addressed including operational overhead, a higher level of DevOps skills and the complication of managing a large number of services, many of which perform some level of service inter-communication.
SOA has been around for quite a while and it is difficult to remember when it was the new kid on the block. For the most part, service development around REST and the JSON data interchange format has taken hold and microservices has made it easier for the mobile developer to easily and quickly build/deploy the services needed to support a mobile application.