Design Sprints are great tools that help answer critical design questions using analysis, design, prototyping and validation. A design sprint typically compresses all these phases into a five-day intensive collaborative workshop.
A design sprint already squeezes weeks and months of design and product debates into a five day process so that the team can save time. It’s great and one of the main requirements of a sprint is to have most of the major stake holders present for the sprint so that critical business decisions can be taken during the sprint.
A sprint is usually divided into six phases:
- Understand: This is where we understand business needs, user needs and technology capabilities.
- Define: This phase is used to define the key strategy and focus.
- Diverge: Exploring as many ideas as possible.
- Decide: Do a prioritization exercise to select the best ideas.
- Prototype: Something that gets the idea across.
- Validate: See what stakeholders feel about it.
While the design sprint is strategically significant, it is time intensive and requires a lot of scheduling to have everybody available for five days. A number of stake holders I’ve run into feel they are unable to devote five days to a design sprint. At times I’ve tried to fit it into three days. While it is a bit cramped it is still possible. But there have been requests to fit the workshop into a single day.
Is it possible to fit a month of discussion into a day?
One of the experiments I’ve tried and been relatively successful is to take part of the process offline.
The idea is to make the ‘Understand’ and ‘Define’ processes asynchronous. Use collaborative tools to get the whole team to contribute. Collate all the responses and meet on a day where two phases ‘Diverge & Decide’ are carried out and the assimilation and validation can again be made asynchronous.
This would mean one day of actual meeting but more than a week of collaborative asynchronous input gathering and validation. It still feels like the whole team worked together on the consensus. But the actual time spent in meeting is drastically reduced.
Would you like to run a design sprint for your organisation? Get in touch…
Your project manager walks in. He wants to release a version of the product that you have just started designing for. And he wants it released before the end of next month.
Not surprising. After all, yours is a lean (and mean) organisation. This can’t be all that bad, especially when you are getting feedback on actual usage from customers. Quickly.
You could call ‘Super Designer’ to the rescue. Or you could look deeper and analyze the situation further.
You realize, for example, that the team is making a number of compromises. To crunch the time required to build the product, they have skipped certain bits of the process all together. User research for example. It has been the first on the chopping board.
But that need not be always the case. You can save research from the guillotine by employing some innovative techniques. By using ‘Zippy User Research’, for example.
This will allow you to incorporate effective research into your lean development cycle. Unlike traditional research methods (or even lean research), ‘Zippy User Research’ is far easier to execute. And need not be resource intensive.
If you have to do an attitudinal research, say a focus group or an online survey, there is a significant investment you would require. Firstly you will have to recruit right. Followed by execution and finally data analysis. Same for usability tests or A/B analysis.
These are valid investments as the returns you will get are significant. However, as a startup, these are not necessarily luxuries you can afford. After all, you want to capitalize on the first mover advantage (what ever that means).
But that should not become an excuse to forsake user research. Usually, at this point, most organisations utilize lean or guerrilla research techniques. Most of these techniques talk about using tools like spreadsheets and SurveyMonkey forms to gather the same old information. In almost the same old fashion. However it is somewhat faster and cheaper. But not by much.
This of course, is better than nothing.
But what if the time you had been severely constrained? In crunch situations, dates and deadlines have already been chalked out by immovable circumstances. Like a conference, for example. Or a potential investor who is available only for a short period.
Is there anything you can do in a situation like this? Something better than relying on your gut.
That’s where ‘Zippy Research’ comes in. Unlike traditional research it removes the constraint of relying on actual users. Making the process a lot faster. And it works much better than simply relying on gut feel.
Additionally it works great for brand new products.
Let’s take a look at what Zippy User Research entails. It is actually not a single technique but a combination of a number of techniques. They include:
- Reviewing reviews
- Role play
- Relating to the future
- Pattern based design and heuristics
Let’s look at these in detail.
Reviewing reviews: When you buy any product, you usually do a thorough review before you commit to buying it. This helps you form an opinion about the product. Tech review, iTunes Reviews and Play Store reviews help you form that opinion. These reviews give you insights into how other people are perceiving the product.
Similarly you can gain a lot of insight into what the user is thinking when they post on the internet about your product.
But if your product has not been around for a long time, making a presence on social media or review sites is difficult.
This is where you might have to go innovative. Look for a competitor’s review on Play Store or iTunes Store. You can even search on Quora for what people have to say about similar products. Or on online forums about how many people are facing the pain points you are trying to address.
You should end up with either a scenario or persona that you built using information you found online. However during the research, you need to be mindful about the task at hand. You will encounter a lot of useless information, but you need to decide soon if the source is worth your investment. Note down every bit of information that will help you define the unmet need more succinctly. Don’t get lost in the sea of information online.
Role Play: Here you could use empathy to imagine what a user would do a particular scenario.
Assign yourself tasks that the user would most likely perform. Note down how you would go about doing it. For example, will you pick up a phone and call for a taxi. Or can the phone offer you a view of all the taxis around your area. Putting yourself into this role play will help you see the obvious advantage one option provide you over another.
Sketching out of brainstorming over possible tasks and then actually doing a role play for each would add more authenticity to this technique. If you have some rough sketches, it allows you to empathize a bit more with the user and evaluate the task at hand better. You can use this technique but the caveat is that you should not to bias yourself based on the design solution you already have.
To avoid bias, it would be better to use this in combination with a hallway research technique. Get someone else (who ideally is not part of your team) to get involved in the role play. Since the person you ask for opinion has no role in the design of the interface, chances of bias are lesser.
Relating to the future: Have you every written you own obituary. Written a press release for an unreleased product. Or interviewed your future self?
This can be a life enhancing experience. Since this involves imagining how you would have responded to challenges and events to come out stronger.
A similar exercise in product development would be to write out future press release for product launches or actually conduct a mock review with a tech writer or blogger that will bring out key challenges and approaches on how you might be able to address them.
Ask questions about situations that require complex solutions. See how you have addressed these situations. This will clear your mind to bring out solutions you have not thought about.
Pattern based design and heuristics: Use existing design patterns like the ones enumerated here (). Or something like Material Design Guideline . Or the Apple HIG. This is not a replacement for design but is a good way to kick-start the process that you get to a MVP.
But essentially you should think whether an MVP works at all. You might actually start thinking about a Minimum Desirable Product.
I’m sure you have been using some these techniques in your design. Maybe have been calling it get feel. But using the technique consciously as design tool, will make you explain the reason you came up with a design with more accuracy. It will also help you release faster. And result in a well designed product that not sacrifice user research in the process of using a lean development philosophy. However think of zippy research as ‘User Research on Steroids’, while it is fast, it is not necessarily healthy…
In a rare event, I flipped the same article into two Flipboard magazines.
But there was: ‘Mindfulness Practices for Better Design‘.
It is an article on Medium posted a while back by Irene Au. Actually it is the transcript from her IXDA keynote address. And it touches upon (obviously) mindfulness and design. Also amongst other things, the article makes a connect between empathy and design.
It’s a significant association.
While empathy is an important skill for design practitioners, not many are necessarily good at it. Especially if you are building designs for a user, who is very different from you.
Sure, great designers excel at putting themselves into diverse users’ shoes; but not everyone can do it. If you find yourself in a similar situation, there is some heartening news. You can get better at generating empathy if you make the right efforts.
You can follow some of the nice suggestions that Irene has in her article. Or if you are really adventurous, you can even use virtual reality to improve your empathy.
Thankfully you don’t need to resort to elaborate methods. Let’s explore some of the tools available.
Tools to develop empathy
Developing team goals: This is one of the simplest ways to instil empathy. Not just individual empathy but also for the entire team. Prioritising individual goals over team goals (usually unstated) is one of the main reasons for egos to build up. While this can be detrimental for the team to make progress, it also destroys the empathetic environment that is essential for success. Also when it comes to setting these goals, it is better to have a user focussed goal. Take Google’s philosophy for example. The very first point on it is ‘Focus on the user…’ and this sets the tone for all development work at Google. Even a statement like ‘Fast is better than slow’ is a result of its focus on users. So getting the team philosophy right is important for the team to generate empathy. And also importantly, for empathy to be tolerated within the culture.
However, just setting a good team goal is not enough. People will always have individual goals at the back of their minds. So there should be a process to rejoice over team goals that have been achieved. And also, reward people who put team goals ahead of individual goals.
This environment nurtures empathy.
Contextual enquiry: Contextual Inquiry is an ethnographic research method in which the researcher watches the user do their normal activities and discusses what they see with the user. It provides insights to user behavior that would be difficult to capture in the usual quantitative research methods. A contextual inquiry interview is usually structured as hour long or longer, one-on-one interaction in which the researcher delves deep into current user behavior and infers unmet needs that could be addressed in the design.. I’ve elaborated on this method earlier in this post.
Diary studies: A diary study is a long term longitudinal user study where the users either provide feedback on events or usage of the product in a contextual usage scenario and close to the time that the actual event happens. This gives a more accurate feel of what the user is going through at the time for you to develop empathy for the user and design products that meet the requirements more accurately.
While these are tools that are generally used in the field, I was inspired by irene’s article to add a couple more. These are not your traditional design research methods, but have been borrowed rather heavily from Buddhism. There are two such methods, let’s explore them below.
Developing loving-compassion: The Pali term for this practice is ‘Metta Bhavana’. It is an effective method to remove indifference and animosity towards other people. This is primarily a visualization. It starts with visualizing a representative user. Can be a user you are aware of or your defined persona. Imagine that you have a strong connection with this user and wish the user the very best. The second step is directional pervasion where you imaging users in all four directions and have the same intention for them. The third step is universal or non specific pervasion. Where your imaging all users who come in contact with the product to benefit from it. Finally is the development of the intention to benefit the user. This practice will form a connection with the user that is more intimate than the one you have now and will help you relate with them more.
Finally the last method is based on the mind training of the seven point cause and effect.
Mind Training: Mind training practices are an important set of practices in Buddhism. In Tibetan, they are called Lojong and involve a set of visualizations and slogans that help familiarize your mind with compassion. There are seven aspects to it but the preliminary step is is generate a feeling of equanimity. Even if your product is aimed at a specific type of user, say a large enterprise user, it would be a good thing to develop a feeling of equality for say a small business user. You can look at some basic needs that both these users have and see the similarity. For example, all of them want to develop a profit. Some for shareholders and the others for their small business. But the end goal they both have is the same. This is followed by a seven step visualization that is explained below. One of the pre-requisites for this process is to have a well defined persona.
1. All potential users are your best friends. Tomorrow your product might be potentially used by anybody. Especially when you are developing a product like Google or Facebook, you can’t afford to alienate users. The first step is to imagine all these potential users as being very close to you. Like say, your best friend.
2. Remember the times that a friend has helped you. When was the last time your friend helped you? By lending you something? Or by just being there to to listen to you? Think of all the big and small ways that then have been of help.
3. Repay your friend’s kindness. Don’t you want to help your friend back. Think of having that intention. How you would like to do that is not so important. Just have the motivation to help.
4. Make sure they have the best of the features. This is the feeling of affection, where you want your friend to have the best of the features your product has to offer.
5. Ensure they do not encounter any pitfalls. The next is to have a feeling of kindness. The one that wishes no harm befalls your friend.
6. Develop an altruistic motivation to make a beneficial interface. Once you have this feeling, now you should have benevolent attitude with which you work on your idea.
7. Redirect this feeling towards your persona and start work. Now redirect this benevolent attitude to your persona and work on the designs.
Hopefully tools can help you work with more empathy and lead to a more empathetic design process for you.
I recently came across this article by Wouter de Bres about quantifying user experience. I remember using (about 15 years ago) a not too different approach using Fitt’s Law and Hick’s Law in addition to some of the parameters mentioned, to gain a quantitative understanding of how good an interface could be. It’s a very nice article and here are some of the salient points:
- User experience can be quantified at least in theory.
- The following are the factors that affect user experience:
- Loading speed (digital and cognitive)
- Interaction complexity
- Using the above parameters a formula can be derived [ux=(p*i)/v] which can be used to quantify your design.
While it is great to have a quantitative approach, one of the dangers of doing so, is the fact there is a lot of variation in some of the more qualitative inputs used in the formula. For example, purpose (p) in the formula devised by de Bres does not have an international standard. It also depends upon the the person doing the evaluation and the state of mind s/he is in. So the evaluation is highly dependent on the evaluator.
However, make no mistake, this technique has great potential in comparing interfaces quantitatively, especially when it is carried out by the same person. However, in terms of simplicity and effectiveness a well executed A/B test would edge out the effort and results that such a formula could ever give as far as comparisons are concerned. So it becomes tiring and progressively less effective to keep using such a technique in the long term. I know because I hardly use my formula after such a long time.
There is however a great benefit if this formula can be tweaked for a non-comparative evaluation.
If, for example, you feed the results of some well worded questionnaires into the formula. Questionnaires that can be used at the end of user testing by participants who have just used the interface. Imagine users providing fresh feedback on questions like, ‘Does the interface help you get a resolution for x?’ where x is an unmet need that the user has expressed earlier. Something that the interface hopes to fix. These set of questions might be able to provide a more quantitative answer to some of the more qualitative aspects of the formula. Like purpose, for example. It will also remove evaluator bias by having more people be involved in the formula and thus make the results more statistically significant. Some of the more measurable values like speed of download can actually be computed automatically. This might make the formula more usable, especially since it is fed into a more accepted phase of design; user testing.
There are three dimensions along which user research can be categorized:
- Attitudinal vs. Behavioral
- Quantitative vs. Qualitative
- Contextual vs. Scripted
Let’s look at these dimensions individually.
What people say: Attitudinal Research is usually to understand, measure, or inform change of people’s stated beliefs, which is why attitudinal research is used heavily in marketing departments.
Some examples of Attitudinal Research are:
- Focus Groups
- Card Sorting
What people do: Behavioral Research seeks to comprehend and gauge how people act.
Some examples of Behavioral Research are:
- Usability Testing
- A/B Testing
- Eye tracking
Usability field studies have elements of both Attritional and Behavioral Research methodologies.
The next dimension to look at research is whether the research is Quantitative or Qualitative.
Quantitative Research: These are inferences drawn from indirect interaction with users. It usually results in numbers based on tools like surveys or data logs to predict a model for user behavior. These can help identify where issues are but not necessary how to fix them. It’s simply what people do with your product.
- Data log analysis
Qualitative Research: These are direct observations of how users behave either with new or existing products that provide insights on usage. It’s another way of say why people do things they do. This helps you solve those issues if they are bad. Or provide more opportunities to do them if it is good.
- Contextual Inquiries
- Focus Groups
- Eye Tracking
- Diary Studies
The third dimension is to look at the contextual as opposed to scripted usage.
When the study focuses on natural usage of the product within the user’s environment, it is a contextual study. The study can even focus on user not actively using the product. These are typically ethnographic studies that provide insights into the cultural and environmental factors that are involved in the usage of the product.
When a study focuses on the usage of the product where the user is measured against the ability to perform against a set product usage outline, it is called a scripted study. The purpose of the study is validate user flows and proposed solutions so that changes can be made accordingly.
Each of these research methods are suitable at various stages of product development. Here is a tabular representation of which methodology to use when:
Here’s is a presentation on the topic I will be making this weekend:
I’m doing a half day workshop at UXIndia and this is what I intend to present:
It is based on a technique I picked up at Google and found it to be quite useful. It’s something that is also used at IDEO and Facebook to name a few. Maybe you will find it useful as well…
What is Contextual Inquiry?
Contextual Inquiry is an ethnographic research method in which the researcher watches the user do their normal activities and discusses what they see with the user. It provides insights to user behavior that would be difficult to capture in the usual quantitative research methods. A contextual inquiry interview is usually structured as hour long or longer, one-on-one interaction in which the researcher delves deep into current user behavior and infers unmet needs that could be addressed in the design.
How does one get started?
Does your product need a contextual user research? Do some internal product soul searching. See you you need to insights you will have as a result of doing contextual inquiry. For example, are you in the early stage of development or feel you don’t know your end users well enough. Do you feel the need to kick-start a slew of directed innovation? Do you need to validate designs or Personas? Well, in most of these cases a Contextual Inquiry will help you. However, never put off contextual Inquiry if you feel you don’t have enough time for it. The process will end up saving you a lot of time in the end by minimizing unwanted development.
Are there some useful methods for recruiting?
In this talk Michael Margolis talks about conducting guerilla user research and using tools like spreadsheet questionnaires to do recruiting. You should be using some of these methods.
What are the rules of efficient Contextual Inquiry?
1. Of course as the name suggests, the context: Test how the fish behaves in its own pond. It’s important that the researcher watches users do their own work tasks and discusses any artifacts they generate or use with them. In addition, the researcher gathers detailed re-tellings of specific past events when they are relevant to the project focus.
2. Collaborate with the user: Alternate between observing the user and finding out what was the intent the user carried out a specific task. Finding this reason might lead you to an important behavior that explains the user’s mental model.
3. Share interpretations: Do on the spot interpretation and validate them with your user. What if your interpretation is wrong. Don’t wait to come back to the drawing board and loose the opportunity to validate your interpretations. To give an example, in one of the interviews I had conducted, on mobile usage within the illiterate population, the user said that her contact list kept deleting itself. On exploring this further, we found that the user was using the call log as a contact list, and since numbers usually go off the call log, she assumed that the contacts in the list had a limited lifetime. An useful interpretation of this was to have an auto generated contact list which we shared and validated with her.
4. Remove distractions: It is easy for the users to believe that you are having a casual conversation and give into distraction. Remember this is work, and help guide your users back to focus on the task at hand. But at the same time, do not be curt about doing this, as you may loose your trust with the user.
How does one conduct the interview?
An interview typically has three phases:
1. Breaking the ice: Introduce yourself and share the focus of the interview, especially if the tasks the user performs includes others that are not the focus of your interview. Use the warmup session to gain the trust of the user. If you have a genuine sense of empathy towards what the user does, this is very easy. People like it when they are the center of attention and will go out of their way to be helpful. However be careful when this happens as it could create a bias in your interview and skew your design decisions.
2. The actual interview: Take notes of everything. Even small stuff it might be an useful insight that you don’t realize at the moment. Do not lead the user. When they ask for a validation, turn it back on the user and ask them what they think. There are no right or wrong answers, the interview is supposed to put you into the users shoes. What you need to come back with is the complete experience, not a completed checklist. In fact to achieve this, you need to be flexible in your approach. Also be wary of your body language. If your mind has any inhibitions, they will surface in your interactions. Don’t let these create a bias in your interview. To do this, you have to work on your inhibitions.
3. The wrap up: Summarize your findings. Be open and thankful for the opportunity as it is not often that users open up to the team building the product for them. If you are genuine in your desire to help, the users will figure it out. Also see if you can compensate the user for the time and valuable feedback. It need not be money. In fact it is better if it not money. Just something symbolic is what you need.
How to interpret the data?
Do not take data from the interview at face value, always see what is behind a response. Use the data you generate from the research to create personas and HMW brainstorming sessions. More on that process later.