Many modern software development best practices draw on influences from the industrial era and concepts like specialization, where individuals with specialized skills worked in an assembly line to mass-produce physical products. These practices from the world of manufacturing have come to influence how things are done when designing and building software products as well.

Lean thinking is one of the latest approaches software development companies have adopted to maximize value and reduce wasted effort and resources. It does so by breaking down an objective into a series of experiments. Each experiment starts with a hypothesis that is tested and validated. The output of each experiment informs the future direction. This is similar to the idea of “sprints” in the agile world, where the overall product roadmap is divided into smaller and meaningful bodies of work.

Designers are by no means immune to these shifts toward a more iterative style of creation. Nowadays, rather than design being something that’s done once at the beginning of an engagement and then never touched again, a product’s design must be flexible and adjust to changing conditions. Approaches like design thinking tend to be lean by nature. There is a huge opportunity, however, to take this notion even further and align design to the new ways digital products are being built and improved on. Let’s look first at the current approach towards design and how it has an impact on the product.

Limitations Of Current Design Approaches

Traditionally, the design process has focused on figuring out the upfront effort to define the big picture and the core design language. This core design language then informs and guides the detailed design for various modules or features. There are two downsides to this:

Initial Investment and Timeline
Product development is dependent on the initial design direction in traditional software development, which means development has to wait for the initial design work to be completed before it can start.

Predicting Future Needs
It’s more difficult to change a product once the initial design direction has been set. Making amendments based on market changes, customer feedback, and other new information becomes costlier.

Business leaders and product managers may become reluctant to invest in additional design activities in this scenario. They may trade effort that should be spent on research and testing for more development work in order to accelerate time to market. This can have a negative impact on the quality of the product. Further, the risk-taking ability of the team declines significantly. Once the design is presented it is considered to be final, and it cannot be changed easily, so the team gravitates toward proven models instead of being able to explore innovative new ideas.

Design Sprints Can Help

The issues mentioned above can be resolved if the process can be modified such that the design direction evolves over a period of time instead of being fully defined up front. Such a process will allow product teams to start developing sooner and allows the design direction to be adjusted based on new learning and ideas.

This is very similar to the way agile software engineering uses sprints to divide the overall product vision into smaller sets of goals. Design, too, can have sprints.

So, what is a design sprint? Very simply these are one to three-week sprints, focused on solving specific design problems.

You will notice that the process is not very different from the regular design process, but it is condensed in a way that it could be done from start to finish in about two weeks.

Team Setup

This process works well when there are multiple team members focusing on a given design problem. Having multiple people benefits in two ways. One, it allows for doing things in parallel. Second, the collaboration leads to more ideas and quick evaluations of those ideas. Let’s look at each of the steps in more detail below.

Preparation
During the preparation step the team establishes a common understanding of the problem statement as well as the related data and assumptions. Just like software engineering, design sprints are also based on product priorities and a product roadmap so that they remain aligned to overall business goals. You can use tools like the Business Model Canvas or its modified version – the Lean Canvas – to get to a good understanding of a business very quickly.
5Business Model Canvas (See larger version6)

Another interesting tool I found recently is Javelin Experiment Board. With this approach, the team brainstorms who the customers are (left side) and then prioritizes (the right side). Similarly, they work on identifying the problems and the riskiest assumptions that need to be tested. All these together lead to the definition of experiments that the team needs to run. The process allows the team to quickly narrow down the goals into very actionable items.

Kick-off and Research
The kick-off and research step is where having a larger team becomes really useful. Each member of the team can have a thirty-minute talk with three people. With four people doing this in parallel, the team can complete twelve interviews in ninety minutes. Counting some extra time between the interviews and the fact that it’s quite unlikely that all interviews will happen in parallel, I schedule half a day for this activity.

By doing only three interviews or observations per person and keeping each as just thirty minutes, it reduces the need for remembering or documenting. In my experience the thirty-minute interview is long enough that I can find patterns across multiple interviews. Longer conversations can bring more insight, but remember you can do that in future sprints, equipped with even more knowledge that will be gained between now and the next sprint.

The research sessions make use of tools like empathy maps to capture the insights. Empathy maps provide a simple but very effective structure to capture research findings. The researchers record what the users said and did, and from that they try to figure out what the users were thinking and feeling. These are the “Say,” “Do,” Think,” and “Feel” sections below. From these the team extracts key insights and further details the problem statement.

Empathy maps are just one example. The specific research technique to apply depends on the goal and the problem. A great place to start for techniques is the IDEO Method Cards App11.

Analysis
Soon after the research step, get the team together for an analysis of what they found. The longer the time in between, the greater the chance of forgetting some information and the more you’ll have to rely on documentation. During this analysis section, each person presents his or her research findings. The team discussionn helps achieve a common understanding of the research findings and priorities of the problem statements.

Ideation
So now we have a prioritized list of problem statements, and a better understanding of the users, the team can focus on generating solution ideas. At the same time, ideation cannot be a one-time activity, so over the next three days keep a loop of ideation and some detail design. Overall, within the three days the team should be able to come up with clear design direction. This could be rough sketches or high-level wireframes.

You can use techniques like Crazy 8s to quickly come up with a lot of ideas. The technique requires each team member to sketch eight ideas in five minutes. Only use thick markers, to avoid focusing on too many details. This is a simple and fun exercise.

You can then use dot-voting to quickly identify the good ideas that the team sees most value in. Dot-voting is a simple process where each team member is given a certain number of votes (represented by paper dots), and they go through and vote on the design ideas. They may put all their dots on one idea or spread them out as they desire. After this, the team looks at the most popular ideas and works its way down to least popular ideas to identify key trends that seem promising.

Prototyping
The next three days in the sprint are dedicated to detailing out the design to a level that can help validate the design direction. Think of prototypes as a visual way to ask questions. Think of the questions you want to ask, and optimize the prototype for those questions. This means some areas of prototypes would be more detailed than the other, and that’s OK as you want to spend time on more value-added activities.

Validation
The last step is validation. Just the way we did research with multiple people in parallel, multiple team members can also do the testing with several users. This allows for testing to be completed in as little as one day.

Notice a few things that should be present in any design sprint:

Collaboration
The idea is to bring creative energy and diversity together to focus on the problems. Activities like filling a Business Model Canvas, or Crazy 8s ideation with dot-voting allows the team to actively collaborate and work towards a single direction. This leads to new and innovative solutions that are relevant to the problem at hand.

Reduced Handover Friction
Through more collaboration, we reduce the requirement for documentation. For example, the team does small thirty-minute interviews during the research step and then comes together and discusses soon after, instead of going off and documenting the research in a black box.

Focus
The team moves from one activity to the next within the same problem statement, each time moving closer to the solution. With little time lag between, it keeps everyone tightly focused on solving the right problems.

This is just one of the ways to apply it. Outfits like Google Ventures also use this concept successfully for their portfolio companies. They do a one-week sprint, but it excludes all research and initial information gathering. Their process looks like the following:

Jake Knapp wrote an excellent post on Google Ventures’ design sprint process18 for anyone interested in reading more about the approach they have tailored specifically for startups.

Another real-world example of design sprints in action comes to us from the Nordstorm Innovation Lab. A few years ago they did an experiment where they went into a Nordstrom’s and set up a complete design and development operation right there. They took a product idea/problem area to solve and ran through the entire process in the store, rapidly prototyping and validating an iPad application over the course of the week. See the video embedded below for more.

As you can see, the core idea remains the same, but there is flexibility to change it as needed. Each sprint may include all or only some parts of the design process – research, ideation, and prototype to validation.

It’s initially a difficult concept to enact but it’s a powerful one when implemented correctly. And the difficulty is less in applying it but more in internalizing and adopting that mindset.

Design Sprint Benefits

So what are some key benefits, or the value of designing via design sprints?

Momentum.You can quickly move from one problem to the next in these sprints. You will see the momentum building.

Minimized waste.Reducing documentation and increasing collaboration, this process minimizes the activities that do not directly contribute to product development.

Enhances design thinking.By working on smaller problems, one is able to explore many different ideas and apply design thinking in a more thorough manner.

Encourages innovation.Design sprints allow for exploration and risk-taking not otherwise seen in the product development space.

It’s important to note that the structure of the design sprint does not have to remain the same throughout the product life cycle. As the product design moves along, the structure should be modified to align with the changing needs. For example, the need for generative research may go down after a large enough body of knowledge has been created. Usability testing also may not be relevant for some sprints, if the design is based on previously validated ideas. The goal of design sprints is not to build a rigid design structure, but to define an approach that allows the entire design process to be more adaptable.

Bringing It All Together

You might be wondering about the overall design direction. Won’t focusing on a few small problems at a time lead to an inconsistent design? This is where what we call the product mindset becomes very critical. The product mindset requires you to take a long-term perspective of the overall product life cycle and the business value. In the short term, small inconsistencies and inefficiencies in design can and will likely crop up, but in the long run they would be ironed out.

This is something to keep an eye on as sprints are being planned and the design progresses. Software engineering sprints have a concept of code refactoring, where the engineers, after every few sprints, revisit the code and refactor it to improve the quality of the code, reduce duplication, increase encapsulation, etc. Similarly, a design refactoring exercise should be undertaken on a regular basis. It is important that everybody on the team, especially the product owner, understands this and that this is included in the product planning. During refactoring, the inconsistencies are reduced and the design direction is realigned.

How To Get Started

If you have never explored applying lean or agile practices to design, the core challenge is in adopting a different mindset. Instead of focusing on finding a perfect solution up front that would just scale to any future requirement, take a longer-term perspective that the perfect design will evolve over a period of time, with regular learning and iterations. The mindset will strengthen as you apply these concepts and see the value. To start with, just take this is an experiment that you are running to test the idea.

Identify a project where you think design sprints may be able to help. This could be a project where:

Complexity is very high

There are a lot of unknown requirements

Time is limited and you need to show results fast

Talk to your team about the idea of design sprints and the value it can potentially deliver. It is important that the entire team supports the initiative. Establish the team’s role in the process, especially emphasizing greater collaboration and reduced documentation.

The next step is to define the scope and goal for your first design sprint. To do this, look at the product backlog or equivalent of that in your organization, and work with the product manager or business stakeholders to identify the highest priority goals. Identify something that you feel can be addressed within one week. The reason for keeping it to one week is to keep the effort short enough that you can run the experiment without a lot of investment.

With the priority identified, set up a working session with your team. Start by explaining the new process, then talk about the identified priorities and the rationale behind selecting them. Set up the plan for the remaining week.

If this works, then repeat it. If something doesn’t work, then tweak it to your requirements and then try again.

These concepts are new, and change can be difficult. But as product designers, our role is to build value for our products and the people using those products. The tool we use is design. As the development landscape changes, we also need to adapt our methodologies to more closely align to the changing landscape and to continually deliver that value effectively.

Alok Jain leads the User Experience and Design practice at 3Pillar Global, focussing on building innovative products that deliver business results. Prior to 3Pillar he has helped many startups take ideas from just a few bulleted points to a launch and growth stage as well as with Fortune 500 companies designing large content management solutions, eCommerce applications, business applications, collaborations tools and more.

Prior to 3Pillar, Alok led the Design and Product management at Insight Methods, Worked with Federal Communications Commission (FCC) to redesign their entire auction system that generates several billions of dollars in revenue to the US Government, designed a bus route management system for Disney and established one of India's largest User Experience competencies with over 120 members. He is also an entrepreneur and has founded 2 software product companies.

He is passionate about Design and Innovation. Outside of his work, you'll find him exploring new technologies like Ardiuno, 3D Printing, Wearables and more. More about him on LinkedIn.

It obviously comes from the Age of Industry, when it made sense to measure, categorize and optimize many MECHANICAL Production Steps.

Software Production has a few such repeatable Steps that can be standardized, but following all the Crap about Lean / Agile / Awesome / Idiotic Methods it fails to understand the big Difference between “doing” Software and “doing” Design.

—————–

1. Management loves standardized Processes:

Something that doesn’t work well in the World of creative Ideas. I am not so naive to say commercial Design can not be pushed along a Schedule or certain formalized Elements, but Ideas are not like a Pregnancy that can be “supported” along a fixed Time Line.

—————–

2. The non-linear Nature of Design:

The Process Diagram (Yuck!) forgets all the Design Process simply NOT a linear Process, because it contain non-linear intuitive Processes as well as logical linear Processes.

Let me explain:

The Main Difference between UX and normal Designers is that UX Designer must be capable to “translate” non-linear and non-functional Requirements of Design (and sadly the Marketing Hounds) into clear “Instructions” that can be followed by Code Monkeys (Devs) as well as Pixel Pushers (Designers).

While many functional Requirements are easy to do – the non-functional ones are very hard to do. It is easy to say “User needs to enter his/her Address here”, while the usual Buzzword Crapola of “Joy of Use”, “intuitive”, “awesome” and “Simplicity” are actually Marketing Bullshit sadly many People don’t understand, but still want to be “pressed” into their Products.

So to define “Simplicity” we have to do Stake Holder Interviews and break them into a “linear” Language / Design Document and fling it back to them so we are all “on the same Page”.

This is as much a “political” Process as it is a design and Technological one.

So your process Chart utterly ignores intuitive Exploration as well as the Maturation of Company Consensus and “assisted Thinking” Processes to arrive and support mutual Conclusions.

—————–

3. Design is not about just Design:

I am not surprised that all that idolized Talk here comes from someone who does a public Rain Dance for a Design Company.

The real Challenge of all commercial Design is the Conflict between Business Cases and sensible Use Cases – or usual better expressed as the old Clash between Marketing/ Management vs (UX-)Designers.

Business Cases are often counter-intuitive to good Design Solutions, because you have to make gap the Paradox between funnelling the User into doing something he doesn’t want to do in contrast to what the best Solution of the Task (Use Case).

From Apple to Google or any “great” Company they all have always clearly put the Business Cases ahead of the User’s Interests.

So a good Design Process has to clearly work out the Directions and Directive of the commercial Requirements – and also define the accepted Inconsistencies and Conflicts (and their Solution by good Service Design) that arise from this.

Your Articles and childish Charts live in the typical Wet Dream of a “clean” and “awesome” Design Universe – where Design will reign supreme and convince Management to follow their Lead …

Yeah right.

—————–

4. Complexity is not a sliced Sausage

This Design Approach of hacking the Product and Problems into many little solvable Parts might work for producing Code, but is unsuitable for good Design.

The whole Thing always will be greater than the Sum of the Parts.

Always.

Good Design & UX-Designers must have the emotional, intellectual and technical Ability to confront the Beast / Challenge in all it’s Complexity – and not just pad itself on the Back when it has picked one Bones clean, while the Connections and Relationship of all the rest of the Moving Parts are not considered.

In many more complex Products we see again and again how different Teams / Sprints create a Frankenstein Monster of scavenged Parts. Sure these Mad Scientists understood what the Parts where supposed to do, but they simply don’t fit together, nor are they as small as they could be because each Parts was designed in it’s own “Design Sprint” and then bolted into the already “solved” Problems.

—————–

5. The wishful Thinking of keeping it simple and clean

Your Process too often speaks of keeping Things minimal and simple. In the Context of User Research there is the Rubbish of just recording what People “Thought” and “Liked” etc.

Not to speak of keeping Documentation at a Minimum.

Oh my …

The Devil of Design is always in the Details.

You need to crawls into all the Details, explore and understand why you choosing a certain Direction – but most of all – why you are NOT following a certain Direction.

This brutal Selection Process should be documented as detailed as possible, because you need it for later Discussions, but also saving your Ass in later Conflicts when let’s say stupid Decisions – and there are always stupid Decisions from Design and Management – hit the Fan.

This is simply a Reality of commercial Design and should be an integral Part of such a Chart: CYA (Cover Your Ass).

But more important for the Design Process itself is to understand and document the Inconsistencies and why they exist.

Despite all the euphoric Wishful Thinking in the Design Community and of Designers most Products are riddled with Inconsistencies.

Why? Because apart from a very few and very simple Products nothing is a 100% consistent. So Design is about the concious Process to find the right Balance all the Needs and Limits from all Sides and decide which Design Solution is best. This includes accepting and making clear why you chose Inconsistencies.

And in many Cases there is not one perfect Solution for one UX-Pattern / Task or whatever – but only several mediocre ones.

So it’s a utter Delusion that Design will only lead to minor Inconsistencies and that they will be ironed out over Time.

—————–

There are many more Holes in this Article – including such patronizing Ideas as Crazy 8s, which are worthy of Design Kindergarten (which is probably great to keep Millennial Designers happy and engaged – have you also tried handing out non-fat, sugar-free & organic Chocolate Bars?).

Design Agencies and too many (Startup Consultants) are getting too much Attention and are making too much Money from selling such “Design Solutions”.

Chris

It’s difficult to answer to this childish rant, but I’ll try to correct your two main misunderstandings.

1. Sprints are for day-to-day work. Everyone is splitting his work into smaller pieces – even a UX designer. Sprints are just one way to make the split. There is always someone who has to create the big picture – and this person isn’t part of the sprint team! (See step 1 preparation. Someone has to state a problem.)

2. Sprints seem to be linear, but development / designing isn’t. One reason for the Agile Manifesto in software development was, that developing software in linear fashion from start to end often produced exactly what was planned but not what was needed. So they introduced a mechanism to get feedback as soon as possible. Now we try something, test it, and if it’s crap, we’ll throw it away and try again (that’s far away from linear).

Your comment looks like you walk at the beach, then suddenly you’ve got the big idea, which will change the whole world, and you create perfect instructions for the code monkeys, which only have to hit the keyboard often enough. I can’t believe that.

Dieter Mueller

Thanks for the remote Diagnosis of my Thinking. I am sure you are awesome and you totally disproved my Points.

1. Design is always “Day to Day” Work – it doesn’t matter if you work on a small or large Scale Problem.

And your awesome Idea to have someone outside the Scrum Team having the Overview and the Team itself on focusing on a Detail is exactly the mental Disconnect I was talking about.

But I am sure you realized that in your Awesomeness, right?!

2. I shed Tears for you mentioning the Agile Manifesto and Feedback – I am sure that makes all the Difference?!

You make it sound like Feedback was invented with the Agile Manifesto – Managers, Designer and Code Monkey in the Dark about this Agile Magic that made all the Difference.

Feedback and Iterations have always been a Part of good Design – but just to formalize it as a Method doesn’t mean it it makes it any better.

Competence and good Feedback come from competent and engaging People – not Methods. Just because you doing in an agile and scoialized doesn’t mean the QUALITY of the Feedback is any good or that People really engage.

You can sing “Kumbaya my Lord”, but it doesn’t mean the Baby Jesus will fulfill your wishful Thinking – the same applies to Methods and Teams …

The Article pointed out a Method I personally find lacking many Aspects I have encountered in my +25 Years of being a Freelancer in many Projects.

Chris

“someone outside the Scrum Team having the Overview and the Team itself on focusing on a Detail is exactly the mental Disconnect I was talking about.”
I never said that. I said there is “someone who has to create the big picture”. They all need an overview.

“You make it sound like Feedback was invented with the Agile Manifesto”
I never said that. I said “get feedback as soon as possible”, you’ll get faster feedback than in a waterfall model.

“doesn’t mean the QUALITY of the Feedback is any good or that People really engage”
I never said that. It’s just one way to do it.

You definitely have a problem at listening to others, you’re contradicting statements which weren’t made at all and you’re hiding that behind your funny sound bites (“You can sing “Kumbaya my Lord””).

“But I am sure I will be awesome some Day – just like you!”
I surely cannot keep up with you at any design problem, but your social skills are lacking.

Marcelo Paiva

Alok, thanks for the article. Great job consolidating some of the tools and techniques. There are a couple of important pieces that should be taken into consideration:

1) In a real enterprise-level setting, the team should be comprised of lead representatives for development/QA, business analysts and product sponsors; the least, you should have a developer as part of your design sprints.

2) Have a UX producer or project manager trained as scrum-master to lead the way and keep things on track – daily.

3) Aim to start building a UI Pattern Library and a living styleguide from day-1 – these will help accelerate design/development further as time goes on.

Thanks Marcelo, I agree on all 3. Collaboration with a cross functional team is critical to product success. Living style guide is something we want to experiment with , but have not played as much with that yet.

For the users we work to building a list of individuals who we could approach. In the very initial stages this takes time. In an enterprise setting this is easier, the hard part many times is convincing business to gain access.

In a consumer product, you can work with a recruiting agency, or recruit over places like craigslist (IDEO has had success with this approach), do intercept studies – for example for one of our products, we were targeting people focussed on fitness, so we designed the study where we approached a local shop where such customers are likely to shop, and then talked to the owner to allow us to conduct the study and in return we would give gift cards from that shop to the customers as reward.

Having said that, there are users who are not easy to have access to. When I was working with the World Bank, some of the users were people managing billions of dollars of loans, constantly traveling and didn’t really have time for user interviews. In that case we worked with their assistants, or had to wait for people to be local. This improved over a period of time, and required Sr. Management support to ask for their time.

You also asked “Are you not doing design sprints every week?” … I do 2 week sprints, I have found 1 week to be more constrained than I found necessary. The additional knowledge I refer to is whatever comes up in the 2 week time period.

For one of the products we interview 5 people in half a day (all users were in same location and we could move from desk to desk), and we could see patterns that pointed towards certain kind of usage and mental model, that was different that what we heard from business. It also impacted the fundamental navigation of the application, so we had to pivot and focus on the core navigation. The interviews provided us great clarity on some aspects, which we started building upon.

For another product we were redesigning an existing product, and the users kept referring back to existing way of doing things. Our hypothesis was that it’s so because that’s what they had being doing for last x number of years. We kept exploring new ideas and pushed some new models out. It took us 4 iterations to narrow down and grasp the mental model, and then we refactored the design. The individual components that we had previous created were still okay, but the navigation and visual association between the component was misaligned, so in the next sprint fixed those two aspects.

Shawn Chittle

Fantastic article Alok. The amount of care and consideration that went into this was staggering. A lot of people out there in the UX / Visual design world are always looking for some kind of process to help when in fact a lot of places don’t even have a process. This is a lighthouse for them.

Me personally? I love design sprints. Have been doing them for ages. We do “dual track” agile where designers are a sprint ahead. They talk with engineers of course during their design sprint, get the viability down, then iterate and test like crazy. When it comes time to build, sure, we still might make changes, but a lot of the heavy lifting is out of the way. Our engineers love and respect when things have been well thought out, as they get bothered when they have questions that can’t be answered. Everyone can sympathize with that.

Adam Nemeth

First off, the tools you use are great, and does a decent design cycle.

However, I can’t find the reason why desing should be timeboxed. You say:

“product’s design must be flexible and adjust to changing conditions”

I fail to see how changing conditions could affect design lifecycle: most changes I have seen were due to lack of proper qualitative research (finding out late that the product also needs to do X in context Y). If you let people research a bit more and do proper specs, product requirements in my experience don’t change for several months.

“development has to wait for the initial design work to be completed before it can start”

I can’t see the problem with this: start your design a month before you start development and that’s it, really. The two can run in parallel then, just let design lay the groundwork (better than letting development do it) 60-80% of software projects aren’t new developments anyway, which means initial design work was already done, even people don’t like that design.

“They may trade effort that should be spent on research and testing for more development work in order to accelerate time to market”

These are two separate pockets: I usually say I can generate a month’s worth of development work in a single day if needed. Once you accept salary realities, research cost is close to zero, you just have to let your designers do proper research instead of telling them what to draw.

Having said that, as it is custom in my region, I usually work as UX Team of One, which perhaps alters the landscape.

My thoughts on timeboxing is that It sets up the expectation that we talk to customers atleast every weeks, that limits the time that team could potentially have gaps.

Also for me, design is not an output of a solution worked out in the mind, but it helps think through the problem itself. Everytime I start the design, new questions come up as well as new ideas that I would love to validate. The 2 week timeframe allows for absorbing what’s learnt, explore the understanding and the solutions.

“product’s design must be flexible and adjust to changing conditions”

There are three kinds of changes I think of here:
a) New learnings about the customers – There is an interesting video by Etsy on their process – http://mcfunley.com/design-for-continuous-experimentation
b) Changes on the marketplace – new product, new feature from competition etc
c) New Ideas

A few years back I designed Insightify.com – a survey tool. The original vision was to build a tool for market researchers. I interviewed researchers at several prominant market research companies, independent researchers, validated wireframes with them. For about 2 months we did very little development. As we got into development, we realized we were trying to do too much and would have a backlog worth years with what he had in pipeline (and given our budget constraints). So we started prioritizing and focussed on core survey interaction first. In the end we came up with a product that was not for market researchers, but for regular business owners and the product started growing from there.

The research process is very critical. I often give IDEOs example to people, where they insisted on conducting research when they were asked to design children’s toothbrush, and they got great insight the very first day. The sprint process it to include design process early in the process.

“development has to wait for the initial design work to be completed before it can start”

I agree with you that design could start a month before development, and in most cases there are development tasks that are independent of design that do get started, giving the additional time for design to get started. My initial statement refers more to the traditional waterfall kind of process, where end to end design (or close to it) was done before dev starts.

“They may trade effort that should be spent on research and testing for more development work in order to accelerate time to market”

In my experience I have seen many times that business feels that they alredy know the customer needs or the solution being focussed on is the obvious one, so doing research will only delay what they already know to be correct. If the research adds a few weeks to the timeline then that becomes an issue. If your experience is different, that’s great.

I also re-emphasize that we cannot know all questions upfront and be able to research on those. As we do designs, new questions come up and building regular cycles for research > ideation > validation help give flexibility to go back and do deeper and focussed research.

I am also curious to learn, how many people do you conduct the research with ? What kind of methods do you apply ? Could you share more on that…

Adam Nemeth

So, first off, right now I’m doing User Experience Research / Design for FIBA, the International Basketball Federation. My job description reads “Make 3×3 [a regulated version of streetball] an Olympic Sport by 2020″. So perhaps I have a special case here: if I want to do user interviews, I go to a tournament, where I mingle with the crowd and reveal my identity once contact is built.

On an event, the goal is to conduct 20 research sessions with players / spectators, that’s how many presents I have with me usually. Sessions include interviews on topics pre-agreed with FIBA (Portigal’s book is the guideline), moderated card sorting sessions, usability tests of our interactive prototype built using Axure, running on my mobile with 5-6 tasks to answer.

Because of its informality, video documentation is sometimes dropped but I drag along devs sometimes. Videos are recorded about the organizers, as there the setting is more formal (we’re there in the corner on preparation day in their office, recording their screens and asking them to explain what are they doing and why).

All events have qucik daily debrief, which is a bullet-point based list, and within a week after the event, a report presentation is made, full with pictures of little mundane things I have noticed – I usually say the main tool to use is your held-back breath while you’re watching and listening to users. This is shown to developers and product owners.

Besides this, as most people working for FIBA, I maintain regular contact with a few organizers and players, and I am reading all support discussions.

Iterations are based on tournaments: usually I go to an event, do these research sessions, then collect ideas, build/modify prototypes, and either go to another event to test them or use my contacts to make an ad-hoc test session.

Quantitatively this is accompanied with Google Analytics of course, and we’re planning a HotJar/ClickTale integration. We are thinking about sending out surveys to certain groups (eg. players participating in a specific event)

Out of this research, personas, user journeys, user stories are built.

For us, development is really slow. If you want to A/B test something, that has to be developed first, so we think about it twice – once we committed to something, we expect it to more or less work already, so we solve known problems that came up in interviews and measure if things have changed. A/B test helps you in this but A/B tests, especially “current vs proposed” tests will not reduce your development costs, only your failure rate.

Qualitative research also highlighted issues we haven’t thought about for years!

Again, this might be a special case, but in all my career I have found ways to do the qualitative research: sometimes joining support (esp. in banking), sometimes approaching people in pubs (I teach mobile startups to test this way), and there were times when I had to rely on ClickTale or other screen automation tools.

Adam Matthews

Hi Alok – thanks for a great article. I’ve been struggling with the concept of agile/lean UX, largely because in my personal experience so far it fails. I’ve lived my whole career in agency/consultancy companies…which have started to try to take up design sprints since “they make everything better.” The reason I struggle is because agencies & consultancies seem to tend to get large, often complex projects. These don’t really break down too well into (design) sprints that maintain a minimum viable product – which is of course the goal of agile development. Specifically, and to me at the very least, the IA needs to be worked out first. Perhaps then it’s possible to break down smaller sections of sites/portals into sprints, but I have done one project where we dove straight into sprints without the global nav / IA set, and it resulted in a lot of rework of earlier sprints as we discovered our navigation didn’t support all it needed to. Surely editing Sprint 1 during Sprint 4 or 5 makes nobody (including dev) happy.

Your article clearly illustrates to me, for probably the first time, the value of sprints with smaller designs or apps. Do you have a sense of how some of this translates to the sorts of larger, more complex projects I have mostly had experience with (e.g., designing a whole ecomm platform for a cruise line, or a wellness product for a health insurance company)? Is there really such a thing as Lean/Agile UX in this sort of situation? And can you really get away with not documenting research or design decisions when you are, at the end of the day, responsible to your client for what you deliver and how it meets their needs & goals?

Just seeing your comment. I have been applying the ideas behind design sprint for over 3 years for a very large web application. Everything can be broken down into smaller chunks, the challenge will be getting everyone to see that way and agree with that approach.

For example at a very high level, a large ecommerce platform may have an inventory management system, shopping cart, catalogue, profile management, recommendation engine, notification engine. Then you can break each on down – a catalogue will have listing , filtering, searching, details, reviews, ratings etc. These can then further be broken down. Essentially like a mind-map exercise.

Some foundational elements will still be important, for instance first sprint can focus toward a core IA – not necessarily every detail of the IA , but a directional decision on how people would want to browse the catalogue – by demographics, interests etc. The specific entries within those in any case will change over a period of time. I am happy to discuss in more detail for your specific goals. Feel free to reach out to me on Linkedin – https://www.linkedin.com/in/alokj and we can setup a call to discuss.

Florence Bell

Sam Jones

We’ve recently had to endure a version of Design Sprints at work following a huge “let’s be collaborative drive”. It’s been, I think, horribly misapplied where technical solutions are discussed in a roomful of people including architects, developers, sales and business representatives. Everyone has a vote despite not even understanding the solution. It lasts for an hour on average and apparently the decision is final. It is supposed to be high level but drops into database design or other areas of low-level design. Worst of all, I’ve been told we can’t “go back” – and we’re a supposedly an agile company. Generally, I have found the meetings to be personality driven with good salespeople manipulating the room to push people in various directions.

As chief architect, I feel dis-empowered. I considered the analogy of a brain surgery operation where the hospital administrator, the bloke who installed the MRI machine, finance and a neurosurgeon all had to agree on how to operate on a patient. There’s only one person who should make the decision in this context but if we talk about architecture, suddenly everyone can have an opinion.

I can see how User Centred Design can benefit from this but surely technical solutions are meant to be decided by an oligarchy. Granted there are some problems with the way our company has interpreted the design sprint but I think this also includes thinking it is right for technical design.

ZeonWang

I’m A Industrial Design Student From China And I’m Totally Fascinated By Your Awesome Article. Therefore I Want To Ask If I Can Share This Article To http://www.ituring.com.cn/article/131134 , I’ve Already Translated To Chinese And Put The Copyright And Your Link On The Top Of The Article.If You Feel Uncomfortable With That.Please Tell Me via E-Mail.I Would Delete It Immediatly.Thanks!

Florence Bell

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

SmashingConf isn't the eighth wonder of the world, but we are pretty close. Join us at SmashingConf Oxford on March 16–19 or meet us at the shores of Santa Monica for SmashingConf LA on April 27–30. You won't be disappointed.