Macadamian Blog

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.

Product Managers, Designers and Developers Need to Work In Parallel

Perhaps the most challenging aspect of modern software creation is having multiple team members—designers, developers, architects—working iteratively and in parallel. Wouldn’t it just be easier if Product Managers completed their requirements definition, then handed it off to designers to create the full design, who then handed it off to development to build and test? Easier? Maybe. Will it yield a more successful product? Definitely not.

There are a couple of reasons functions can’t “take turns” sequentially designing and building a product:

1. The steps are not sequential. Designers need to test that a design is working over the course of development. Product Managers need to adapt requirements as they get updated competitive data.

2. Designers need room to be creative, and that means the ability to fail and iterate.

3. Part of success is releasing in time to capitalize on a market opportunity. Working in parallel with daily communication is much faster than sequentially. Here is a glimpse at how we’ve seen very successful teams manage this idea of mass parallelization and iteration.

Start With Back-End Development

Many developers are used to the idea of developing the UI first and then implementing back-end functionality progressively. This is normal—business stakeholders are visually inclined and have always put more emphasis on having the visible parts of an app built first for things like demos. How many managers do you know that see a UI with no back-end and assume the product must be almost complete, when in fact the back-end has barely been started?

Developers who are comfortable with the idea of starting on the back-end and making sure to have a robust data model while the designs are being fleshed out typically thrive in modern software environments. They recognize that well architected software has a clear divide between the front-end and back-end and starting with the back-end actually contributes to a solid architecture. What this means is that Product Managers need to work closely with the architect and developers early on to establish the data model based on product requirements. Follow the requirements advice we gave earlier, and you should be in good shape.

Argentina innovation: Frozen Beef!

Last October I was in Argentina,  a vacation my spouse and I were very keen on. It was a blast and in the cloud 9 experience category. We got to visit parts of a great country with great people. What I want to talk about though is what I discovered there when doing the tourist stuff.