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

So why talk about this?

Designing for accessibility is not that hard. At work, we’ve heard many questions from prospects, clients, and team members asking about accessibility. It’s a topic a bit outside their knowledge space and not something they’re used to discussing. Accessibility and the related practices of inclusive design are multi-faceted topics. From working in finance and insurance and having to be mindful of audits focused on this, and from my time teaching people with various levels of physical and cognitive abilities, it’s a topic that matters to me.

I’ve been collaborating with some other team members interested in the subject for an internal presentation and resources to serve as an introduction to inclusive design and accessibility, along with some common concepts and terms related to them. We’ve been sharing information on what it means to be accessibility compliant, how we can currently advise clients, and ways we can improve our own offerings. If it’s not something included in the beginning, going back to include a more inclusive approach to increase compliance and accessibility can be a longer process, needing wider involvement, but with this presentation we hope to start the conversation and help inform our community on these topics.

How you define accessibility?

Before going too far, there is one point I want to make:

A disability is a physical or mental condition that limits a person’s movements, senses, or activities. A disability is any continuing condition that restricts everyday activities. 

They can be episodic. They might not be permanent. When it comes to people, there’s no such thing as “normal.” The interactions we design with technology depend heavily on what we can see, hear, say, and touch. Assuming all those senses and abilities are fully enabled all the time creates the potential to ignore much of the range of humanity. It can include situational impairments, activity limitations, and restrictions on participation. 

When it comes to design, every decision we make can raise or lower barriers. 

What is Accessibility?

Accessibility is the practice of making your products and services usable by as many people as possible. Accessibility is a goal. Accessibility is the goal to ensure that products support each individual user’s needs and preferences. There is no perfectly “accessible” final result. Designing for people is an iterative process.

Accessibility involves two key issues:

1. How users with disabilities access electronic information

2. How web content designers and developers enable web pages to function with assistive devices used by individuals with disabilities

What is Inclusive Design?

Inclusive design involves designing products and services to be usable by everyone to the greatest extent possible, without the need for adaptation. It’s design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.

Inclusive design recognizes that our needs shift with time and circumstance, so it anticipates different ways an individual might interact with the world as life goes on. Aging, permanent or temporary disability, carrying a load of grocery bags, pushing a stroller, or sitting in a business meeting are some examples of circumstances that impact how you interact with the world around you — circumstances that might change what you do or how you do things.

• Considers as many people’s needs and abilities as possible

• Aims to please a diverse range of individuals and accommodate a variety of experiences and methods of interaction

• Doesn’t specifically target people with disabilities

How are they different?

Including accessibility into products aims to remove a barrier for people with disabilities. Inclusive design strives to fundamentally redesign a product so that the barrier does not exist in the first place

• Building for accessibility is reactive

• Inclusive design is proactive

• Inclusive design goal is to be usable by everyone to the greatest extent possible.

• Accessible design is more specialist and addresses discriminatory aspects in UX for people with disabilities

How are they related?

Accessibility and inclusive design work together to make experiences that are not only compliant with standards. •Accessibility is a goal and outcome of inclusive design

Inclusive design has a strong heritage in accessibility. We define inclusive design as a set of practices that can be applied to any existing design process. Inclusive is how we design. It’s our tools and methods. In comparison, accessibility offer ways to improve access to what is already designed.

A curb cut is still a curb. The cut makes the curb more accessible to wide array of contexts and needs. It helps people in bicycles transition from street to sidewalk, it aids people in wheelchairs and walkers ease onto sidewalks, it also helps anyone with a child in a stroller, moving objects, or riding other modes of transportation. Inclusive design gives us ways to design for ever-changing human motivations and needs. And design systems that can adapt to fit those diverse needs.

Why should I care?  

Individuals and organizations with different functions will find different reasons to adopt accessibility and inclusive practices: 

• Accessibility uses innovative technology

• Accessibility creates market opportunity

• Accessibility is the right thing to do

• Accessibility offers benefits for all users

• Accessibility is the law for many institutions

• Accessibility uses innovative technology

Accessible design is based on the premise that web pages must work with a broader range of browsers than only Mozilla Firefox or Internet Explorer. A page must be accessible whether using a screen reader, a refreshable braille display, or a head pointer. Making pages work in nonstandard browsers often makes them available to other consumer Internet devices, such as mobile phones or handheld personal digital assistants (PDAs). The techniques of accessibility are based on recent technologies and design strategies. Older, static HTML designs often intermix content with formatting on web pages. Accessibility guidelines encourage the separation of formatting from content through the use of cascading style sheets (CSS) to allow more flexible use of content and easier implementation of more powerful dynamic models.

Accessibility is the right thing to do

First and foremost: Accessibility represents an important step toward independence for individuals with disabilities. Accessible web pages provide access to fundamental government services and information such as tax forms, social programs, and legislative representatives. Accessible web pages also make possible a broader range of employment and educational opportunities by providing added means of communication. In addition, accessibility allows users with disabilities to participate in day-to-day activities many of us take for granted, such as reading a newspaper or buying a gift for a loved one.

Accessibility creates market opportunity

Accessibility offers the potential for organizations and businesses to reach new customers and new markets. As additional accessibility policies are adopted, the need among government and educational institutions for goods and services that support accessibility policy is growing. In the United States, businesses providing goods and services to the government via the web or other information technology should understand Section 508. Businesses that understand accessibility and comply with Section 508 have a strong market advantage, which is multiplied as local governments implement new policies.

Accessibility offers benefits for all users

As with many improvements intended for individuals with disabilities, the enhancements of accessible design offer benefits for all users of the web. Anyone who has pushed a shopping cart out of a grocery store can attest to the value of automatic doors and ramps cut into curbs. Similarly, accessible web pages are often easier to read, easier to navigate, and faster to download.

Accessibility is the law for many institutions

With new national requirements in the United States, Canada, and the European Union, and more to come in the near future, there are numerous legal mandates for accessibility. These policies will likely expand in scope. In the United States, for instance, Section 508 of the U.S. Rehabilitation Act sets standards for web pages designed or maintained by federal agencies. State and local governments as well as educational and nonprofit institutions around the United States are considering their own accessibility policies. For example, the University of Wisconsin at Madison adopted an Accessibility Policy requiring all pages published or hosted by the university to conform to all WCAG level A and AA guidelines.

What are accessibility regulations?

I’ll be following this post with ones focused on accessibility guidelines and regulations, and listing some tools and resources to learn more about these topics and how to include them when working on projects.

For the next session of our Action Design best practices series, we are collaborating with Ethical Design Boston.

Our next session will be focused on Ethics in UX Research.

Empathy. Deep Empathy. Accessibility. Inclusiveness. Localization. As the tech industry matures, more and more organizations are acknowledging how the users of their products often differ from those creating them. To close this gap and design better experiences, product teams have begun incorporating more user research into their development cycles.

Including users in the design process presents several ethical challenges, however. For example, how do we test important business assumptions while ensuring participant well-being and privacy? How do we balance user feedback with subject matter expertise? Using examples from the speaker’s work, this talk explores the sometimes thin line between “human-centric” and unethical.

About Our Speaker

Alba N. Villamil is an independent UX Researcher who specializes in designing products for vulnerable populations like refugees and low-income families. In addition to working with pre-stage startups, she has worked on projects with Code for America, the Harvard Kennedy School, and the Rochester City School District. She studied sociology at Harvard University and social psychology at Swarthmore College.

Event Schedule

Registration info TBD, but we’re aiming for 10 DEC 2018, otherwise after New Year’s.

• 6:00 – 6:30 pm: Networking

• 6:30 – 7:30 pm: Talk + Q&A

• 7:30 – 8:00 pm: Networking

What is Ethical Technology Boston?

Ethical Technology Boston is a community of technology & design professionals looking to incorporate an aspect of social responsibility into our daily work. We meet locally to discuss and evaluate complex real life ethical issues and potential implications that we face in our industries. Through these discussions we learn from each other, develop new practices and gain a trusted network of likeminded individuals. We’re also part of a global online community for Ethical Technology and Design at ethicsofdesign.org.