In the first post of this two-part series, we discussed what design sprints are, how they help execute design thinking, and what benefits you can realize with design sprints.

Now it’s time to get into how to run a design sprint. And what better way to show that than seeing how we here at Mendix run them. 

Recently at Mendix, we ran an abridged design sprint to figure out ways to improve repeating time entries on one of our internal applications that tracked time with our clients.

Timeboxing

Timeboxing is a key component of running a design sprint. Like any meeting, it’s easy for things to get derailed if you don’t stay on top of it. Keeping track of time helps keep everyone focused and on task. We had a set time for each of the exercises we did over the course of the sprint. If you are leading the sprint, have a way to keep track of time and give warnings as time draws near to closing. Sometimes you’ll see people use a timer and place it where everyone can see.

To start us off, we had a member of the team discuss the pain point they wanted to address to give everyone context. After listening to them discuss the issue, we took a few minutes to research relevant examples from other services to see if there are other products tackling similar problems and how they approach the problem. People looked at other time tracking and recording systems to see how they approached this or similar problems.

From there we did Crazy 8s, an activity that lets you quickly ideate solutions for a problem. We folded a sheet of paper into eight spaces. The goal is in eight minutes to sketch different possible solutions, spending a minute on each idea. The idea at this point is to stick to a high-level idea or approach.

Voting

After those eight minutes, everyone pinned up their sketches and introduced their concepts. Each person has three minutes to talk through their ideas and answer any questions. Once everyone presented, we took a few minutes to vote on ideas to delve into further. Rather than an open discussion to vote, everyone had three votes. To vote for an idea, they used a set of three sticker dots. In five minutes, everyone indicates the most compelling ideas by voting on specific sketches, not the entire paper.

They could use those dots any way they wished: on three different ideas, on one of their own, all for one idea, etc. Sometimes louder voices in a group can drown out others, or people are less willing to voice their opinion if there is someone of a higher rank participating. Voting this way helps keep groupthink out of the voting process.

Following voting, we took the most voted ideas and for the next half hour went deeper into those ideas, mapping out what they could be. After, everyone presented their ideas and used dots to vote again to decide which features to focus more on. Once we established key features through voting, we plotted them on a matrix according to their technical complexity versus their value.

Once you map features onto the matrix, remove any low-impact ideas (whether low or high effort). What counts as a low-impact idea? That depends on the team and how they evaluate ideas based on difficulty and value. If you have a lot of ideas, you can vote again to help narrow them down and prioritize better. You can always capture the ideas in a document and incorporate them at a later date.

Storyboarding

Focusing on the top features from our matrix, we storyboarded how those interactions would flow. We sketched on paper the different steps someone would take using the proposed features. Ideally, an interactive prototype would be made from the storyboards, but we chose to test with our sketched storyboards due to our this condensed time frame. With our storyboards ready, we discussed how we wanted to present the storyboards and any questions we wanted to ask when we tested them with people who currently use the time tracking tool.

Testing

No matter the length of your design sprint, two of the most important phases are prototyping and testing. Testing is important to validate your design with the people who would be using it. Because we were running such an abbreviated sprint, we used our storyboards as our testable prototype. Make sure to record people’s feedback, reactions, and thoughts. You can use that information to see if an idea is worth pursuing, how to revise it, and to decide which features to build first.

When you test, have one team member lead the session and another take notes. This is an opportunity to bring in stakeholders or other team members into testing by having them observe and takes notes on reactions. Taking advantage of an all-hands-on-deck company event, we went around during lunch and reviewed our storyboard with people.

Want to learn more about design sprints?

These sources are a great start if you want to learn more design sprints and how they can be used effectively.

• Jake Knapp, Google Ventures (literally wrote the book)

• AJ+Smart (revised the book)

• Fresh Tilled Soil (wrote the other book)

• DesignBetter Enterprise Design Sprints (Fresh Tilled Soil with Invision)

If you discover items that need more research and thought before you can implement a solution, using the structure of a design sprint is a great way to approach it. When you do find an approach over the course of your sprint that you want to test, Mendix makes it easy to create an interactive prototype to test with. Design Sprints are a welcome tool to help us bring more successful products and services to market.

Originally posted on the Mendix blog

Also posted on DZone

As a product manager, you want to enable your team to create successful digital products. To help your team achieve that you need to reduce the risk of failure for your projects.

Design sprints help answer critical business questions through design, prototyping and testing ideas with people who will use your product. Participating in a design sprint orients your team and stakeholders. Design sprints also help teams establish and reach clearly defined goals. They serve as useful starting points when kicking off a new feature, workflow, product, business or solving problems with an existing product.

In part 1 of this two-part series, we’ll be looking at what a design sprint is and the benefits you realize when you integrate them into the product development process.

What is design thinking?

Before we look at design sprints, let’s first talk about design thinking. Design thinking is shorthand for a collection of cognitive, strategic, and practical processes combined to form an approach that’s iterative and human-centered. It utilizes empathy and experimentation to break down complex problems and arrive at innovative solutions.

The goal of using design thinking is to make decisions based on what people want or need and reduce making risky bets based on instinct instead of evidence. Like Agile, it’s a collaborative and iterative process, but design thinking helps you make sure you’re solving the right problem. Agile alone is no guarantee that your teams will consistently deliver truly engaging, impactful solutions. Design thinking brings a strong user focus — ensuring user needs are kept front and center throughout the entire design and development process —  while Agile is an excellent way to incrementally deliver solutions.

What is a design sprint?

If you have been looking for a way to incorporate design thinking into your process, design sprints are a valuable way to do so. They provide a structure to design thinking practices to produce actionable results. Design sprints have their strength in sharing insights, ideation, prototyping, and testing concepts in a short timeframe. Because of that short timeframe, design sprints help focus on a part of the solution. Despite that, they are an excellent way to quickly learn if you are on the right track and allow you to easily pivot.

Design sprints are a tool that the Expert Services team at Mendix has started using for internal projects and client engagements.

Design sprints draw on the strengths of design thinking and Agile to minimize risk and increase collaboration by bringing team members, stakeholders, and your audience together. Like Mendix, design sprints encourage collaboration through making. Think of a design sprint as a way to learn without actually launching a product. During a design sprint, teams prototype, test and validate ideas with people who are actually using them, before the solutions are built or launched. The team learns from user testing feedback and then iterates in a short time frame.

Design sprints are a process made popular by Jake Knapp and the Google Ventures team in their book Sprint. As described by Knapp and the team at AJ&Smart, a design sprint can be a four- to five-day process used to solve big problems and test ideas. A dedicated team discusses a challenge, designs potential solutions, and tests with real people. You start with something vague and finish with real feedback and something tangible.

Over the course of a design sprint you go through six phases:

1. Understand

2. Define

3. Diverge

4. Decide

5. Prototype

6. Validate

The four- to five-day timeframe is not rigid and you can adapt it to the specific needs of the problem. Some phases may need more than a full day and others may need less; although it is still important to go through all of them. The phases mirror the idea of diverging and converging from design thinking.

By taking a pause to explore a problem, you save time and resources in the long run, helping you avoid pursuing solutions that don’t work or focusing on the wrong part of a problem.

What are the benefits of a design sprint?

One challenge with organizing a design sprint is getting the right people in the room. Following design thinking practices, a big part of organizing a design sprint is having a diverse group of people, skills, and perspectives. Another major part is at the end of the sprint, you’re testing your solutions with actual people. By including the people who will use your product to get feedback, you can quickly learn how they respond to ideas. It also allows your users to be an important component of your development process.

Teams should include members of your design and development teams, stakeholders, and product managers. By including them, design sprints can give team members a sense of ownership once you do get to a solution. Involving stakeholders in creating the solution makes them less likely to reject it later, and more likely to defend it. That sense of ownership improves the chances of the solution getting built. Design sprints break the mystery of design, helping stakeholders and developers understand the process. This, in turn, helps build trust and focus the attention of everyone involved.

In short, design sprints help you:

• Get an immediate result

• Incorporate stakeholders and get buy-in

• Test the potential of your concept without investing in code

• Limit the risk level and be able to pivot your project if needed

• Boost your creativity and keep the good ideas

• Maximize your return on investment

Is it time for a design sprint?

Not all problems should be approached by using a design sprint. If you have a well-defined problem to solve and access to the right stakeholders, a design sprint can prove invaluable. They are best for solving product challenges of medium- to high-impact, not routine work. Design sprints can be helpful for getting everyone on the same page and working toward the same goal.

When is it good to run a Design Sprint?

• At the start of a new project to define your product or create a shared vision

• When time is critical to inject speed into your development or decision-making process image placeholder

• At an impasse, roadblock or fork when your product or team needs to get unstuck

• After uncovering new insights to leverage new findings, data or research 

When shouldn’t you run a Design Sprint? 

• If you don’t have user research or a strong understanding of
  your customer base

• If you have clear product direction and just need dedicated
  design time

• If you don’t have leadership buy-in

In the Mendix agile process, we’ve started to use design sprints as a way to structure spikes — tasks aimed at answering a question or gathering information — when we come across a problem or a topic on which we don’t have a clear path forward. You’ll learn more about how we use design sprints in part 2 of this series. Stay tuned!

Originally posted on the Mendix blog

Also posted on DZone

Prototyping is one of the core principles of the design thinking process. It doesn’t matter how deep an understanding of an app’s intended users your team has developed in the empathy stage; most of their initial ideas for the interface, interactions, capabilities and overall user experience will miss the mark. Prototypes serve to test those ideas by giving end users and business stakeholders something tangible to react to, so they can provide feedback and the team can continuously iterate towards the desired solution. 

Empathizing with your end users over time engages you in a continuous dialog with them to provide solutions. Fundamental needs might not change, but how we address them does. Iterating and prototyping from empathy lets us connect and evolve with our users.

As Alan Cooper, the father of Visual Basic and a pioneer in the field of interaction design, once said, “The value of a prototype is in the education it gives you, not in the code itself.” Through the process of making prototypes, the team is able to think deeply, ask questions, and begin to uncover the true requirements for the solution—in a way that creating abstract specification documents could never replicate. 

Should all prototypes be thrown away?

Many believe that prototypes serve a temporary purpose and are ultimately meant to be replaced by something better. As part of the design thinking process, you are driven towards action: to create, to test, and to refine solutions that best meet your end users’ needs. View everything as a prototype. If testing proves an approach to be unsuccessful, don’t be afraid of trying something else. Speed is crucial so that minimal time and money is spent on an unsuccessful solution. Rapid prototyping advocates for the creation mockups that can validated—and if needed discarded—quickly as you build towards delivered software. The idea is that it’s better to focus on validating concepts and refining requirements early on, rather than investing in building software that will change significantly.

But what if you could have the best of both worlds: the ability to rapidly create a prototype to collect feedback from users, and the ability to continue refining it and have it ultimately become the production application? You’d still get the benefit of learning through prototyping, having spent minimal time and money in the process. On top of that, the time to value for the final solution would be accelerated, because you wouldn’t need to throw the prototype away and start from scratch. 

Take apps from prototype to production using low-code platforms

This is the power a low-code development platformbrings to the design thinking approach. Low-code platforms employ visual, WYSIWYG development techniques that are ideal for enabling small, cross-functional teams, and even individuals, to iteratively design and build applications.

In the context of design thinking, developers and even business domain experts can leverage a low-code platform to quickly construct functional prototypes for validation with users. Pulling from a variety of reusable templates, functional components, and professionally designed UI elements, they can assemble screens, and begin building the application’s logic and underlying data model, without needing to create everything from scratch. Once it’s ready for feedback, the prototype can be shared with a single click and previewed instantly across web, mobile, and tablet devices. Users can provide feedback via an embedded feedback widget, and a closed loop brings this feedback directly into the development environment, facilitating rapid iteration.

Using a low-code platform, it is certainly possible to create throwaway mockups with the same speed and ease you would experience using common prototyping tools. In fact, as noted above, many prototypes will simply miss the mark based on feedback from users. These can be discarded without a major investment of time and money, and the team can move on to the next one. 

But a prototype that does resonate with users can be carried forward, forming the basis of the actual finished application. The team can extend it with complex logic, integrate it with other systems, define a fine-grained security model, and more. They can leverage built-in agile project management tools to iteratively develop the solution, continuing to solicit and adapt based on user feedback. Lastly, a cloud-native architecture with out-of-the-box high availability and failover ensures that the application can be deployed at scale.

Enabled by these capabilities, some organizations like ADP eschew prototypes altogether and build working software that they put into users’ hands as quickly as possible. While ADP’s product incubator practices design thinking, it’s main focus is on the design thinking principleof empathy. Once the team develops a deep understanding of an app’s intended users, they use Mendix’s low-code platform to quickly build a working application that they test with real users and iterate based on their feedback. One app, Compass, was so successful that after rolling it out to 50,000 employees worldwide, ADP recently commercialized it for customers. 

Marry rapid prototyping with the ability to develop and deploy enterprise-grade apps

While prototyping tools will always have a place, particularly for low and medium fidelity wireframes, a low-code platform is an ideal solution to organizations looking to marry the benefits of prototyping with the need for accelerated delivery timeframes. In the context of a design thinking approach, such platforms enable teams to quickly construct fully functional prototypes for validation with users, with built-in feedback mechanisms to capture input on app designs. Because these prototypes can evolve all the way to robust production apps, time to value is reduced significantly because you don’t have to throw the prototype away and start building the production app from scratch. 

Written for the Mendix Blog