First and foremost, gamification is not a game, nor is it even necessarily fun. Gamification is the application of game design elements and game mechanics to non-game contexts and is typically used to improve:
Engagement with the product or service
“Flow”, a concept popularized by Mihaly Csikszentmihalyi
Learning ability or the desire for learning
Ease of use
Three Basic Tenets
As users perform actions (e.g. post Tweets, upload photos, buy products, write reviews, etc.), they are validated by receiving likes, shares, upvotes, or other “rewards”. These serve to reinforce the action and encourage users to continue performing that action because they cannot predict how much “reward” they will receive and will constantly seek more.
Human nature is to seek to see things “whole”. Partially painted walls, half-done laundry, and incomplete DIY projects bother us and generally prompt us to continue until we or the environment around us feels “complete”.
Achievements & Prizes
These can be real or virtual. 4square used virtual badges and achievements to reinforce behavior, but air miles and cash prizes are common real rewards for other platforms.
There are many Agile methodologies out there and many process flows and documentation on how to work. However, those processes are the byproduct of a culture; they’ve been documented after the fact, rather than created as a mandate and sent to the team. If you want to successfully implement Agile, it starts with your C-suite. Top-down support for a shift in the organizational culture is a requirement. Period. Then everyone under them and all the managers under those people and all the employees under those managers need to be empowered to begin making changes to the way they work.
Before you try to be “agile”…
Shifting your entire organization to an Agile way of thinking and operating is a big deal and it is not going to happen overnight (or even after the first several projects). Make sure you’re ready before you take the leap. Ask yourself these questions: Are you (and, specifically, your management team) ready to:
There are dozens of different types of testing and hundreds of different methodologies out there. I’m going to focusing on the big three that we interact with in UX on a regular basis:
User interviews vary greatly depending on whether they are moderated or unmoderated, who wrote the script, and who is conducting the interview. This is a very soft science and a lot of care needs to go into how they are constructed. In general, you will have better results with moderated interviews because you can observe the participants’ body language, correct trains of thought before they derail completely, and ask probing questions when the participants hit on something interesting. So why would you do an unmoderated study, if you’re going to lose all of that insight and control? Unmoderated studies are easier to recruit for and they’re fast; for a lot of companies, it’s that simple. If you’re going to go the unmoderated route, UserTesting.com has a decent platform; but if you don’t have a lot of experience with this type of work, you may find it difficult to get usable feedback. Regardless of the path you take, here are a few things to consider:
When you hear, “Don’t fix what isn’t broken”, you probably think of some iconic luddite from Hollywood; someone who is unwilling to acknowledge or unable to see the fault in the system and has no desire to address it. Unfortunately, sometimes this describes our clients–not every client and not every time–but many of you can probably name at least one project within the last year.
This post is all about why you shouldn’t actually try to fix the things that are broken.
But before I get started, I want to highlight a few exceptions:
In an earlier post, I talked about how UX fits into the development process and ways we could be adapting and improving collaboration. I feel like there is a lot that UX has brought to product development as our field has matured and there is a lot about solid UX principles that we can and should be leveraging in our design process and methodologies.
In this post, I’ll be focusing exclusively on the Planning and Analysis stages of the Software Development Life Cycle (SDLC):
Requirements Gathering (today)
The first phase in most project usually involves gathering requirements. This phase can have a tendency to be very rigid, for example: business analysts conduct stakeholder interviews to get the very detailed answers they need in order to write their business/functional requirements documents. That might be an overly reductionist view of what often happens, but regardless of who begins gathering requirements, what I often see is the following pattern of questions: