Where is the Border Between Agile and Bad Design?

View the original post

You guys know what I mean, right?


Design Your Own Design Process Step By Step

View the original post

Managers have developed dozens—at least—of processes that they believe improve efficiency and get better results. Those series of steps, however, may not match the needs of your design team. You might also find that some projects don’t fit into the restrictions of established stages of design? Who says you can’t make a design process of your own?

Start by learning popular approaches to project management

You may want to establish your own design process, but you should still take some time to learn from established project management methodologies. They may offer steps and concepts that you want to incorporate into your process.


With Agile, you create an iterative process that includes steps for:

  • Planning the design process and defining goals.
  • Creating the product design according to your established guidelines.
  • Testing your design to find opportunities for improvement—UXPin works well during this step because it lets you create fully functional prototypes with interactive features and real data.
  • Finalizing the first version of your product and releasing it to consumers.
  • Using feedback from users to make additional product improvements.
  • Continue the cycle until you retire the project and decide to use the current version of the product.


Scrum creates results quickly by planning ahead and relying on design sprints.

  • Choosing someone who will direct the design project’s vision.
  • Putting together a team of designers and developers with skills the project needs for success.
  • Selecting a “scrum master” who can run daily meetings.
  • Creating a list of the goals you need to meet during the design process.
  • Planning your design sprints.
  • Following a transparent workflow that lets everyone on the team see each person’s progress.
  • Meeting daily to discuss successes, failures, and barriers.
  • Making a prototype of the product to show the client – it’s very easy with a UXPin preview and share feature
  • Incorporating feedback into your plan and beginning the next design sprint.
  • Continuing until you finalize the product.


Kanban gives you an extremely easy way to track a design project’s progress. You can use it successfully by:

  • Visualizing and planning your workflow—this usually involves making columns for tasks that have been “not started,” are “in progress,” and have been “finished.”
  • Determining all of the tasks that you need to accomplish during the design project.
  • Establishing rules like deadlines and task assignments.
  • Moving tasks through the categories until you have completed them all.


As the name suggests, Lean gives you a streamlined approach to managing design processes. Key concepts of Lean include:

  • Setting specific goals and breaking them down into the tasks your team must complete reaching those goals.
  • Spending more time working on the design project instead of planning the project.
  • (User) testing designs for functionality and aesthetics before giving a prototype to the client.
  • Making any necessary changes to satisfy the client’s needs. 


Waterfall design processes recognize that you must finish some tasks before you can move on to others. Project managers commonly approach this by:

  • Establishing the design project’s requirements.
  • Working on all of the tasks required to complete the design.
  • Bringing the designs together to create a prototype.
  • Verifying that every feature in the prototype works.
  • Delivering the product to the client.
  • Managing updates as needed.

Related article: Agile vs. Scrum vs. Kanban: Which Project Management Methodology is Right For Your Team?

Identify your user persona

Regardless of the design process you decide to follow, you need to create user personas that help your team understand its target market. When you develop a user persona, think about features like:

  • Pain points the user wants your product to solve.
  • The user’s age, level of education, income, etc.
  • Interests and values that will appeal to the ideal user.
  • The devices that your user persona likely owns.

At the end of the process, you should have a concrete description of your user persona. It might say something like:

“23-year-old woman who recently graduated from college, wants to find ways to move her job forward, volunteers at a local animal shelter, and owns the latest iPhone.”

From this point, you can start to think about how your design makes it easier for her to reach the goals in her life. Perhaps you decide to build a career-oriented app that posts job openings and offers tips for getting a new position. Depending on whether you want to focus on a smaller niche, you might even create a product that helps animal-lovers find jobs.

Every person has numerous problems to solve. Just make sure that solving those problems becomes a part of your design process.

Related article: How a Human Centered Design Process Infinitely Enhances Your UX and UI

Use wireframes to outline basic ideas

Many designers have big ideas in their heads that they can’t wait to create in software. You want passion in your designers. Those are the people that do amazing work and push boundaries!

At the same time, you might want to slow them down to make your design process more manageable. 

Requiring wireframes might accomplish that goal for your design team. Even as your expert designers roll their eyes at the rather boring process of making wireframes, you must admit that they have advantages like:

  • Centralizing the team’s vision instead of letting each person pursue their own creative ideas.
  • Improving development by ensuring that you have a sturdy structure before you add cool features.
  • Saving money by shortening the design process and avoiding errors.
  • Easier handoffs when one person can’t complete a task—perhaps she calls in sick—and someone else has to do the work.
  • Improving the user’s experience by forcing your designs to think about the project from multiple perspectives instead of just making the product look amazing. 

Build a library of approved assets

Early in the design process, you should build a system design that creates guardrails for your designers. The design system can include approved:

  • Colors
  • Typography
  • Assets
  • Components

UXPin lets you add descriptions within your system design. Hopefully, the descriptions will prevent designers from barging into your office to ask why they can’t [insert interesting but unrealistic idea here].

Without a design system, some designers will take paths that don’t lead to your desired result. Stop that impulse by restricting them to the project’s approved options.

Learn more about UXPin data systems here.

Get feedback from as many people as possible

You and the rest of your design team might feel a lot of enthusiasm for your work. You might even think that this project is the best thing you’ve ever done.

Get feedback from as many people as possible so you can get an outsider’s perspective. What seems amazing to the people working on a project could look odd to those outside of the team.

UXPin lets you get feedback from anyone, regardless of whether or not they have a UXPin account. When you send a link to your prototype, people with the link can interact with your design and leave comments. Hopefully, they will love your work as much as you do. If they find issues, though, take them seriously. There’s a good chance that other people will also dislike how the feature works.

Decide what steps do and do not work for your team’s design process

Experiment with design processes to identify steps that work for your team. If you find something that doesn’t get positive results, discard it. If you feel like your process misses something, brainstorm to find a new step that will improve your process.

You don’t have to follow someone else’s rules. You can make your own design process that helps your team get the best results.

Sign Up for a Free Trial With UXPin

UXPin has several features that will support your own design process. Start your free trial today to see how it can contribute to the evolution of your design process.

The post Design Your Own Design Process Step By Step appeared first on Studio by UXPin.


How to increase your team’s productivity when stakes are high

View the original post

The speed at which the global healthcare industry moves is under a microscope these days. For almost a year now, you’ve gotten daily (sometimes hourly) updates on COVID-19 case volumes, breakthroughs in treatment, and vaccine rollouts. You’ve educated yourself on mRNA and spike proteins—spending hours researching the ins and outs of a virus that has changed our lives.

But perhaps, you’ve missed an important story behind these scientific advancements: Healthcare innovators are not only enacting meaningful change and quickly, but they’re doing it in one of the toughest environments. Companies like GSK, a science-led global healthcare company, have been undergoing digital transformations long before the onset of the global pandemic, but they were disrupted just like many other organizations by the overnight switch to remote work. Changing the way people work can take years. But, when the environment around us is changing at a rapid pace, we need to find ways to accelerate and adapt. While many companies had a bit more flexibility in their journeys, the stakes were higher for those in healthcare: Any slowing down equated to direct impact on the health of their customers. The situation demanded near perfection.

And yet, led by Rachel Burton, the director of transformation, and Alex Voorhees, the director of design on the Core Technology Design team, the GSK team rose to the occasion. Like many of us, the hardest part of enacting change was simply getting started. But Burton and Voorhees decided to approach their path forward just like they would any project: with human-centered design thinking principles. Rather than solely focus the team on objectives and hitting certain metrics, they chose to firmly ground their day-to-day journey in their people.

“In order to get to where we need to be, it all starts with the people at their desks,” Voorhees says.

As you enter your final social distancing stretch and feel the draining effects of a long disrupted life, look to the lessons of these groundbreakers to add some momentum to your day-to-day:

Remind yourself what a bias towards action feels like

Burton and Voorhees had been working on ways to demonstrate what it means to have a bias towards action—a way of working that needs to be felt rather than talked about. What better way to do that then through a design sprint? Voorhees took the Google 5-Day Design Sprint template and modified it to accommodate the team’s needs.

Marah Faron, one of the participants at the design sprint, shared, “There was intimacy and speed at the same time, which allowed us to feel what it means to be agile and bypassed the slow-moving tendencies of a larger company.”

While setting aside several days to facilitate a workshop can feel daunting, there’s something irreplaceable about feeling what it’s like to move fast as a group. Word of the sprint caught on, with more and more teams requesting to participate and adopt this new style of collaboration.

If you’re working on a project solo, you can create a “sprint” for yourself (and maybe a few others) to generate a small win and kickstart your momentum.


Try a new tool

Entering 2020, Voorhees and Burton knew they wanted to roll out a series of hands-on experiences as part of their skills transformation initiative. So much of what is “hands on” had previously been crafted as in-person experiences. Stay at home orders made this impossible, confronting the team with a new unforeseen challenge: how can you create transformative experiences while everyone is remote?

Voorhees found a solution in Freehand, InVision’s online digital whiteboard. Freehand allowed the team to accommodate team members from across the globe in a way that still felt engaging and productive.

“The sprint leveled the playing field. Freehand facilitated a digital space to brainstorm ideas where everyone had a voice. Even with no design experience, the tool was easy enough that there was no learning curve whatsoever.” shared Faron.

You can add spark to your everyday analog tasks by trying them out a new way. Try grabbing one or two colleagues (or team members) to create bonding while also remaining productive.

Create psychological safety

In order to be productive (while also in a high stakes situation), you need to take the pressure off yourself a bit. Creating an environment where everyone feels like they can take risks and be creative without the pressure for perfection is a critical aspect of fostering breakthroughs. Said simply, if you’re wanting to promote change, you and your team needs to be open to it.

One way to create psychological safety is by choosing tools and platforms that feel approachable no matter an individual’s background. Faron recounts her feelings during the design sprint process, “When I heard that there would be sketching involved, I freaked out. I’m a data scientist and developer and I was nervous about drawing things using a trackpad. Using Freehand, I could use shortcuts to create clean shapes and not worry because they looked great.”

Burton, who also participated in the design sprint reflected, “It created a great learning moment, because everyone is on the edge of their seat and it’s highly visible. I enjoyed seeing the richness of ideas and was blown away by the creativity.”

Voorhees agrees, “Be resilient and continue to try and experiment with an open mind. With this sprint, we tried for a long time to make something happen and we didn’t give up on it.”

Know that the result of your design sprint won’t be a fully-baked solution, but you’ll be surprised by how much you can create and how far you can take something when you create the space and environment to move quickly.

Get started with whiteboarding templates

Get started with whiteboarding templates, Explore Templates

The post How to increase your team’s productivity when stakes are high appeared first on Inside Design.

Agile Remote

5 simple strategies to make your next remote retrospective more engaging

View the original post

A retrospective, in plain terms, is looking back. Thumb through any self-improvement book and you’ll likely find the concept positioned as the trick to successfully moving forward. Born from mindfulness, retrospectives are woven into our human DNA. So, why wouldn’t we expand this reflect-to-improve exercise to our teams?

Finding better ways to remotely build your team should be a priority for 2021— especially as we’re going to be doing this for a while. Retrospectives are great because anytime you get your whole team together with an open floor for chatting, you’re bound to have a fruitful discussion. By simply putting retros on the calendar and building them into your team’s rhythm, you’ll grow your team’s trust.

But, with some added structure, you can make these magical meetings even more engaging and productive. Here, five easy-to-implement strategies for improving your retrospectives in a remote work environments:

1. Set clear expectations for participation

Every team member should go into the meeting knowing how to participate. For example, do you expect everyone to turn their video on? Reading body language and picking up on communication cues can be tough if, say, half the meeting participants don’t have video enabled. Also, encourage team members to step away from Slack or e-mail during the retro. Reinforce that the room is a safe space by stating the team’s orientation towards exposing issues and taking action.

2. Mix up the format 

While making sure your retrospective’s structure invites participation, try changing the format weekly. By mixing it up, you can evoke different responses from the team. At InVision, rather than ask for volunteers, we rotate through assigned facilitators.

3. Greet everyone by name as they join the meeting

If meeting in-person, you’d walk into a conference room and feel the energy as you greet your teammates. But how do you replicate this IRL experience in a virtual meeting? At InVision, we play music for the first few minutes as team members enter the meeting. It gives everyone a break before focusing on the meeting. A subtle, yet important step here is greeting every person by name. They’ll feel seen and will more confidently speak up during the retro.

4. Start with some easy questions 

Begin the meeting with some lightweight questions that everyone must answer. Here’s some examples:

  • “How would you describe the past sprint?”
  • “How would you describe the last two weeks in a word?”
  • “If our team was a vehicle traveling down the highway in our last sprint, what would it be? A tricycle? A minivan? A convertible?”

These low-investment but creative questions get people thinking and talking.

5. Use a template

If you’re looking for an easy starting point for a remote retrospective, we have a template you can use that’s designed specifically for these meetings: The plug-and-play Freehand Retrospective Template. The online whiteboard has a low learning curve and can provide prompts like “what went well?” “what needs improvement?” and “next steps.” This encourages team members to participate by writing down ideas on sticky notes and then bring them to the main retrospective board.

Want to get more from your team during agile planning?

Want to get more from your team during agile planning?, Watch the talk now

The post 5 simple strategies to make your next remote retrospective more engaging appeared first on Inside Design.


Design Processes, Implementation Phases and Creating an MVP

View the original post

The topic of MVPs recently came about in a discussion with fellow Designers and former co-workers. Our discussion was prompted by the question: Does an MVP compromise the scope of a solution that is achieved during the Design Process, or is it simply an edited version of a potentially larger narrative, which has been backlogged, and will eventually see the light of day. Also on this topic, we discussed how the Implementation aspect of a Design Process, and particularly its quality, can enhance the experience of a solution or on the opposite side of the spectrum, completely underwhelm and undermine it (and just as a friendly reminder, Implementation is a part of the Materialization Chapter of the Design Thinking process). This article showcases two examples I have personally been fortunate enough to have worked through, which illustrate how different approaches towards MVPs can and will actually influence timelines of product delivery to market, the quality of Implementation associated with it, and how the Design Process itself was deeply ensconced in all these events.

Design Processes and MVPs. Wikipedia as usual provides a succinct definition of what constitutes an actual MVP: “A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. A focus on releasing an MVP means that developers potentially avoid lengthy and (ultimately) unnecessary work. Instead, they iterate on working versions and respond to feedback, challenging and validating assumptions about a product’s requirements.”

Interestingly enough, the definition of MVP never refers to Design or its process altogether, choosing to focus on the implementation aspect of a solution that has been devised. I’ve written previously on the topic of Design Thinking, Iteration Cycles and generally going through that process with the intent to grasp and establish a solution/path which is solidly constructed. At its core, this process and methodology, represents the convergence of multiple points of view hailing from varied Team Members and Departments, but also and just as crucially important, gathers all the input collected from the research that has been performed. I’ve also alluded to the topic of research in previous articles, but it specifically entails and includes analytics, usability testing, customer interviews, gathering of user review and ratings, competitive analysis, market canvasing/triaging, all of this assessed, compiled and documented, obviously sustaining the iterative cycle and refinement process.

The goal is of course to understand customer/user journeys, the jobs to be done, identify patterns (both behavioral, but also operational tied with software solutions, all of this married with gaining a clearer vision of expectations) and generally speaking, address the most important focal problematic points which need to be solved. Typically the output of the Design Process up until the Explore path, allows for these scenarios to be uncovered, tested and gain insight and validation from users and testers. However when it comes time to defining an MVP and implementing a solution, there are several factors that are usually taken into consideration, namely timelines, cost of development, availability of resources, sales strategy, brand positioning, among many other factors. All this to say, typically not every single feature or flow that is uncovered during the process is implemented as it was outlined, tested and refined. This does not constitute a fallacy of the Process itself, it merely surfaces the inherent aspect of being flexible and malleable, qualities that both Design and Designers need to always have in their minds.

The MVP is, for the lack of a better definition & analogy, a version 1, a first chapter of something that is being progressively built, of an ongoing narrative. A product has a life span, and that is ever more present than in software design, where most teams are agile, and just as importantly, where products and solutions keep evolving as a direct result of actually being used by clients/users. I’ve been fortunate to have worked & contributed to many products, alongside an array of very talented teams with very different timelines, but for the sake of illustrating this article, I’m going to provide two very distinct examples of how MVPs and Design Processes were tackled.

The first one, is a rather recent example of a Progressive Web App whose incubation process and Design Process was swift and agile. The timeline for this application, and for its first release was 4 months. The Design Process which my team embarked on, produced a series of outcomes and artifacts which informed the direction in which the first release was going to go. This MVP was a result of several discussions, but included aspects such as client feedback, time to market, implementation cost, resources, brand strategy, seasonality, to name but a few factors. Some of the flows uncovered during the process were backlogged and new directions were devised and tested, in order to effectively marry the MVP logistics. This is an example where the Design Process and MVP establishment were collaborative partners and the integration was seamless.

The second example, pertains to an application and even more so, to an ecosystem which was developed within a far more considerable time frame (quite a few years of incubation and also investment). This product had a lengthy Design Process, since it was an entirely new Product Line which demanded a thorough research process, across multiple geographical locations, not to mention it had ties with different product lines and also hardware/industrial design components). That being said, this application also had an MVP, which upon its release was promptly analyzed, triaged and assessed. Understanding the metrics sustaining the early adoption was essential, since there was already a series of subsequent features and enhancements which were being orchestrated to be released. Once again, the MVP was a part of longer Product Design journey, which ultimately aimed to pierce through a new market segment and expand the brand’s footprint. MVPs that are effectively delivered, should be a convergence of points of view and one of the outputs of the Design Process itself, even if they are indeed a bashful version of what the solution is going to be. That effectiveness is deeply tied to them ultimately remaining faithful to the integrity of the solution that is being delivered.

Implementation Processes and Quality of Output. One of the most important chapters of the Design Thinking Process is the Materialization chapter. Implementing what is uncovered in the previous chapters is a fundamental aspect of delivering a solution that is useful, usable, credible, findable, desirable, accessible and credible. The virtuosity of good implementation can include automation of processes, machine learning integration, AI paradigms, enhancing motion details, to name but a few, but all these have a common narrative thread: quality married with accountability. Whatever is materialized and implemented should always be consistent with what is uncovered, tested and prioritized in the previous chapters of the Process. Whenever the implementation fails to represent what was uncovered, the process itself is a failure. The integration of all these diverse teams, is done with the sole purpose of bringing insight, shared ownership, but also awareness towards what is being conceived, in order for everyone to understand where constraints lie, and overcome them accordingly. The necessity of having this coherence of efforts and ultimately outputs, throughout the entire process is fundamental to deliver solutions to the market which are impactful for the business as well as the users.

Reality check. Shaping MVPs can induce a fair amount of stress on teams, particularly when team members fear that what was uncovered during the sessions is being abandoned. Hopefully as teams ingratiate themselves and their efforts, they realize that the narrative that is being shaped, is a continuous one. What comes next after the release is driven by momentum and continuing to tell a powerful story. The question is always — are we saying enough with an MVP, and will it be impactful enough for clients and customers. The core aspect of the process that teams always need to keep present, is essentially the problem statement that sustains the solution being edified. Is that problem being addressed, is the solution presented relevant, credible and distinguishable enough from what is already on the market. These are topics which need to be reflected upon when devising MVPs. When it comes to Implementation phases, it’s always important to keep in mind topics of accountability, quality triage, and finally assessing if the process itself and the output produced, is actually marrying with the statement an Organization plans to unveil in the market. Independently of being an MVP or otherwise, having a robust and solidly conceived product/feature solution carves out a path of excellent for whatever endeavor that is established, and will likely retain users and clients attention and retention.

I’ll conclude this article with a quote on the topic of quality, from the great Aristotle:

“Quality is not an act, it is a habit.”

Design Processes, Implementation Phases and Creating an MVP was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.


Design Sprints vs Agile Sprints vs Design Thinking

View the original post

What’s the Difference Between Design Thinking, Design Sprints, and Agile Sprints? Some combination of this always comes up and Let’s Get…


User Stories: As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered]

View the original post

Let’s examine a tool so simple yet so powerful that once you’ve learned about it, you will apply it in all your projects. It is a great design method that enhances collaboration among all stakeholders.
Users’ Needs are a core part of Agile: the User Stories
There are so many articles about UX and Agile. Lots of them are rants about how Agile is so UX unfriendly, how these two approaches cannot work together, etc. Yes, it is difficult to work on software projects. Yes, it is challenging to work in collaboration with other disciplines. And, while we’re at it, we might say “yes” to so many cons, that we won’t address them all in a single article.
Our focus today is on this simple and quick d…


Mapping User Stories in Agile

View the original post

Summary: User-story maps help Agile teams define what to build and maintain visibility for how it all fits together. They enable user-centered conversations, collaboration, and feature prioritization to align and guide iterative product development.

In traditional product-development processes, teams often rely on wasteful and lengthy business requirements documents and functional design specifications to move from a vison for a digital product to outlining what it should include and how it should work. Instead of having an ongoing conversation about users, problems, ideas, and solutions, teams expect distributed documentation to suffice.

However, these documents usually fail; no one has the time or attention to read them, and even those who do read them end to end will likely come away with vastly different interpretations of what to build. Rather than propelling productivity, these heavy documents stifle creativity, communication, collaboration, and innovation from the start. As an alternative, user-story maps work much better as lightweight representations of the digital product that an Agile team intends to build.

User-Story Mapping Defined

Definition: User-story mapping (also known as user-story maps, story maps, and story mapping) is a lean UX-mapping method , often practiced by Agile teams, that uses sticky notes and sketches to outline the interactions that the team expects users to go through to complete their goals in a digital product.

Read Full Article


The case against Waterfall

View the original post

I genuinely believe the Agile manifesto outlines a great set of principles for a successful development team. As a certified SCRUM practitioner, I also believe that formalized project management techniques are helping large teams to improve their throughput.

Every successful team has to find a unique way of shipping great products. Unfortunately, some patterns are preventing teams from defining their unique way, and I would like to share some of my observations of these.

Before AgileNo sane person advocates for Waterfall. Repeat, there are zero sane Waterfall advocates. That said, every argument that Agile adherents make against their opponents could easily be made