Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Off To The Races: Getting Started With Design Sprints

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.

Further Reading on SmashingMag: Link

Limitations Of Current Design Approaches Link

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:

  1. 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.
  2. 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 
Limitations of current design approaches4
Limitations of current design approaches (See larger version5)

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 Link

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.

Two-week design sprint example6
Two-week design sprint example (See larger version7)

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 Link

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.
Business Model Canvas8
Business Model Canvas (See larger version9)

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.

Javelin Board10
Javelin Board (See larger version11)
  • 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 map12
Empathy map (See larger version13)

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 App14.

  • 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.

Ideation with crazy 8s15
Ideation with crazy 8s (See larger version16)

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.

Dot voting17
Dot voting (See larger version18)
  • 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:

Google Venture's design sprint19
Google Venture’s design sprint (See larger version20)

Jake Knapp wrote an excellent post on Google Ventures’ design sprint process21 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 Link

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

  1. Momentum.
    You can quickly move from one problem to the next in these sprints. You will see 
the momentum building.
  2. Minimized waste.
    Reducing documentation and increasing collaboration, this process minimizes the activities that do not directly contribute to product development.
  3. 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.
  4. 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 Link

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 Link

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.

Getting started with a trial week22
Getting started with a trial week (See larger version23)

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.

(ah, il, og)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29

↑ Back to top Tweet itShare on Facebook

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.

  1. 1

    Dieter Mueller

    August 20, 2014 3:32 pm

    … and another great Example how Methods of Software Production ruin Design.

    Let us rewind – shall we?

    All this rubbish comes from Taylorism – which is so charmingly called “Scientific Management”.

    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.


    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”.

    Design isn’t clean, Design isn’t a Funnel for simple digital Sausage Making.

    The sooner we discuss Design Problems and their contextual detailed Devils instead of these broad Brush Strokes of Corporate Wankery the better …

    • 2

      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.

      • 3

        Dieter Mueller

        August 25, 2014 5:52 pm

        Dear Chris!

        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.

        But I am sure I will be awesome some Day – just like you!

        • 4

          “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.

  2. 5

    Jake Truemper

    August 20, 2014 5:11 pm

    Great article. I’ve been gaining traction building this type of workflow within my company (and our clients), and this provides a lot of really solid examples that will put some minds at ease.

  3. 6

    Marcelo Paiva

    August 21, 2014 3:23 am

    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.


  4. 7

    A couple of questions…

    Where do you find all these users? Do you have a large enough user base to just walk outside and ask people? (Are you designing “air” or “breathing”?)

    You mention.. “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.


    Are you not doing design sprints every week? How long do you have to equip yourself with “knowledge that will be gained between now and the next sprint”?

    Good tactics and processes at a high level, but your description of “your process” seems a bit oversimplified and naive…

  5. 8

    Shawn Chittle

    August 21, 2014 4:00 pm

    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.

    Thanks again!

    • 9

      Thanks Shawn, I find more and more people who have tried such an approach found it valueable.

  6. 10

    Torben Andersen

    August 22, 2014 9:39 am

    Very thoroughly and process oriented, but sorry – I don’t believe in the term “wasted effort”. An effort is always good, and wasted efforts makes us sharper.

    • 11

      Torben, I agree .. it’s about how we value the two kinds of effort , but both ways are valueable.

  7. 12

    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.

    • 13


      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 –
      b) Changes on the marketplace – new product, new feature from competition etc
      c) New Ideas

      A few years back I designed – 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…

      • 14

        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.

  8. 15

    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?


    • 16


      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 – and we can setup a call to discuss.

  9. 17

    Great and a very informative blog. Keep sharing.

  10. 18

    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.

  11. 19

    Hi, Alok Jain

    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 , 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!

    Greets From China

  12. 20

    Florence Bell

    January 30, 2015 6:41 am

    Great and a very useful article Alok. I love to read it. Keep sharing.


↑ Back to top