Google is running a two day User Experience Master Class in Cape Town in October to teach developers, designers and product managers how to create great apps and websites using the principles of user experience.
You’ll not only be introduced to the basic concepts of UX design, you’ll also learn the most important practical techniques used by UX designers such as user research, scenarios, information architecture, and wireframing. You’ll be working hands-on in teams to practice these techniques which you can then use to improve your own designs.
There’s also a chance to learn from some local developers who will discuss all the UX considerations they took in their app’s design and development.
The class will be presented by two members of the Google UX team who are experienced in all things web and mobile. As experienced user experience designers, Flow will add local support.
Date: 7 & 8 October 2014
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:
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.
By Phil Barrett
I did a talk at Agile Africa last week.
A couple of key points:
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!
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.
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.
“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.
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.
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.
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.
I discovered this quote in Making it Right: Product Management for a Startup World by Rian van der Merwe. ↩
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.
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.
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…
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:
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.