Blog

22 August 2014

What’s so great about Android? Let’s start with customisation

Our office is almost split down the middle when it comes to the iPhone or Android battle. Each time a colleague is about to get a new phone we all try our best to convince them that our operating system is better.  People seldom change sides but it’s still an interesting debate.

Philip Langley explains just one of the many reasons that he prefers Android in his post:

Customisation: the heart of Android. 

 

Remember that feeling playing with Lego that you could build anything your imagination could come up with? Sure, it may not have been 100% perfect but you could play with something that previously you could only dream of. That’s the same feeling I get from customising my phone.

my android homescreens

18 August 2014

Usability testing for agile software teams

By Phil Barrett

I did a talk at Agile Africa last week.

A couple of key points:

  • The really valuable kind of user feedback often doesn’t just come to you. If you want good quality feedback, you have to go get it with usability testing.
  • It’s easy to forget to gather user feedback because Agile projects deliver incremental, gradual change… so you don’t notice how far your interface has come.
What your customers REALLY think: Incorporating usability testing into agile from Phil Barrett

18 August 2014

Designing for Behaviour change

By philbuk

I did a talk recently for the UX craft meet up ion Caep Town about designing for behaviour change.

It’s a kind of glorified book report covering Dan Ariely, Nir Eyal and Stephen Wendell. All squeezed into 45 minutes. People seemed to like it!

Designing for behaviour change from Phil Barrett

6 August 2014

How to run a good usability test

By Marc

At Flow we do around 300 usability tests every year – an average of about 6 users per week. Here’s some of the top user testing tips we’ve gathered over the years.

Don’t

Don’t complete their sentences

Even if you think you know what they’re going to say, you really don’t. Keep quiet and wait for the user to finish talking – even when they’re a bit slow in finishing that sentence.

Don’t use leading questions

“Does that make sense? Do you like that? Was that easy?”

Most people will answer ‘yes’ to that kind of question, because most people want to please the moderator. These kinds of leading questions will lead to false results in your research.

(more…)

27 July 2014

Research in Nairobi

By David

I visited Nairobi recently to do research and usability testing. Besides being my first visit to Kenya, two things excited me about going. Firstly, putting websites in front of people to find out what they think about them. And secondly, to get a better understanding of what mobile first, or mobile only, means in a country like Kenya, described as the epicenter of mobile innovation.

The battle is fierce for the hands and minds of Nairobi’s mobile phone users.

Doing research

I was going to Kenya because there were things we didn’t know – and talking to people firsthand is the best way to find out. In Nairobi we teamed up with a research company who provided space where I setup two laptops, a smart phone, and a mobile testing sled, and armed with a modicum of background knowledge, I interviewed ten people and tested two websites.

Usability testing on the move: two laptops, a smartphone, and a mobile testing sled.

Before starting a research project I sometimes worry that I won’t find useful information, either because I don’t have the right questions, or that I’m looking in the wrong place. I then remind myself that the only predictable thing about doing research is that you can’t predict what you’ll find. You have to get stuck in and do it, and be prepared to, as Erica Hall writes: Joyfully release all of your preconceived plans and ideas. In time I’ve learnt that this sense of apprehension comes from the fact that preconceived plans create a kind of comfort, whereas what you discover in research can change the entire trajectory of a project. And that is what design is all about.

The trip reminded me of three things

  • The global village is mediated by technology, it provides a universal language of sorts, the result is that on the surface we all appear quite similar, but it is a trap that can hide local knowledge and insight from us.
  • Africa is described as a mobile first continent. But it does not mean that mobile is the solution to all problems. Talking to people is the best way to avoid generalisations.
  • When we look at interfaces we interpret meaning, putting things on screen entails taking responsibility for how we assume others think, testing means owning up to that responsibility.

Reflecting on what to do next I’m reminded of Rebekah Cox’s definition of design:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions. 1

Finding out what you don’t know is not a guarantee that things will be easier – the opposite often happens – but you’ll have information to base your decisions on.

And that is why we do research.

29 June 2014

From contracts to collaboration

By David

There are two sides to being a consultant.

On the one hand you get to work with a wide range of clients on projects that are varied and interesting. You’re exposed to different perspectives and ideas, and if you’re open to them it means you’re always learning. It keeps you on your toes and that’s what I like about it.

On the other hand, you are usually contracted to produce a deliverable at the outset of a project with limited scope for change. Sometimes you realise that what you’re doing is not exactly the right thing, but you’re somehow stuck in a one-way project track where your ability to create change is limited. This always feels like an opportunity lost.

But there is hope. Imagine a move away from purely deliverable-based contracts. In Lean UX: Applying Lean Principles to Improve User Experience Jeff Gothelf argues that we:

… give up the illusion of control that a deliverable-based contract offers but gain a freedom to pursue meaningful and high quality solutions that are defined in terms of outcomes, not feature lists.

So instead of working mostly in isolation, making something, you turn the process on its head by involving clients more in what you’re doing. What becomes visible is the boundary of a process and not the physicality of a thing. This has many advantages, Jeff Gothelf continues:

… both agency and client benefit form additional insight, feedback, and collaboration with one another.

The learning from this process may reframe the problem, or for example, bypass the creation of a wireframe deck completely, leading straight to the creation of a MVP.

Insight, feedback, and collaboration are the necessary foundations for making better products. Getting there requires boldness and a desire to explore, from both consultants and clients alike. And I think it is a risk worth taking.

11 June 2014

A unified product management framework

By Phil Barrett

If you want to succeed as a digital businesses you need product management. But understanding what product management is, or what a product manager does, can be difficult. I thought a diagram might help.

Part of the problem is that product managers need to adapt their approach based on context. You might be product managing a startup, searching for a killer business model. Or working in a large corporation, creating a digital interface to an existing business product. Or perhaps you’re managing software that has been around for years, with dedicated and vocal users.

Tactics will be different in each case. But there are some fundamentals about the process that stay true regardless. So I came up with this.

The product management process

Three phases, four tracks

All in all there seem to be three phases. They can vary in length and importance, and there are different tactics you can employ in each one. But there do seem to be three. I’ve called them product discovery, ship MVP and grow incrementally.

And in each of the phases, you should be doing some of everything: Designing, planning, building and learning from customers.

What changes from phase to phase is the balance and purpose of the activity on each track…

(more…)

5 June 2014

Future of the hamburger icon

The Android Google Plus app is experimenting with an alternative navigation pattern by removing the hamburger icon and replacing it with a drop down called “everything”. If Google is considering losing the hamburger icon, does it really have a future?

Chris discusses this and possible alternatives in his blog post:

The future of the hamburger icon

 

Screen shot of Google plus's 'everything' dropdown

2 June 2014

Designing and releasing a good Android app: Tips from Mxit

Mxit has launched their new Android app recently and it’s getting a good response from their target users. I chatted to Ryno Kotzé and Maia Grotepass, two members of the dev team, about how they did it.

Getting the right balance

And example of chat cards on Mxit for Android And example of a backdrop on Mxit for Android

As advocated by the Kano model, the new version contains a mixture of basic expectations, new functions and delighters.  For example…

(more…)

29 May 2014

Design thinking meets urban planning

By David du Plessis

The psychologist Rom Harré wrote that ‘the primary human reality is persons in conversation’. It’s a validating idea for design thinkers and user-centred designers because we do a lot of talking, and listening, to find the emotional touchpoints between people and products.

With Harré’s quote in the back of my mind I joined a World Design Capital 2014 co-design workshop, teaming up with members of the community, city officials, and fellow designers to talk about regenerating the Gatesville Central Business District and the Lansdowne Civic Precinct.

The co-design workshop was structured as an end-to-end design thinking process, and for many participants it was their first encounter with design thinking. But the premise of the day was that everyone is a design thinker, and we were encouraged to participate in conversations structured by the primary design thinking stages of:

  1. empathy, context and ideas,
  2. creating a vision,
  3. prototyping and iteration.

Empathy, context and ideas

First up, members of the community told their stories, setting the scene and context for the workshop. Next, they brainstormed the challenges faced by the two sites in their community, followed by a card sort and voting session to identify and prioritise the key issues.

*Voting in progress to whittle down prioritised issues.*

Voting in progress to whittle down prioritised issues.

(more…)