Macadamian Blog

World Tech Jam is Almost Here!

Every two years a very exciting event takes place in a different country around the world. No, I’m not referring to the Olympics; I’m talking about the World Congress on Information Technology (WCIT).

Probably the world’s leading information gathering, WCIT brings notable speakers and business leaders from all over the world together for a 3 day conference to be held in Montréal, from October 22 to 24, 2012, at the Palais des Congrès de Montréal.

This year’s WCIT is also bringing something new, and perhaps unprecedented, to the world stage, a World Tech Jam scheduled June 5 – 7, that will not only kick off WCIT 2012, but is meant to actually lead the conversation of the October event by giving users a voice. The results of the JAM will be twofold:

1. To create a Digital Agenda to help maximize the benefits that digital technologies can unlock across diverse sectors and institutions.

2. To influence on the WCIT 2012 program in October.

How do I prioritize different types of customer data?

On a recent webinar we gave on User Experience Design, I was asked  How do I prioritize different types of customer data? I thought this was a great question and decided to share it, and my answer.

Question: When you have too much data, from many different sources, how would you rank the value of the data - for example, I have usability testing data, customer interview data, customer submitted enhancement requests, sales enhancement requests, marketing enhancement requests, support enhancement requests, R&D technical priority enhancement requests, win/loss data - I am swimming in data and not sure what to do with it - how are sources generally ranked?

First and foremost I would start with my business goals and audience personas or top critical use cases as guiding principles.

Ideally the roadmap has a few tracks, one that is always customer centric, and the other tracks can map to other business goals like "support sales staff."

• I would map the feedback to those goals.
• I would prioritize the customer feedback above internal request.
• I would ask everyone submitting feedback (internally) to map their request to the goals and prioritize before sending them to me. I would also ask them to go through the "trouble" of defining the expected outcomes and the risk associated with NOT doing it. I would probably have them force-rank the request too. Force everyone to think in terms of business and customer goals, if they can't make a case they may leave some things off the list. Not only will it reduce the number or requests, the additional information you gather will help you prioritize.
• Regarding the customer feedback, I would look for patterns in the customer interview data. Since it's not quantitative, it's best to look for major themes related to critical use cases. Don't try to reply to each person's requests. Regarding usability studies, I would prioritize the stuff that is getting in the way of task completion. Same goes with the customer feedback requests - I'd look for patterns and I'd validate that the feedback is coming from target users.. I'd look at all the customer feedback as a whole. It's hard to say which of the three I'd prioritize above the other, but I'd definitely prioritize it above internal feedback.

Ideally you also have metrics in place tied to the business and customer goals, to watch the performance of the product against these key metrics. You should be proactively looking at this regularly and thinking about what you can do to optimize the performance, especially if it will also help address the customer feedback you are getting.

Of course, it's not like there is a simple answer. It takes a lot of work, and if you find there is no time to make sense of it, maybe it's time for a new hire

Exposing your team… to your users!

A great blog article was sent to me by a fellow researcher regarding a way to improve the designs teams produce. The solution… more exposure hours. It was found that by exposing all team members to the design’s end users helped improve the final product.

Exposing team members to end users means participating in field visits and listening in on interviews and usability tests that help uncover user’s goals and objectives.

For a project I recently worked on, I conducted field visits and interviews with a number of users and user groups. Reporting on the findings to stakeholders that had not participated in the research activity led to some conflicts and discussions at design and product development meetings since they weren’t as familiar with certain ways their product was being used. Not connecting with their end users has lead their design to become more complex by the addition of features and capabilities so it was great to see that this first step had been taken and an importance placed on user experience (UX).

Let’s compare that scenario to another project. For this project, a number of stakeholders actively participated in observing design concept walkthroughs and therefore, were much more educated in the subtleties and nuances of users’ interactions with the design. Seeing the problems users were running into led to insights behind their potential causes and gave everyone new ideas for a better solution. When everyone has a chance to come up with solutions, it helps the core design team become aware of other influences to the design, which may not have been considered or mentioned previously.

Designing with a Rubber Stamp Doesn’t Work

"Fred, our app is everywhere and not one single platform is the same, aside from our icon." That's a quote verbatim I get from time to time. My client in this case is expressing a need that he would like to have the app the same everywhere. It reminds me of a rubber stamp; I have a design and I duplicate it everywhere. This is a tempting approach to save cost because we think it's the way to go, but it doesn't work. We all know it doesn't work that way to a certain degree - clients included - still what is the root cause of this kind of comment?

Do Your Homework Before Porting an iOS app to Android

With the rise of Android’s popularity, product managers with an existing iPhone or iPad product are under pressure to port it to Android. While porting from iOS to Android is certainly possible, we have found teams almost always underestimate the amount of effort required.

Porting an iOS app is not a trivial matter because there are a number of Android elements not present in iOS, and vice versa. When the product manager or designer tries to preserve as much of the iOS design as possible, developers frequently devote a great deal of time replicating the iOS controls and workflow because they do not exist on Android. The result is a product that releases late, and ultimately alienates Android users who have become accustomed to Android-specific interactions. For those who are planning to port an application from iOS to Android (or are already knee-deep in this surprisingly challenging endeavour), we’ve put together a list of recommendations.

Re-use Data Organization and Grouping of Controls

The data organization and grouping of controls into screens can be reused from an iOS product in a direct mapping. The relative control placement does not need to change, although it is typical to move the “tab” control from the bottom to the top of the screen.

Use Native Android Controls

Android controls are much easier (and less costly) to implement than custom controls so they should be used wherever possible. Google, like other UI toolkit makers, spent more effort on its UI controls than most app developers can afford. This makes it difficult or impossible to replicate many iPhone interactions on the Android platform.

For example, “lists” on the iPhone can be pulled down to reveal a search control. While this can be easily replicated on an iPhone app, implementing the same behavior on an Android app, and making the transition smooth, would require a significant investment.