Exploring the Google Glass UX

As wearable devices enter the mainstream, UX designers must develop ways to maximize those devices’ potential while acknowledging the new limitations they impose. That’s what the software team at ELEKS concluded after evaluating Google Glass – an experience that allowed them to abandon their expectations about head-mounted wearables, adapt user experiences to tiny screens, and forget about keyboards altogether. For many UX designers, Google Glass evokes visions of an Iron Man-like interface with numerous controls and augmented reality features. Our team at ELEKS, too, fell victim to these assumptions. It was only after designing and developing multiple applications for Google Glass that we began to truly understand its distinctive features – and how to work within its limitations. In particular, we came across numerous technical and contextual challenges that few in the UX space will have encountered before. As the market for Google Glass, and thus the market for compatible applications continues to expand, we feel it is of vital importance for UX designers to share their experiences creating applications for the device. It’s in this spirit that we’re sharing our own. Photo Credit: lawrencegs via Compfight cc Technological limitations We began playing with Glass in August of 2013. Since then, our team of designers, analysts and engineers has worked on seven related projects, ranging from business concepts to fully operational applications. Most of the projects catered to unique usage scenarios and provided an application from which clients can benefit, either by opening new opportunities or by optimizing business processes. First, we discovered that the predominant way to interact with Google Glass was via Mirror API, which showed text...

Breaking the Constraints

On August 7, 2014, UX designers and developers around the world cheered to the news that Microsoft would officially drop support for older versions of Internet Explorer, effective January 2016. Yet by and large, the outcry was less “hooray for Microsoft!” and more “why didn’t they do this sooner?” The answer is “because people still use IE,” and yet people still use IE because it’s supported, and it’s supported because people use it. It’s a vicious cycle. Two years ago, Nicholas Zakas wrote an article for Smashing Magazine entitled “It’s Time to Stop Blaming Internet Explorer,” in which he said: It’s not actually old browsers that are holding back the web, it’s old ways of thinking about the Web that are holding back the Web. He went on to explain that constraints will always exist, be they older browsers, business requirements, or user needs, and it’s the UX designer’s job to focus on what can be done rather than how to rid the world of the constraint. It’s an intriguing idea. We do work within constraints on every project, and many of them will never wane no matter how much we complain about them, but some constraints can be cracked, or at least altered, if we know where to begin. We’re often told to ask for serenity to accept the things we cannot change, courage (or coffee) to change the things we can, and the wisdom to know the difference. By understanding where constraints originate and why users react to a given constraint the way they do, we can gain the wisdom we need to identify whether each constraint...

What a Difference a Lab Day Makes

Four years ago CauseLabs started setting aside one day every two months for our team to build projects of their own choosing. Little did we know the impact these lab days would have on our company’s internal motivation, our employees’ skillsets, and our ability to work collaboratively in innovative ways. Now, four years in, we’ve broken down our insights into best practices for other companies to follow, to help them achieve similar success. Innovation days go by many names, but the key elements are consistent: Bring together a few people, set up a basic process, and tackle acute problems. At its core, a “lab day” is any amount of time devoted to team collaboration on an agreed upon problem or project. Companies from Google to small start ups are finding that committing to lab days can make an immense impact on productivity and engagement in every other area of their business. Lab days engage our imaginations, address our restlessness, and allow us to tinker. During a lab day the blinders are on to other projects, email, and all other distractions. Teams of one to three people build for a set amount of time, then join with other teams at the end of the day to demo and get rapid feedback for next steps. Any organization with design thinkers and makers can use time like this to solve problems. Our path to lab days At CauseLabs, a software strategy firm, we began lab days a few years ago after one of our staff members came back from a conference with the idea of doing an internal day of innovation. Nonprofits...

The Ethics of UX Research

As a UX researcher for a social media operation, Ute considers different interface designs that might allow users to make more social contacts. Ute gets a radical idea to test her hunches: What if we manipulated some of our current users’ profile pictures and measured the impact of those changes on their friends list? If successful, her research would provide valuable insight into the social media design elements most likely to result in sociability online. Of course, a successful study would also diminish the experiences of thousands already using her company’s service. In Ute’s mind, this is a simple A/B test, yet in the wake of recent controversy surrounding social media research, she’s starting to wonder if she should be concerned about the ethics of her work. As a research scientist and professor at two different universities, I work to better understand the social and psychological impact of technology on human communication. Our experiments have tested the limits of accepted research design practice, with designs ranging from the manipulation of romantic jealousy using social networks to studying the impact of induced stress and boredom on video game experiences, and a host of other experiments and observations. Yet, these studies all share a common element: they were all subject to intensive internal and external ethical review practices to ensure that participants in these studies were both informed (either before or after the study concluded) and unharmed. On these two points, recent debates surrounding the recent Facebook “emotional contagion” study have centered on notions of informed consent (Did Facebook users know they were in a study?) and minimizing harm (Were any...

Progressive Content for Progressive Reduction

Every new interface we come up with is also an exercise in instruction design. Designers typically leverage their user’s prior knowledge to create innovative experiences and help users learn how to navigate those those experiences. But how might we teach our users new, complex processes (or changes to their existing behavior) while still maintaining a simple UI? Last February Allan Grinshtein, an interaction designer at LayerVault, posited that because a user’s understanding of our application improves over time, our application’s interface should adapt. Others agree. Increasingly, designers are finding opportunities to design interfaces that better adapt, or personalize, their layouts and functions in accordance with their users’ individual knowledge—predominantly through progressive reduction and progressive disclosure. Progressive reduction is a theory that suggests that certain information should be diminished or simplified over time. This assumes that advanced users, who frequently access the application, will learn and remember basic functions and no longer need help text or additional labels. LayerVault shows how UI copy and design is personalized to different levels of user-expertise using the principle of progressive reduction. Image from LayerVault Blog. The insight behind progressive disclosure is similar: it relies on the belief that users need to have more complicated information ‘drip fed’ to them over a period of time. Jakob Nielsen puts it well: “Good usability includes ideas like progressive disclosure, where you show a small number of features to the less experienced user to lower the hurdle of getting started and yet have a larger number of features available for the expert to call up.” Progressive reduction and disclosure are theories that apply to presentation, but presentation...