Meta Refreshed.

Meta Refresh 2014

It’s been close to 5 months that I have moved to Bangalore.  Today, I attended Meta Refresh 2014 for the first time along with a bunch of designers and developers from Adobe. One of them was a even presenting about SVG. I was pretty excited about the whole 2 day conference and the sessions that were going to be conducted. However it kind of didn’t go that well. Meta Refresh turned out to be a bit disappointing for me. Leaving that aside, the conference had a lot to offer despite the overall disappointing set of presentations. I wanted to do a post that covered the entire 2 day conference, but decided to only throw in the most relevant bits I picked up.

Vision is different from ideas.

I have a vision. I have an idea. I have a vision and an idea. I going to take that vision and that idea and build a product. I’m super awesome. No. Vision is the long term goal. Idea is the path to that goal. Ways to get there change. Some work. Some fail. Some ideas are good and some are bad. Having said that, it’s only natural that we change our path to our goal as often as possible. Sometimes we change our steps, improve the idea, sometimes backtrack or ditch the idea, because we thought of a better way – a better idea. The point still stands – the vision never changes, despite the ideas that change. This is a subtle warning that we often very easily overlook. Define our products on a vision and not an idea. Change how you want to build it. Don’t change what you intend to do with it. Decouple the vision for a product from the idea you have for the product. People on a team need to have different ideas. But most importantly they need to have one vision. Building your product involves validating your vision. Post that validating your idea for it. Validate, prototype, test and iterate on the ideas. But focus on the vision. When both the idea and vision merge what you end up with is a product based on an idea but a compromised vision. Drive the vision on a solution to a real world problem. Drive the idea on user’s feedback. Very often we are building products with a vision that already have others in the same domain. Simple – We need to disrupt. We need to incrementally improve. That’s where we need to change our ideas. There is no harm in building products with a vision, a vision shared by thousands of others. What matter is the way we solve it. The way we fulfil our vision. They way we build it. The idea we build it with. Have a vision. Have several ideas. Many may have the same vision. Don’t bother. A few may have the same idea. That’s where you need to improve. You need to disrupt. Keep the vision, change the idea.

It’s not full responsive. It’s  called full responsibility.

You designed a fully responsive site for your product. Awesome.

  • Case A: I’m guessing that means it’s fully accessible to your all the users. Well my site site can easily resize within the browser. Well most browsers. Well most modern browsers. Okay maybe guys with IE probably won’t be able to access it.
  • Case B: I’m guessing that means it’s fully accessible to your all the users. Well my site site can easily resize within any browser. Definitely all browsers. Yes, I even considered for IE. Okay maybe it will work but I’m sure if it’s still functional.

Clearly full responsive is not full functional. We build for the web. The web is a medium. Browsers allow us to access that medium. And what the web contains is experiences. When we build, we need to design for full responsibility. Responsive is good. Responsive is needed. But functional is more important. To think of it the web grows so fast. The way the people access it changes every day. The medium through which they consume these experience changes every month. And the content experiences that define this web change every second. The web is changing faster than we can imagine. Build with backward compatibility. Don’t just design for backward accessibility. Design for backward functionality. I guess here’s where it makes sense to build your online product as a stack of blocks. Build it in a way that even if a block doesn’t play well with browsers from 3 years ago, that domain of users can still access as well as use it. It’s hard to build with independent blocks and fall backs, but that’s the need. You can’t assume that just because you keep up with the fast moving web, so do your users. The pace is very different. Their access point, and means to access the web change slowly. So designing full responsive is not the answer. Designing for full functionality is the answer.

Design for the workflow not the task. 

We often tend to build products with a single model. A model that we assume fits all our users. If it doesn’t we usually state those aren’t our users. We engineer products based on a model that is almost always focussed on a task. Very rarely on a workflow for that task. Online transactions for example. I keyed in my card details and hit submit.

  • The task is very simple – Debit the amount for the user’s account.
  • The workflow was equally simple – Take the user’s payment details, debit the amount and provide a confirmation.

However we focus  and only design only for the task. So while the experience of filling in my card details was easy and provided a sense of security, the other half of the workflow – waiting for the confirmation wasn’t that good. After I hit submit, pop up windows appear with the age old rotating GIF loaders, some including even blank screens, all one after the other keeping the user pinned and clueless till it all goes away and few seconds later a confirmation message appears. Clearly we missed this part of the workflow. The part where the user waits for his confirmation. In the offline world, the user hands over his card, it’s swiped and the transaction is completed. Doesn’t it make sense that we map this same experience to the online product we are building for that same very task? Yes off course. What was missing in the above design was the part where you continue to engage a user even after he has completed his part of the workflow. It’s absolutely necessary to engage the user with visuals that don’t boggle him but atleast let him know that stuff’s happening behind the scene. Having said that, progress bars or animated GIFs are not the best options. Designing for these workflows involve carefully replicating the user’s offline mental model with value proposition and trust symbols. In the real world the when the user swipes his card, does he see how the transaction being processed from the device to the provider? No. So then why online? Think about it. All he cares about is, take the money, give me my service and confirm it’s completion. Hide the unwanted details but map every single action with relevant feedback.

Design Escalators not Elevators.

Probably the best thing I heard all day. Design escalators and not elevators. Both serve the same purpose. Take a person from point A to B without having him to walk that path. Heres the thing, you lose power, the elevator stops. The person is stuck. You lose power, the escalator stops. The person is not stuck. He can still walk up. Design needs to be like this. Design needs to have a fallback functionality. Products need to be able to engage with users even when they have no power or means to and for that they will need to rely on the design  – needs to be like an escalator.

Advertisements