A Quick Look at ambient UI

We’re now so blasé about our Computers, Phones and other devices , that what has become far more important is our experience when interacting with them. Over the past few years we moved on from the wonder, discovery and acceptance phases and landed directly in the impatience phase. If you don’t think this is true here’s a little thought exercise for you:

Image by Gleb Kuznetsov✈ 

Quick test

The next time you are in an elevator and the door takes about 5 seconds (yes 5 seconds) to start closing, do you or someone in the elevator hit the close door button? Now think, after the button is pressed and the doors have started to close, do you feel better or at least less impatient?

"Ok brace yourself”

In a study by the New York Times, 3,250 elevator close buttons were tested, most were found to be mechanical placebos with a mere 120 working buttons found. That’s right, just over 3.5% of the elevator close buttons actually did something.

 

Ambient Computing

This brings us to ambient computing. Today’s user, expects things to ‘just work’. Look at keyless cars. If the driver is close to the car and has the key in their pocket, the car just opens, making the pressing of the unlock button unnecessary. In the same vein, we are slowly falling in love with virtual assistants to avoid tapping those buttons. Why navigate through pages and menus when you can just talk to a chat interface and order your next coffee, turn off the lights or play a music track.

In the same way that your phone most likely no longer has a physical keypad and has beefed up its voice-based assistant,  you can now talk to your car, your lights, your watch and even your fridge. How many times have you set timers, a reminder or asked how to spell Goondiwindi (sorry just need to ask Siri and he/she got it on the second try). Interestingly, Google Home could not spell Goondiwindi after several tries, "I guess you can’t believe what you see on TV (Google Home TVC)"; without even needing to tap a button. Just speak and your house obeys.

I am willing to admit that I am worse than most here. My lights turn on when my phone connects to my home wifi, my front door unlocks when my smart watch is within 2m, the security system turning on, air conditioning turning off if my smart watch goes more than 100m from the house and so on.

With your BMW having keyless entry and go, gesture control and self guidance assist, your iPhone containing a modified PowerVR Furian GPU and iOS 11s AR kit, Hue lights, Kwikset Kevo smart lock and Alexa added to your LG fridge. This all means that you can drive home listening to you favourite music, park your car, find that your fridge has ordered groceries (having consulted www.foodswitch.com.au beforehand to improve your health), your front door unlocked, the lights on and the house at the correct temperature all without tapping a button. Oh and you will be able to look through your phone screen using AR to see exactly how to make the meal your fridge has ordered for you.

That’s right you or other machines are talking to machines. We humans just sit back and expect results.

 

What does that mean?

So what does that mean for the average business looking to develop a website currently?. At it’s most basic level, as we expect our interactions with technology to be increasingly seamless, it means a lot more development expertise will be required. And definitely means that you can never set and forget your site as the oncoming iteration is even more important than it’s current state.

This is because removing the interface is not a magic trick, it’s the development protocols and systems that take the place of user interface, and that’s a lot harder than it seems. Designing and building protocols is far more time intensive and requires a deeper understanding of the user’s needs and human systems or expectations as we map methodical freeways of human-designed protocols.

The way we interact with Devices is taking its first evolutionary steps since the 70s. So it's time to make sure you have a good relationship with your UX team and have a strong team of developers because at the end of the day you're users will simply expect it.

User-centered Development in not a fix Process

Which camp do you were fall into

Do you believe that timelines and process kill creativity or do you believe that a predefined rigid process is the only way to get something done?

At the far end of this spectrum, extremely dangerous business practices can be found.

So with this I'm going to preach flexibility

I think we can all agree that the integration of user-centered thinking and product development requires structure. But it also requires creativity around user engagement, design and utility.

Also we should to be wary of the need to make money. This means the product needs to be in the hands of the end user.

These words (I’ve deliberately avoided calling them “approaches”)

It’s currently a popular trend to come up with new ways to work through the same problems to deliver the same end result. One month, documentation of any type is dead. And the next month, wireframes are outdated in favour of whiteboard and paper sketch delivery.

A more realistic and humanistic approach is to simply be flexible. Some projects require more detailed documentation than others. For some, you may be able to partner with a developer and draw your wireframes on a napkin over a beer, and for others offshore teams may need overly complex functional specifications, annotated wireframes and interactive prototypes to appropriately deliver your product. Flexibility allows teams to collaboratively define the approach for each project. The best laid plan is specific to the product at hand, the money and time available, and the resources working on the project.

The flexible approach to delivery shouldn’t be misconstrued as being disorganised, and it certainly doesn’t equate to being a pushover.

You must be firm in your rationale for required deliverables and your approach to each project.

Timelines and Process

In order to be successful with a UX strategy or even elements of a UX practice, you need to be able to discuss timelines. As project plans grow they will organically include UX. Until that time, here are some barriers and outlines of typical situations that are likely to occur.

Barrier

Time allotment will have no relevance to the actual items required to be delivered.

Project plans and timelines will likely be created in a vacuum, and UX and UI won’t have a voice. To this I say speak to the people who are doing the work. Have them agree how much time something will take and have them take ownership of this time allocation (if you work with the same people on multiple projects you'll get an understanding of how individuals quote time and you can adjust project plans accordingly).

Supportive/Advocate

Once you have all your resources agreed to and how much time individual deliverables will take, then you own those resources for those allocated times. No other project should infringe on your allocated workflow and on the flipside you need to meet the deadlines set out by your project plan or meet your deliverables when they are due. The flexibility comes here by tracking your burn rate on a daily basis and having your project plans with sufficient detail to know every deliverable element and the exact number of minutes required to achieve each item. You should know long before a deadline that you are not going to achieve it, allowing you to adjust expectations and due dates accordingly.

Work-in-progress

Underlying all of this is the need to proactively share work with all involved throughout the process. Work-in-progress sharing allows teams to better understand the process and approach from beginning to end.

UX and creative teams, especially agencies, are known for intaking a project and going behind the scenes for weeks at a time before the grand reveal.

At this point, the timeline is exhausted. And if there’s objection, the timeline suffers—and, ultimately, so does the end user.

Prototyping and co-designing of product development creates a greater sense of ownership with all parties and delivers a stronger product to the end user.

Business Requirements

Central to software product development is the creation of business requirements. It’s common for UX to react to requirements and create deliverables in response to hundreds of detailed orders. We must change this.

User-centered product development represents this change. Insight user research drives project goals, requirements, and success. All requirements and engineering approaches should be derived from listening to your users at the outset of the project. Ideally, this includes an equal amount of qualitative and quantitative research.

 “Tell UX what needs to go on the screen. Don’t tell UX how it goes on the screen.” 

Think ofbusiness requirements as a list of goals, how they appear on the screen is up to the UX strategist.

Pushback

“Foster positive collaboration instead of a takeover mentality.”

This pushback will likely cause initial friction because business analysts, project managers and producers, who are responsible for creating requirements, tend to fill the UX vacuum when there are no UX professionals engaged in the project. They may view this as a takeover of their work.

But this isn’t the case—their role is extremely valuable, and they can be great partners in helping the UX movement. Foster positive collaboration instead of a takeover mentality—it’ll build a bridge to future work.

Okay, I realise I may have just stated a bunch of things that you probably think about everyday. What is important to remember here is that being flexible throughout in tire project process is the most important step in the creation of an amazing product.

This is an excerpt from Principles of UX Design, an InVision e-course by Timothy Embretson.