DEV Community: Browser

Do MVPs Fail Us?

Browser — Wed, 04 Sep 2024 01:09:12 +0000

The Minimum Viable Product (MVP) has been a cornerstone of startup methodology for over a decade, promising a way to validate ideas quickly and efficiently. But as markets evolve and customer expectations soar, a question emerges: Does the MVP way of thinking fail us?

This question isn’t about abandoning the MVP concept entirely, but rather examining its limitations and exploring how we can evolve our approach to product development. In an era where user experience is crucial and switching costs can be significant, the traditional MVP may fall short in several critical areas:

It often prioritises speed over adoptability

It may not adequately address market fit beyond early adopters

It can overlook crucial adoption barriers in favour of basic functionality

As we delve into this exploration, we’ll challenge the conventional wisdom surrounding MVPs and propose a more holistic framework that addresses these shortcomings. By expanding our understanding of what “minimum” and “viable” truly mean in today’s market context, we can develop products that not only validate ideas but also pave the way for widespread adoption and long-term success.

Are there MVP alternatives?

Which choice works for you?
While the traditional MVP approach has been valuable, it’s crucial to expand our thinking to encompass a more comprehensive framework that addresses both product viability and market adoption.

Minimum Viable Outcome (MVO) Focus on desired business and customer outcomes, setting specific, measurable, and time-bound objectives that align with overall business strategy and market needs.

Airbnb’s MVO

When Airbnb started, their MVO wasn’t just to create a platform for home-sharing. They focused on the specific outcome of making it easy and trustworthy for people to rent out their spare rooms. This outcome-focused approach led them to implement features like host and guest profiles, reviews, and a secure payment system. By concentrating on this core outcome, Airbnb was able to build trust in their platform and drive adoption in a market where the idea of staying in a stranger’s home was novel and potentially risky.

Minimum Viable Data (MVD) Identify essential metrics for decision-making and AI model requirements, balancing data needs with privacy and security concerns. Include metrics that measure not just usage, but actual adoption and replacement of existing solutions.

Netflix’s MVD strategy

Netflix’s transition from DVD rentals to streaming required a careful MVD approach. They needed to gather enough data to inform their streaming strategy without compromising user privacy or overwhelming their systems. Netflix focused on collecting viewing habits, user ratings, and completion rates. This MVD approach allowed them to develop their recommendation algorithm, which became a key driver of user engagement and retention. By focusing on these essential data points, Netflix was able to personalise content suggestions, leading to increased user satisfaction and platform stickiness.

Minimum Viable Output (MVOU) Deliver tangible artefacts that support both MVP and MVO, fostering collaboration across teams and enabling iterative improvement based on feedback. Ensure these outputs address key adoption barriers.

Spotify’s MVOU

When Spotify entered the music streaming market, they faced significant competition from established players like iTunes. Their MVOU strategy focused on delivering a seamless, fast, and legal way to access a vast music library. They started with a desktop application that emphasised speed and ease of use. This tangible output allowed users to experience the core value proposition immediately – instant access to millions of songs without the need to purchase individual tracks. By focusing on this key output, Spotify was able to overcome adoption barriers related to the perceived complexity and cost of digital music consumption.

Minimum Viable Segment (MVS) Identify and focus on a specific customer segment that is most likely to adopt your product early and provide valuable feedback for iteration.

Slack’s MVS approach

Slack initially targeted tech-savvy teams, particularly developers, as their minimum viable segment. This group was more likely to adopt new communication tools and provide detailed feedback. By focusing on this segment, Slack was able to refine its product based on the needs of power users, which ultimately made it more robust and feature-rich for a broader market. This MVS strategy allowed Slack to build a strong foundation of enthusiastic users who became advocates for the platform, driving wider adoption.

Minimum Viable Adoption (MVA) Consider the minimum features and value required to overcome adoption barriers such as switching costs and sunk investments in existing solutions. This concept integrates aspects of the Net Adoption Threshold (NAT) framework.

Zoom’s MVA strategy

When Zoom entered the video conferencing market, they faced established competitors like Skype and GoToMeeting. Zoom’s MVA strategy focused on simplifying the user experience to reduce adoption barriers. They made it possible to join a meeting with just one click, without requiring software downloads or complex setup processes. This approach directly addressed the switching costs associated with adopting a new video conferencing tool. By minimising these barriers, Zoom was able to achieve rapid adoption, even in a crowded market.

Minimum Viable Experience (MVE) Design the core user experience that delivers the essential value of your product while ensuring it’s intuitive and engaging enough to drive continued use and adoption.

Duolingo’s MVE approach

Duolingo’s initial MVE focused on making language learning feel like a game. They distilled complex language learning concepts into bite-sized, engaging lessons that users could complete in just a few minutes. This gamified experience was crucial in overcoming the perceived difficulty and time commitment associated with learning a new language. By creating an MVE that was both educational and entertaining, Duolingo was able to keep users engaged and coming back, driving long-term adoption and habit formation.

While these six approaches—MVO, MVD, MVOU, MVS, MVA, and MVE—offer distinct perspectives on product development and market entry strategies, it’s important to recognise that there is often significant overlap between them. For instance:

Airbnb’s focus on trust-building (MVO) directly informed their data collection strategy (MVD) and user experience design (MVE).
Slack’s choice of initial target audience (MVS) influenced both the core features they developed (MVOU) and the adoption barriers they needed to overcome (MVA).

Zoom’s emphasis on reducing adoption friction (MVA) was intrinsically linked to their user experience design (MVE) and the outcomes they prioritized (MVO).

This interconnectedness highlights the complexity of choosing the right approach—or combination of approaches—for your specific product and market context. Factors such as:

Industry dynamics and competitive landscape

Target audience characteristics and preferences

Available resources and technological capabilities

Regulatory environment and data privacy considerations

All play crucial roles in determining which MVP strategy (or strategies) will be most effective.

Given these complexities, deciding on the optimal approach often requires careful reflection, market analysis, and sometimes external expertise. It’s not uncommon for companies to struggle with identifying the most suitable MVP strategy for their unique situation.

If you find yourself grappling with these decisions or seeking to optimise your product development and go-to-market strategy, consider some assistance.

Redefining “Minimum” in Product Development

MVP vs Waterfall
Build for right now and scale as needed
When we talk about “minimum” in the context of MVP or its variants, it’s crucial to consider the following factors:

Organisational Resources
The “minimum” should be defined in relation to the organisation’s available resources, including budget, personnel, and technological capabilities. It’s about maximising value creation within existing constraints while ensuring the product can cross the adoption threshold.

Timeline
“Minimum” should be contextualised within the project timeline and market demands. It’s not just about speed, but about delivering the right value at the right time to drive adoption.

User and Market Expectations
The “minimum” should meet or exceed the baseline expectations of your target users and market. In mature markets, this baseline may be higher than in emerging ones. Consider not just feature expectations, but also the value required to overcome inertia and drive adoption.

The Power of Focus: When Traditional MVPs Thrive

Keep your eyes on the ball
While we advocate for a more holistic approach, it’s important to note that traditional MVPs can still succeed when they adhere to a philosophy of excelling in one core area. The key is to:

Identify a single, critical user need or pain point
Develop a focused solution that addresses this need exceptionally well
Ensure the solution provides enough value to overcome adoption barriers
Iterate rapidly based on user feedback to refine and expand the offering

This approach can be particularly effective for startups or when entering new markets, where establishing a strong foothold with a singular focus can pave the way for future growth and wider adoption.

Aligning everyone and everything
The big question of course is; How do we align the design, development, and deployment approach with Stakeholder dialogue?

A group of people take part in a insight application workshop in our London office

Product momentum at the speed of dialogue
The chosen approach to product development should directly inform and shape stakeholder conversations, especially regarding market adoption. This alignment ensures that all decisions and feature requests are evaluated against the established process, goals, and adoption criteria. Here’s how this can work:

Clear Communication of Approach: Ensure all stakeholders understand the chosen development methodology and its focus on both viability and adoption.
Feature Evaluation Framework: Create a clear framework for evaluating new feature requests based on their contribution to both core value and adoption potential.
Stakeholder Education: Educate stakeholders on the benefits of the chosen approach and why considering adoption barriers is crucial for the product’s success.
Decision-Making Process: Establish a transparent process for feature decisions that considers both immediate viability and long-term adoption potential.
Iterative Feedback Loop: Set up regular check-ins with stakeholders to review progress, gather feedback, and assess adoption metrics.

Evolving Beyond MVP-Centric Thinking

So, do MVPs fail us? If treated as the default tool, yes. If treated as an option to customise to the circumstances of the product’s circumstances, no. The MVP concept has undoubtedly revolutionised product development, enabling countless startups to test ideas and iterate quickly. However, in its traditional form, it often falls short of addressing the complex realities of today’s market landscapes.

The failure isn’t in the MVP concept itself, but in our sometimes narrow interpretation and application of it. By expanding our framework to include considerations of market adoption, user experience, and long-term viability, we can evolve the MVP approach to meet the challenges of modern product development.

Special thanks to Polina Zimmerman, Jason Goodman, & Mark Arron Smith, Finnian HaDiep, Guilherme Garcia, D Jonez

The post Do MVPs Fail Us? appeared first on Browser London.

A UX Design Dilemma: Adapt Brand Guidelines or Start Afresh?

Browser — Thu, 25 Apr 2024 11:23:31 +0000

Whilst the dream for most designers is to start a new project from scratch and have all of the creative licence and control that comes with that, this unfortunately isn’t always the case. Putting aside those fun projects that you may do when starting out (anyone else guilty of designing multiple travel and adventure apps just for fun?), a large proportion of projects will be some form of a redesign or continuous improvement to an existing product or platform.

This is certainly more challenging and there is a lot to consider across all areas when it comes to the UX and UI design, not to mention the engineering. One of the many considerations we designers face is the use of the brand guidelines and their effectiveness and appropriateness for the job at hand. In this article, I’m going to discuss the two sides of the spectrum that we often face: adapting the brand guidelines vs starting afresh.

Every brand strives to retain its identity both offline and online

The challenge at large

Before I dive into the minutiae of brand guidelines, it’s worth touching on the challenge as a whole when redesigning platforms and why you’d need to consider a redesign in the first place.

Technology and design have developed at an unprecedented pace in recent years, resulting in many products and platforms becoming outdated fast, this of course causes issues across the entire customer experience. From outdated and inflexible technology to clunky and inaccessible interfaces, these outdated platforms end up and costing companies where it hurst the most, user traction and engagement. No one wants to lose out to a competitor platform.

Whilst a redesign can be considered costly, an investment into modernisation is just that, an investment, it can improve brand perception, increase productivity, enhance accessibility, plus create possibilities for continuous innovation and more. A company that turns its back on modernisation will be paying the price and may struggle to thrive in the constantly developing digital landscape we find ourselves in.

Whilst a redesign goes far beyond the design of the interface, it will usually consider all areas of the user experience, having said that the UI design is an essential aspect that will have a significant impact on the accessibility, overall usability and perception of the product or platform. This is where the brand guidelines come in.

The ideal scenarios

As a designer, there are two possible ideal scenarios when faced with redesigning a platform interface. One is that you are provided with incredibly thorough, thought-through, recent, carefully documented and digitally focused brand guidelines. The other is that you have to start completely from scratch. However, what is often the case is that you’re presented with something somewhere in the middle of these, something that perhaps has the basics, or wasn’t created with digital and UI design in mind. And even if you are that lucky designer who does get handed the wonderfully thought-through guidelines, there is still a good chance that some expansion upon it will be required for the purposes of the UX and UI design.

Guidelines aren’t the be-all-and-end-all

Before we answer the question at the beginning of this article, we must first take a look at the limitations of traditional brand guidelines, and why they are not the be-all-and-end-all for any redesign in the first place.

Your traditional brand guideline documents are in some cases created by brand and marketing teams who may not necessarily be familiar with the intricacies and requirements of how a digital platform operates. Usually, their primary focus is on laying out the brand language, visual identity and creating rules and guidelines for various possible design scenarios. They don’t tend to go into the complexities such as context, error and validation messaging, or provide the detail required for interactive elements and states.

Furthermore, you’ll be lucky if you’re presented with a colour palette or rules that has been developed with accessibility in mind. In fact, I have personally only come across a few traditional brand guideline documents that outline the colour contrast ratios of certain colour combinations from their palette. This isn’t to say that they’re not out there, it just means that what you are given to work with may well not have all of these bases covered.

In a perfect world, branding, design, marketing and product teams would all communicate wonderfully, creating a world in which brands are created with a digital-first approach, including all requirements and considerations for the UX and UI design, we might call this a design system. However, we don’t live in that perfect world and we often have to do the best we can with what we are handed.

Design systems can be incredibly useful when it comes to scaling

Are they even relevant?

Another factor coming into play is this: How up-to-date are the brand guidelines that you’re being sent? After all, if they’re years old, they may no longer be fit for purpose anyway, and so a start-from-scratch approach may still be on the cards. That is, if you can clearly articulate the benefit of taking on what can be a much larger (and therefore, more costly) project.

At the end of the day, if a brand has recently been developed or re-designed then you’re in with more of a chance of it being fit for purpose. And if the brand hasn’t been touched in years, isn’t digitally focused and has significant gaps, then you’re going to need to take a deeper look before starting any UX and UI redesign.

Why you may want to adapt the brand guidelines

One benefit of adapting the brand guidelines for an interface redesign is that your users will be familiar with that certain look and feel, and so may find it easier to adapt to the new interface. After all, a radical and sudden change to the interface that both looks and works so differently from what the users are familiar with can cause great frustration, and in the worst-case scenario, abandonment.

We do see this happen with redesigns in many areas of design failing and causing huge amounts of financial loss and damage to the brand. From GAP’s rebrand in 2010 which cost $100 million to Twitter’s rebrand to X which is widely considered a failure, the examples are countless and act as a warning to all who attempt a rebrand or redesign. However, we can learn from others’ mistakes and are not doomed to repeat them.

Twitter’s controversial rebrand in 2023

Why you may want to start afresh

Whilst adapting brand guidelines may help users get to grips sooner with a redesigned interface, this isn’t to say that starting afresh will fail. If done well, and for the right reasons, it can be quite the contrary.

At the end of the day, if there is a genuine need to start afresh, and the usability will be greatly improved in doing so, then sticking to possibly outdated and ineffective brand guidelines is not worth it for the sake of familiarity. To soften the blow in terms of changes (as we all know that users, and people in general, don’t always like change), a gradual approach of continuous improvement can be taken, whilst being sure to test on real users throughout the process.

So, what’s my preference?

I would go as far as to say that for a UX and UI designer, a preference towards creating guidelines from scratch may be the most common. It certainly would be my preference as it means you can create it exactly how you think is best, exactly in line with the needs of the product and users, whilst being sympathetic to the brand at large.

But, at the end of the day, part of being a designer is being flexible and open to working in whichever way is necessary for a given job. If I’m handed brand guidelines to work through a redesign, I’ll make the best of it, but if I’m lucky enough to be able to start from scratch, that’s a good day all around, both for me and most likely for the interface too.

In the past, I’ve been given no more than two hex codes to work with. Given the autonomy to flesh out all styles necessary for the project, I was able to create a thorough and cohesive set of styles and interface components that worked for the brand and platform, whilst ensuring their usability, legibility and accessibility. Beyond this, it also meant that the styles and wider design system were all documented within Figma, alongside the design files and prototypes, resulting in an easy and efficient workflow between design and engineering.

With that said, if you’re anything like me, you may find yourself itching to make changes to the brand and certain styles throughout the design process, but I do believe that sometimes working within restraints and relinquishing some control can make you a better designer. After all, any UX/UI designer with a good understanding of branding can create a beautiful set of styles from scratch, but taking something that has been handed to you and making that work for the brand, business and user, well that is a true skill.

Thanks to Tirza van Dijk, NordWood Themes and Giorgio Trovato for the photos on Unsplash ❤️ This post Browser London.

CSS Container Queries: Revolutionising Responsive Web Design

Browser — Tue, 23 Apr 2024 11:41:09 +0000

In the ever-evolving landscape of web development, staying abreast of the latest and most efficient coding practices is paramount, we discussed how responsive web design has evolved in our 2019 article ‘Should we still be selling Responsive Web Design‘.

Now among the plethora of CSS advancements, one topic back in 2021 ignited the interest of developers worldwide: CSS Container Queries. At the time, Robin Rendle at CSS Tricks wrote a nice introduction titled ‘Say Hello To CSS Container Queries‘. This innovative feature transformed how we approached responsive design, promising a level of flexibility and precision previously unattainable with traditional methods.

The dawn of a new era?

Historically, responsive web design has hinged on media queries that respond to changes in the viewport size, while media queries are of course effective, this approach has its limitations, particularly when dealing with complex components and layouts that require more nuanced adaptability. Whilst CSS Container Queries allowed developers to style elements based on the size of their parent container rather than the viewport, not necessarily a new era, but it made everything a touch more succinct.

Understanding container queries

The introduction of container queries marked a significant shift from the viewport-centric design philosophy. By focusing on the container, developers can create truly modular components that maintain their design integrity regardless of where they are placed on the page. This level of component-based design was of course a significant gain, especially in the era of web components and design systems. The Mozilla Developer Network (MDN) provides an authoritative overview of Container Queries, including syntax, use cases, and browser support information.

How do container queries work?

At its core, Container Queries leverage the @container rule, which applies styles based on the conditions met by a container’s size. For instance, a card component could be styled to display its content in a single-column layout when in a narrow container but switch to a multi-column layout in a wider container.

For a simple explanation, below is an example code snippet demonstrating how to use a CSS container query, as you can see it’s pretty simple. This example will show how you might style a component differently based on the width of its container. The goal is to create a card component that adapts its layout based on the container’s size. For this example, let’s assume we want our card to display its content in a single column when the container is less than 500px wide and switch to a two-column layout when the container is wider.

First, we define the container in our HTML:

<div class="container">
  <div class="card">
    <img src="image.jpg" alt="An interesting image">
    <div class="content">
      <h2>Title of the Card</h2>
      <p>This is some description text that goes inside the card. It's more detailed when the card is wider.</p>
    </div>
  </div>
</div>

Next, we apply CSS for the card, including the container query:

.container {
  /* Define the container as a container query container */
  container-type: inline-size;
}

.card {
  /* Initial single column layout */
  display: block;
}

.card img {
  max-width: 100%;
  height: auto;
}

.card .content {
  padding: 1rem;
}

@container (min-width: 500px) {
  .card {
    /* Two-column layout for wider containers */
    display: grid;
    grid-template-columns: 1fr 2fr;
    gap: 1rem;
  }

  .card img {
    /* Adjustments for the image in a two-column layout */
    max-width: none;
    width: 100%; /* Adjust to fill the column */
  }
}

In this example, the .container class is designated as a container query container by setting container-type: inline-size;. This tells the browser that styles inside container queries should be applied based on the inline size (typically width) of elements with this class.

The @container rule checks if the .container is at least 500px wide. If so, it changes the .card layout to a two-column grid layout. The image and text content inside the .card are automatically arranged into these columns, demonstrating a responsive design that adapts to the container’s size rather than the viewport size.

This approach allows for more modular and reusable component styles, making it easier to maintain a consistent look and feel across different parts of a web application, regardless of the surrounding layout.

For an in-depth look, the Mozilla Developer Network (MDN) provides a comprehensive overview of Container Queries which includes syntax, use cases, and browser support information should you need it.

The impact on responsive web design

In the real world, the introduction of container queries is more than just a technical update; it represents a paradigm shift in responsive design.

Ultimately responsive web design (RWD) is centered around ensuring that web pages function well on a variety of devices and window or screen sizes. Typically, it relies heavily on media queries that apply styles based on the viewport size. Here are a few ways it’s reshaped the landscape since it became popular back in 2021:

Enhanced Modularity: Components can now be designed in isolation, with their responsiveness encapsulated within. This leads to more reusable and scalable codebases.
Simplified Layouts: The complexity of managing responsive designs across various viewports is significantly reduced, as the focus shifts to the container level.
Improved Performance: By reducing the reliance on JavaScript for layout adjustments and minimizing the need for media query overrides, Container Queries can lead to more efficient and faster-loading web pages.

Of course, when integrating the concept of responsive web design with container queries, like in the example provided below, you gain the ability to create components that are not only responsive to the viewport but also adaptable to their container’s size. This dual approach enhances the adaptability and reusability of components across different contexts within the same webpage.

To illustrate how responsive web design might affect and work alongside the container query example, let’s extend the previous code to include viewport-based media queries. This will ensure our web page content is responsive not only to its container size but also to the overall viewport size, providing a more comprehensive responsive design.

Extending the Example with Viewport-Based Media Queries
We’ll add some media queries to adjust the overall layout and font sizes based on the viewport size, complementing our container query setup:

/* Base styles */
body {
  font-family: 'Arial', sans-serif;
  margin: 0;
  padding: 1rem;
}

.container {
  container-type: inline-size;
}

.card {
  display: block;
}

.card img {
  max-width: 100%;
  height: auto;
}

.card .content {
  padding: 1rem;
}

@container (min-width: 500px) {
  .card {
    display: grid;
    grid-template-columns: 1fr 2fr;
    gap: 1rem;
  }

  .card img {
    max-width: none;
    width: 100%;
  }
}

/* Responsive Web Design adjustments */
@media (max-width: 600px) {
  body {
    font-size: 14px;
  }

  .card .content {
    padding: 0.5rem;
  }
}

@media (min-width: 601px) and (max-width: 1200px) {
  body {
    font-size: 16px;
  }
}

@media (min-width: 1201px) {
  body {
    font-size: 18px;
  }

  .container {
    max-width: 800px;
    margin: 0 auto; /* Centering the container */
  }
}

In this extended example, we’ve added viewport-based media queries that adjust the body font size and the .card .content padding based on the viewport width. This ensures that the text is readable and the content is comfortably spaced on devices of all sizes, from small mobile phones to large desktop monitors.

The combination of container queries and viewport-based media queries allows for a highly flexible and responsive design. The container queries focus on the component’s responsiveness within its immediate context (the container), while the viewport-based media queries handle global page layout and typography adjustments based on the overall window size.

This dual approach leverages the strengths of both methods, providing fine-grained control over component layouts in different contexts and ensuring the page is optimized for readability and usability across all devices.

As a final note on this, Isaac Lee created a series of examples highlighting responsive container queries using Percy.io for visual regression testing. It serves as a good example of use with basic data. You can check out his Ember Container Query page, or check Isaac’s Github repo for reference and documentation.

The challenges and the considerations

Despite their potential, container queries introduce new considerations for developers, especially when it comes to implementation:

Browser Support: As with any new technology, browser support is gradual. Developers must consider fallbacks for unsupported environments.
Learning Curve: Adopting a container-centric approach requires a shift in mindset and potentially rethinking existing design patterns.
Performance Implications: While Container Queries can improve performance, misuse or overuse can lead to complexity and unintended consequences.

Looking ahead

As the web continues to evolve, so too do the tools at our disposal. CSS Container Queries are just the beginning of a new chapter in responsive design, offering a glimpse into a future where designs are more adaptable, efficient, and user-centric than ever before. The journey of exploring and mastering Container Queries will undoubtedly be filled with learning opportunities and creative challenges, but the potential rewards for developers and users alike are immense.

The post CSS Container Queries: Revolutionising Responsive Web Design appeared first on Browser London.

Navigating the Dynamics of an External Team Collaboration

Browser — Mon, 26 Feb 2024 17:28:35 +0000

As a frontend developer, the majority of my work revolves around JavaScript and TypeScript. However, recently I had the opportunity to collaborate with a backend team from another company that predominantly worked with Python. This collaboration presented its fair share of challenges, as described in our post titled SVG Gradients: Solving Curved Challenges, but it also provided invaluable insights and learnings.

From our recent post: SVG Gradients: Solving Curved Challenges

Here we share my experiences and lessons learned while working as part of an external team, highlighting the importance of effective communication and the power of mutual learning.

Communication Challenges
One of the initial hurdles we faced was communication. Our respective companies had adopted different meeting structures and communication tools, which initially seemed inconsequential. However, as we progressed, it became evident that the constant switching between email, Slack, Jira, and Microsoft Teams was causing important messages to get lost.

Recognising the need for streamlined communication, we decided to collaborate with the external development team and our project manager to simplify our processes. After thorough discussions, we made a couple of key changes:

We reduced the number of meetings to one daily standup on Microsoft Teams, providing a central platform for team updates.

We agreed to log all meeting notes in Jira, ensuring a centralised source of truth for technical requirements.
These adjustments significantly reduced interruptions and distractions, allowing us to focus more on our tasks and tickets.

Overcoming Technical Differences
Another significant challenge we encountered was the technical disparity between our frontend team’s use of TypeScript and the backend team’s reliance on Python. Building a type-safe API became more complex due to this divide.

To alleviate this challenge, I took the initiative to learn MongoDB, a popular non-relational database frequently used by the backend team. Given that MongoDB generates JSON, my transition from JavaScript to this database was relatively seamless. I was fortunate to have experienced backend developers at my disposal, who provided guidance and directed me to valuable online resources. These resources accelerated my learning process, saving considerable time.

Armed with a better understanding of MongoDB, I was able to actively contribute to the API design and development process. My knowledge of how MongoDB structures its data, particularly its practice of embedding documents, allowed me to create TypeScript interfaces and type definitions that aligned accurately with the backend requirements. This harmonisation resulted in fewer changes required for the API, leading to increased efficiency and satisfaction for the backend team.

From the post: 5 Ways to learn Mongo DB Starter Kit article
Embracing Cross-Company Collaboration

Working with a backend team from another company undoubtedly posed challenges, but it proved to be a remarkably rewarding journey. By embracing the opportunity to acquire new skills and align methodologies, we successfully bridged the gap between our teams. This collaboration demonstrates that, with
the right approach, cross-company partnerships can enhance productivity rather than hinder it.

Our commitment to effective communication, along with a shared willingness to learn from one another, brought us closer together and ultimately contributed to the project’s success.

In the ever-evolving landscape of software development, working with external teams provides valuable opportunities for growth and knowledge exchange. By embracing these experiences, we expand our horizons, deepen our skill sets, and forge meaningful connections that transcend organisational boundaries.

The post Navigating the Dynamics of an External Team Collaboration appeared first on Browser London.

SVG Gradients: Solving Curved Challenges

Browser — Wed, 21 Feb 2024 15:06:44 +0000

In the world of programming, seemingly straightforward tasks can unravel into complex challenges. Recently, we encountered one such challenge while attempting to transform a Figma design into code. The task at hand involved creating a radial dial with a linear gradient – a seemingly simple requirement that soon proved to be more intricate than expected.

In this post, we’ll delve into the world of SVG gradients and explore the solution we devised to tackle the challenges that arose, and argue why sometimes, being given complex engineering challenges like this can be highly rewarding.

Thrown a curveball

At first, it seemed simple. There must be a library we can use to create the dial and apply a linear gradient to it. How hard could it be?

And after a quick search of investigating libraries such as High Charts and FusionCharts we did find libraries capable of creating radial dials as well as generating linear gradients using SVG. However, the real complexity emerged when attempting to combine these two elements seamlessly. The obstacle lay in the nature of linear gradients defined within SVG. By default, linear gradients transition between colours along a straight line. When applied to the stroke of a circular path, the gradient’s direction remains linear, disregarding the curve of the circle.

Consequently, if we were to apply a linear gradient to a complete circular dial created with a single curve, the gradient would follow a straight path rather than the desired radial path along the dial. That wouldn’t achieve the curved gradient that we were looking for – so it was back to the drawing board.

Breaking up the problem
Instead, to achieve the effect of a smoothly transitioning gradient encircling the radial dial, we realised we needed to break the dial into multiple sections and apply distinct gradients to each section.

In our example, we divided the dial into four sections, each assigned its own linear gradient. By thoughtfully selecting the colours for the gradient stops, we were able to create a continuous gradient appearance around the dial.

Here, we start to see how we can construct a radial dial in SVG. The “d” attribute defines a path to be drawn. In this case, it’s specifying the path for the first quarter of our radial dial

The ‘M’ stands for “Move To” and sets the initial point of the path at the coordinates (150,10). The ‘a’ command creates an elliptical arc. This arc command has several parameters. The first two parameters, ‘120 120’, set the x and y radius of the ellipse used to draw the arc. The ‘0 0 1’ defines the x-axis rotation (which is zero), large-arc-flag and sweep-flag. The final ‘103.9230 60’ sets the end point of the path, which completes our arc. We then apply the gradient with the stroke attribute on the path.

This process is repeated for each quarter of the dial. Each quarter gets its own path and its own gradient. This gives the effect of a single, smoothly transitioning gradient circling around the dial.

Dynamic Gradient Filling

To dynamically fill the gradient along the dial, we leveraged the stroke-dashoffset and stroke-dasharray properties of the SVG path. This technique is commonly employed when creating radial dials. CSS tricks has an in depth write up on the approach: SVG line animation works.

By setting the stroke-dasharray equal to the length of the path, we established a pattern of dashes and gaps resembling a dotted line encircling the circle. The stroke-dashoffset property determined the starting point of the dash pattern, effectively animating the stroke’s movement. By animating the stroke-dashoffset from the start of the path to the length of the path, the dash appeared to “travel” around the circle.

Embracing Complexity (Sometimes)

While complex designs can translate into difficult technical challenges, they also serve as opportunities for programmers to hone their problem-solving skills. This is an integral part of what keeps programming interesting, at least for me.

The complexities we face in programming often reflect the complexity of the designs we’re working from. Our Figma design, featuring a radial dial with a linear gradient, serves as a great example of how a visually appealing design element can introduce significant technical challenges.

It’s easy as programmers to instinctively try and work with designers to come up with a compromise in terms of design spec. In fact that’s often the right approach. But sometimes, if you want your designs to stand out from the crowd, you’ll need to instead push past your comfort zone and come up with creative ways of solving your problems.

Another way to put this is, while design complexities can translate into technical challenges, they also serve as opportunities for programmers to hone their most valuable skill, their ability to problem-solve.

The post SVG Gradients: Solving Curved Challenges. First appeared on Browser London.

Lean Product Design: A Playbook

Browser — Fri, 23 Jun 2023 16:24:57 +0000

Creating a new product is an exciting process. You’ve dreamed up a killer idea, drafted some sketches and maybe even started to think about how you’d make money out of this world beating idea.

But hold up. Before jumping in and hiring a development team, or asking IT to build it out, take a step back and make sure that you’ve thought it through, recognised your assumptions and proved that they are correct. Are customers really going to want this?

If the answer is no, the best time to find this out is now – the alternative is to find out after forking out a lot of money on coding an app that nobody wants. Fortunately, we can find this out with fast, cheap experiments, rather than paying for months of expensive development time.

That’s where discovery comes in. It’s a chance to explore our customers and their problems in-depth. Here we find out their ‘jobs to be done’, and run experiments to see if customers really will react to your product in the way you expect (spoiler alert: they won’t).

This guide gives you a heap of tactics that you can use to understand customer problems and test buying intent. This phase de-risks the whole venture since nobody; your investors, your board of Directors, your customers, your build partner, want to build something that nobody will use.

—

Throughout this guide I’ll be using a fictional product idea to give context to the concepts that I outline. I’ve used an example that is at a similar stage to the products that people approach us with at Browser: an idea for a new digital product where a little research has been done and a rough idea of the market and value proposition is known.

The steps we’ll run through in this guide are as follows:

Recognise your assumptions
Test your assumptions
Learn and move forward
Develop a value proposition
Run more experiments
Define a strategy and roadmap Let’s jump in.

Setting the scene

Our product

The example product that I’m going to use is an idea for a product that helps busy people find personal assistants. As a working title, we’ll call it PA Finder.

That’s as much as we’ll define for the time being. At this stage, we don’t want to confine ourselves to a particular medium (an app, a physical product, a service). All we need is an idea for a problem and the kind of people that we believe are affected by it. Later, we’ll work out what the solution actually is.

So let’s imagine that we’ve already done a bit of research: we’ve spoken to some contacts who use a Personal Assistant, looked at existing competitors and have even lined up a few beta users who are keen to try out the first version of our product. It might sound like we’re ready to start designing and coding our product. After all, fail fast, right?

It’s tempting to jump straight into detailed designs straight away – don’t.

Staying in the problem space

Well, before we get carried away, Dan Olsen (author of the Lean Product Playbook) has something to say about this. He stresses that when creating a new product or feature, teams explore the ‘problem’ space rigorously, before moving to thinking about solutions. This helps us focus on benefits, not features, and thus on the value that we are delivering to the customer, rather than measuring value based on the features that we are delivering.

Before thinking about the top of the pyramid, we need to make sure we’re right about the bottom.

Since a solution is only valuable if we have first defined the problem/need correctly, for a large part of our discovery phase we want to stay in the problem space. The more we know about our customer’s problems, the more we de-risk all the work that comes with developing a solution.

This doesn’t mean that we’re moving slowly though, or that we’re wasting time working on theories and documentation. As this guide will demonstrate, we’ll be carrying out real life experiments to test customer reaction to the problems we assume they have. Some of this is familiar tools like interviews and surveys, and we’ll also use techniques like dummy landing pages and ad campaigns to test buying intent.

With this in mind, the focus of this guide will be the work done in taking a product back to the problem space, interrogating all the assumptions that we have made about our customers, market and our ability, before emerging again into the solution space with a bunch of evidence to back up what we plan to build.

That brings us neatly to the next chapter, Recognise your assumptions.

Step 1. Recognise your assumptions

You might have already jumped ahead and already started sketching out how your new product might look and work. That might come in handy later, but I strongly advise you forget about that for now and work through this step which focuses problems and solutions from a customer point of view.

Before you start dreaming up solutions, putting pen to paper and hiring a team of coders, you need to understand the pains, gains and customer jobs of your product. At this stage we will search out the assumptions we are making, phrase them as hypotheses and then single out the ones that will make or break our business if they are incorrect.

If you spend the time to do this, you’ll be on your way to creating a testable value proposition that will become the north star for your design, development and marketing. A proven truth that everyone can work towards. If you don’t, you are in danger of building features on a hunch that they are a good idea – a recipe for wasted time and money and a team that is pulling in different directions.

Customer jobs, pains and gains

Our starting point then, is with our customers.

We’ll map out our customers’ pains, gains and customer jobs based on what we know so far. Depending on the amount of research that has already been carried out beforehand, there might be an element of guessing at this stage, but the idea is that we get everything that we think we know about our customers out in the open.

In our workshops, we use the below chart to map this out (inspired by Strategyzer). We’ve applied our example product, Personal Assistant Finder, to this test to give you an idea of how it might look.

Let’s break these terms down.

Customer jobs: What are the tasks that our customers need to do?

Pains: What are their pain points they encounter when carrying out these jobs?

Gains: What opportunities exist for them to make gains on their jobs?

Once we’ve mapped this out we have a clear view of what we think our customer wants to achieve, the problems they have and the opportunities to improve. This might be based on some prior research, but it’s also okay if there is an element of guessing here – we’ll be testing it all in a moment.

Assumption Mapping

Our next step is all about acknowledging how little we know. Whilst guessing is fine at this stage, it is important that we acknowledge what is a guess, and what is backed up by solid evidence. Assumption mapping helps us do this.

Here we’ll plot what we think we know onto a grid and map our post-its by evidence vs. business importance. Below you can see how we have done this with our Personal Assistant product: we’ve taken post-its that we’ve identified in the pains, gains and jobs exercise, and applied them to our Assumptions Map to understand which of these are risky assumptions.

Here you can see a group of post-its in the top right hand quadrant. As the label suggests, these are our high risk items – we haven’t proved them and the product won’t work if they are incorrect. These are the things that we’ll test first.

When assessing whether we have evidence, it’s easy to overstate the evidence that we have. Anecdotal evidence, competitor research or interviews are a good start, but they aren’t strong evidence and shouldn’t be treated as such.

Strong evidence, such as users actually buying a version of our product, or at least signalling intent by signing up to a wait list, are indicators that we can really take seriously. They do take more investment in time however, so we’ll be working our way up to these kinds of experiments in the later steps.

Once we’ve mapped this out, we move to the next stage of our process – Test your assumptions.

Step 2. Test your assumptions

Once we’ve mapped out what we think we know about our customers, it’s time to run some tests.

In the early stages of our process, we’ll use exploratory methods to prove or disprove our hypotheses. These tests focus on finding customer problems, rather than jumping to solutions. They will be one or a number of:

Customer interviews (with a focus on jobs to be done)
Expert interviews (with stakeholders, subject matter experts, frontline staff)
Analysing search trends (are people searching about this problem?)
Shadowing (observing how people act and what problems they face)
Reading discussion forums (are people talking about this problem?)
Surveys (how do people respond when we ask about this problem area?)
Watching customers using existing products (what issues and limitations do they run into?)

Where possible, the whole team should be involved in this process. For us that typically means a designer, a tech lead, a product lead and one or two people from your team. Making sure that all we include a tech person in this early research so that they can see and hear the real world problems that our product will tackle. This helps them make better decisions when it comes to eventually building the product, and also they’ll have some great ideas when it comes to dreaming up solutions.

In-person interviews are a great place to begin testing your assumptions.

Planning experiments using test cards

A typical test card will look like the below. It shows what we are testing, how we will test it, what we will measure and what success looks like. We will often create multiple tests for each hypothesis, to make sure that these key assumptions are backed up with maximum evidence. This is an example from a hypothetical quiz app to find a personal assistant.

The card contains 4 key points to keep us on track:

Hypothesis

Taken from our assumptions map, this is the thing that we want more evidence to be sure that it is true. We’ll tackle our ‘Unknown’ and ‘Critical’ hypotheses as a priority.

Test – Describes what the test will consist of and the actions that we will take during it.

Metric – Documents what we will be measuring during the test.

Criteria – Tells us what the threshold for a positive result is. We define this before the test begins.

We’ll run through what we do with the results of these cards in the next section, Learn and move forward.

Step 3. Learn and move forward

Great! By this point we have identified our most risky assumptions, ran some experiments on them and collected a bunch of data about them that will help us decide if they are valid or not.

But it’s not enough to just conduct experiments, jot down some findings and pat ourselves on the back. We need to take action from each and every one of them if we are going to squeeze all the value we can from them.

A good way to document them is by splitting the results into a card that contains four sections: ‘We believed that’, ‘We observed’, ‘From that we learned that’, ‘Therefore we will’. Using our running example of our PA Finder, this would look like the following:

Whilst in the above example we’ve decided that the next course of action is to run some further experiments, it’s worth noting that we could take a few different routes:

If the experiment was deemed to indicate that the hypothesis was true, we might decide to move forward with another, more time consuming but more reliable, experiment (such as a high fidelity prototype or a landing page)
If the experiment was deemed inconclusive, we might repeat it, or look to other experiments that we have run or will run to see if they provide evidence either way.
If the experiment was deemed to indicate that the hypothesis was incorrect and the experiments that we have run also point to this, we’ll accept this finding and rework our value proposition and/or business model to reflect this.

Advantages of documenting our findings in this way

Keeping track of what we’ve learnt – we’ll be doing lots of experiments and we will want to refer back to them. These cards are easy to find and reference later.
Structuring the way we think about results. The above approach makes sure that we’ve considered what we set out to learn, what we did learn and what we will do next.
Getting everyone’s buy-in. The team will need to agree on these points, so it’s a great way of keeping everyone aligned to the evidence that we are gathering and the conclusions that we are drawing.
Fast documentation – we don’t need to write a full on document, just jot down the key findings and move on.

Step 4. Develop a value proposition

By this stage we’ve assessed what we thought we knew about our customers, highlighted the things that we don’t have evidence of and will cause us serious issues if they are wrong, and methodically gone about testing them through experiments such as customer interviews, search volumes, competitor research and more.

We should now be confident enough to start moving into the solution space by creating a value proposition based on this evidence. From this, we’ll then map out our business model before picking this apart for more risky assumptions.

Creating a value proposition

We’ll map out our gain creators, pain relievers and finally the products and services that we could offer. If we’re on to a winning value proposition, these should match up nicely to our user pains, gains and jobs to be done. If they fit together well, in theory, we’re looking at a good product market fit.

Once we’re happy with our value proposition, we’ll start to map out our business model. At this point we should still be very aware that we’re still dealing with a lot of assumptions. That’s okay, We’re going to do some more assumption mapping at the end of this step.

The Business Model Canvas looks like this:

Original concept: https://www.strategyzer.com/canvas

On it, we map out the core parts of our proposed business model. These are sorted into the following groups:

Desirability (do people need our product?)

Key propositions
Customers relationships
Channels
Customer segments

Feasibility (can we build our product?)

Key partners
Key activities
Key resources

Validity (is our product commercially viable?)

Cost structure
Revenue streams

The Business Model Canvas is a powerful way to find any gaps in the business model that have been overlooked. It’s also a strong tool to get the whole team aligned about what it is that we’re offering our customers, how we’ll deliver it and where the money is going to come from.

Once this is done, we’ll move on to assumption mapping again. We’ll take everything that makes up our business model and interrogate it to work out what is crucial and still has little evidence backing it up.

Step 5. Run more experiments

Once we’ve mapped the assumptions made in our business plan, we’re ready to run even more experiments. Now that we’ve already tested some of the assumptions that we’ve had around our users, these experiments will be more complex and take longer to produce. They might be one of the following:

A simple landing page – creating a marketing page, driving traffic to it and measuring the conversion rate
A clickable prototype – creating a clickable prototype, giving test users a scenario to work through and observing how they get on
A low-code product – creating a working product, but using tools like Webflow or Bubble to produce something that simulates your product idea
A single feature MVP – creating a coded product, but focusing on a single feature or assumption that we’d like to test

A clickable prototype we created for Seven Seas.

In many instances, a design sprint is a good way to approach this part of the product development process. It is a 4 or 5 day period where we define what we want to test, come up with a range of imaginative solutions, create a high fidelity, clickable prototype (of a landing page, or key part of the product itself) and test it out with a small number of customers. It is a great way of making decisions quickly and rapidly testing ideas.

Whatever approach is taken, what’s important at this stage is that we test the most risky and important assumptions on our business canvas first, prioritising those that fall in the ‘desirable’ category over anything else. After all, if nobody is willing to buy our product because we’ve haven’t solved their problems in a compelling way, we need to find that out and make a pivot before we go any further.

As in steps 2 and 3, we’ll create test cards to document exactly what we want to test here, and what success looks like. For example, if we build a landing page, we might want to test for buying intent and consider 50 enquiries in 1 week a success.

Step 6. Define a strategy and roadmap

From all of the work that we have done in the previous steps, we are now ready to define a product strategy. A good product strategy should describe what your product hopes to accomplish and how you plan to do it. It will be a document that any team member can look at and understand what the big picture is and make decisions, like what features to build, based on it.

Remember that business model canvas that we produced in step 4? Well, that’s a great start for our product strategy. It documents how our product will be outwardly desirable, technically viable and financially feasible – three aspects a good product strategy should cover.

To keep us from getting bogged down in documentation, we’ll simply update our canvas based on what we’ve learned during our previous experiments and use it as our product strategy. If needed, we can document this in a deck so that it’s presentable to stakeholders and the delivery team, to make sure that everyone is on the same page.

The product roadmap

Once our strategy and objectives are agreed on, we’re ready to start planning our next experiments. All that’s left is to define what we’re going to focus on first. This is where a roadmap can help.

We can create a roadmap quickly from what we’ve mapped on our business model canvas and assumptions grid. Our roadmap is simply a document that ranks hypotheses in priority order and shows what we’re going to investigate and deliver next.

A Next Now Later roadmap is an excellent way to do this. It focuses the team and stakeholders on what is the most important thing to do right now and it is designed to resist the situation where the roadmap simply becomes a feature list that the delivery team works from. Instead, we frame our product as a series of hypotheses that need to be investigated, and add detail to them as they move to the ‘Now’ column.

Taking our PA Finder app as an example, our ‘Now’ column might have something like: ‘Business execs will trust using a PA found online’. We might also attach OKRs to this in order to measure effectiveness, but that’s for another post.

Adopting an experimental mindset

By now, we’re sure who our customer is, we have clear evidence what problems they have and what the opportunities exist and we’ve tested potential solutions with increasing certainty as to whether they are desirable for customers. We’ve then distilled all of this down into a product strategy and high level roadmap to show how we’ll realise it.

This process doesn’t need to take months and it shouldn’t – all of the experiments described above can be done quickly and cheaply. As a rough guide, in 6 weeks you should be in a place where you are ready to start building your first iteration in earnest.

The build phase should continue this spirit of experientation: it should be a fast (again, 6 weeks max) experiment, testing the most important hypotheses in our roadmap. The aim here is to get working software into our customers’ hands quickly, so we can continue to learn as we build the next iteration.

Continuous Discovery

Although this guide has been presented in a linear way, this is a process that should be repeated constantly if it is to have any value. As you develop your product, you should continue to conduct experiments, big and small, in order to continue to learn about what customers value and what they don’t.

You’ll find that parts of the product strategy and roadmap were wrong and therefore these documents should be constantly reviewed and updated as you learn. We call this ‘Continuous Discovery’ and you can learn more about it in Teresa Torres’ book, Continuous Discovery Habits.

The post Lean Product Design: A Playbook appeared first on Browser London.

Yes, typography can have a huge impact on UX

Browser — Mon, 17 Apr 2023 16:21:27 +0000

I find it fascinating how design can impact user experience. Adjusting interface elements even a tiny amount can have an immediate and measurable effect on how people use and feel about a digital product, website or app. Typography, in particular, has been shown to have a significant influence on user perception and engagement. In recent years, there has been a shift towards using lowercase typefaces in brand names and headlines, and this trend is supported by research that suggests that it can create a softer and more approachable aesthetic, ultimately leading to a more welcoming user experience that promotes engagement.

The recent relaunch of the Rolex website on March 27th serves as an excellent example of how a simple change in typography can drastically alter the overall look and feel of a website. The previous website design utilised ‘Helvetica Now’ in full capitals for headline statements, which gave off a bold and powerful impression. However, the redesigned website uses upper and lower-case headline statements, which creates a more refined and approachable aesthetic.

This change in typeface also aligns with a broader trend in design towards using negative space to create a more modern look. By incorporating more space around elements (thanks in part to the now smaller headlines), the new Rolex website looks more streamlined and organised, making it easier for users to navigate. The overall result is a website that feels more modern and welcoming, which despite the price point of their products I believe is a strategic move by the brand to appeal to a younger audience.

The all-caps approach of the previous site design

The new, softer, lowercase approach, introduced in March 2023

Of course, this is not the first time that typography has been used to create a specific look and feel. One of the most notable graphic designers to utilise typography in this way was Saul Bass. Bass was famous for his work on title sequences for films such as “Psycho” and “Anatomy of a Murder,” where he used typography to convey mood and tone. His bold and graphic typefaces set the stage for the films, drawing viewers in before the action even began.

Another influential designer who has used typography in unconventional ways is David Carson. Carson was known for his experimental designs, which often incorporated distorted and illegible typefaces. His work challenged traditional design conventions, and his designs were often controversial. However, they also served as a reminder that design is not just about aesthetics but also about communicating a message.

It is thought by cognitive scientists and typographers alike, that lower-case text is more legible than upper-case as the human eye can follow the contours and word shapes far easier. Yet lower-case letters are, on average, smaller in height and width than upper-case characters, which suggests an upper-case advantage. Studies have shown that the use of full uppercase typefaces can create a sense of authority, and even aggression or hostility, which can be off-putting to users – just think about those times you’ve had to apologise for sending a text message in FULL CAPS by mistake.

By using a lowercase typeface for headlines, designers can also create more negative space, making a design web or print page feel more modern and approachable, impacting user perception and engagement. By using a lowercase typeface, designers can create a more conversational tone that can make users feel more comfortable.

In conclusion, the recent relaunch of the Rolex website is just one example of how a simple change in typography can drastically alter the user experience. I believe that the use of lowercase typefaces is a trend that is here to stay, not only does it create a softer and more modern look and feel, but it also aligns with broader trends in design towards using negative space and simplicity. As designers, it is our responsibility to consider every detail in design and how it can impact the overall message that we are trying to convey.

The post Yes, typography can have a huge impact on UX appeared first on Browser London.

Continuous improvement beats big ‘tada’ releases

Browser — Fri, 10 Feb 2023 09:42:57 +0000

A little thought experiment for you:

Let’s imagine a client is building a digital product and wants to see what approach works best. They have two teams at their disposal and they will brief them to both build the same product, but with a variation on how they must complete it. Both teams possess the same resources, skill sets, abilities and knowledge, and both have one year to produce the best results. They will also have the same marketing channels and methods applied.

Team one, let’s call them Red Team.

They have been told they want a big launch in eight months’ time, followed by bi-monthly deployments. The product is to be kept under wraps until the big release. Testing is to be conducted totally in-house, alongside the client stakeholder.

The Blue team, are told to use continuous improvement principles (more on this later) and is expected to launch an MVP (Minimal Viable Product) build asap, followed by regular deployments. They are free to test with any users, internally or externally to the business.

Who would you bet produces the best results after 1 year?

My money would be firmly placed on the blue team.

Why? Because I have seen examples from other disciplines that show small incremental change yields better results. I’ve also seen (and been a part of) other agencies that have taken a long time to build a product, only to learn the hard way that they were on the wrong track. It’s painful (and expensive) only to find out that your market fit was wrong, or that users don’t understand how to use the product after you’ve laboured over it for twelve months.

Continuous Improvement in Sport

Probably one of the most high-profile examples I can think of is the ‘Marginal Gains’ principle the British Cycling team used, with excellent results, under Dave Brailsford.

“The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improved it by 1%, you will get a significant increase when you put them all together”

Dave Brailsford, BBC interview, 2012

In the world of Olympic sport and small margins, every aspect becomes important, and Dave Brailsford and the cycling team underwent a systematic approach to find marginal gains.

Everything from looking at how the cyclists washed their hands – because this meant less illness – to asking riders to wear electrically heated over shorts to maintain ideal muscle temperature while riding and using biofeedback sensors to monitor how each athlete responded to a particular workout.

Even the smallest things they spent considerable time on. They tried various types of massage gels to see which one led to the fastest muscle recovery. They determined the type of pillow and mattress that led to the best night’s sleep for each rider. They painted the inside of the team truck white, which helped them spot little bits of dust that would normally slip by unnoticed but could degrade the performance of the finely tuned bikes. And so on, constantly striving to improve performance, even by the slightest of margins. Small gains stack together to make a big difference.

Whilst not entirely the same principle as continuous improvement (i.e. continuous improvement doesn’t necessarily delve into consultants teaching developers how to wash their hands), the overall theme is the same. Small incremental changes to create better results, instead of one giant effort to meet a goal (which was the previous/standard Olympic approach).

The Spaghetti Marshmallow Challenge

Ever done this one? It’s great fun!

The rules are easy; in 18 minutes, each team can use 20 sticks of spaghetti, one yard of sellotape, one yard of string, and one marshmallow – to build the tallest structure with the marshmallow on the top.

If you’ve ever done this or witnessed it, you’ll soon learn that it requires essential skills primary students naturally have, and business school students have forgotten. It teaches valuable lessons on creativity and innovation.

And more importantly (for this blog post at least), It highlights how you have to fail fast and make small continuous improvements in order to win. Those who write a plan, spend ages following that plan and go for the ‘tada’ moment will likely lose this task.

Usually, continuous improvements, marginal gains or just the practice of failing and learning quickly trump ‘tada’ moments. And this is because you remove the element of surprise.

Surprise in the software world is not normally a good thing. Quite the opposite, it means we don’t know how users will react to the product or use a feature, or how the platform will work (especially under pressure). When you build something in isolation over a long period of time, the risk that a bad decision has been made grows over time, and you don’t realise it (or can’t) until users or the data points it out to you.

The red team will learn this and it means the risk factor for them is higher.

Continuous improvement principles or CIP often include the following principles:

Improvements are based on many small changes rather than the radical changes that might arise from research and development
Small improvements are less likely to require major capital investment than major process changes
The ideas come from the talents of the existing workforce, as opposed to using research, consultants or equipment – any of which could be very expensive
All employees should continually be seeking ways to improve their own performance

So for these reasons, I’d bet on the Blue team, and it’s why at Browser we are constantly looking at how we can make improvements, be it to our tooling, technology choices, implementation practices, or deployment methods. You name it, we know that whatever we are doing today can be improved, even if only by 1%.

And yes btw, our devs do wash their hands.

Have I convinced you?

The post Continuous improvement beats big ‘tada’ releases appeared first on Browser London.

Five digital workplace themes for 2023

Browser — Thu, 19 Jan 2023 14:48:31 +0000

It’s that time of year when blogs like this one start to make predictions for the coming year. In fact, probably the safest prediction you can make is that lots of predictions posts are about to appear! But the end of the year is also a good time to think about the wider trends in play, especially as many teams are planning out their activities and considering their priorities for the coming months.

Looking back, 2022 was a busy year. Many employees are still working remotely for the majority of their week, so the digital workplace is their main window into their team and the wider organisation. Companies are increasingly busy trying to support hybrid work and also craft a more coherent and consistent user experience. And 2023 is potentially going to be even busier.

Let’s look at six themes that we expect to see shape the digital workplace space during 2023.

1. The Power Platform continues to democratise automation

Streamlining processes and driving efficiency is an objective for almost every business. Implementing automation at scale across the digital workplace to eliminate the wasted time and pain of repetitive tasks is a big step towards achieving this objective.

Up to a couple of years ago, many organisations felt that automation was a goal on the distant horizon. However, Microsoft’s Power Platform has shown the potential of making easy-to-use automation tools available throughout an organisation.

Empowering users to drive this type of ‘organic digital transformation‘ themselves brings automation at scale to every corner of an enterprise, and during 2023 we expect Power Platform to continue to go from strength to strength. The low code / no code interfaces of Power Automate (the main workflow engine) mean it’s accessible who are not IT professionals, while the ever-growing libraries of connectors and workflow templates within Power Automate make it even easier to implement automation. It could even be said that 2023 could be the year the Power Platform democratises automation.

2. A focus on equitable experiences as hybrid work dominates

One of the key digital workplace themes of 2022 has been the support for hybrid working and how teams can use solutions to meet the challenges around new ways of working. Hybrid working looks set to continue to be a dominant working pattern in 2023, with many of us both working remotely as well as in the office.

As hybrid working starts to become embedded as the norm, we can expect there to be a focus on how we can make the experience of working remotely and inside the office equitable so employees can truly work from anywhere. For example, hybrid meetings have always been challenging in terms of providing the same experience for those in the room and those elsewhere. Subsequently, solutions are evolving for the better, for example with more sophisticated AV equipment and the evolution of features within collaboration platforms like Teams. Other solutions are also appearing that will support hybrid work, for example with the launch of Microsoft Places that helps with a range of tasks such as hybrid scheduling.

I think supporting equitable experiences across hybrid work will be on the agenda for many digital workplace teams in 2023 and will relate to a range of processes and activities, from employee onboarding to conducting meetings and even driving employee engagement.

3. Digital workplace innovation outpaces organisational roadmaps and launch plans

Over the past few years there has been a lot of innovation in digital workplace tools, with enhancements, new features, more connectors, the rise of low code / no code elements and more. This is great news for hybrid or remote teams, but at the same time, it can be exhausting; it feels like it is getting harder for those implementing tools and for users to keep up.

2023 is going to be yet another year when digital workplace innovation and the evolution of tools and features continue to outpace technology roadmaps and launch plans. Employees and support functions are used to change as a constant, but there are only so many tools that can be launched in a given year.

I think this app or platform overload is going to become more explicit during 2023 as teams struggle to keep on integrating new tools and users lose interest in yet another new app to get to grips with. I’m not sure there’s a straightforward answer to this trend, but it will be interesting to see the change and governance tactics that organisations adopt to cope with the sheer pace of digital workplace evolution.

4. Business intelligence and advanced analytics are back on the menu

A consequence of the digital workplace is the generation of huge amounts of data about how we work, collaborate and consume information. There are exciting opportunities to use and analyse this data to generate insights that can help improve productivity, well-being and collaboration. However, in practice, few digital workplace teams are actually leveraging this data.

In 2023 we expect business intelligence and advanced analytics to move up the corporate agenda, as more teams start to use the data that is produced by platforms like Microsoft 365 and Google Workspace. This will be helped by the evolution of services like Microsoft Viva Insights which surfaces productivity and wellbeing analytics from across Microsoft 365, as well as a data visualization platform like Power BI which allows for the development of rich dashboards. However, data protection and privacy are factors that must be considered when advancing analytics generated by employee activity.

5. Employee experience goes mainstream as a dynamic in the digital workplace

Employee experience is a concept that has been around for a while, advocating a more holistic and joined-up approach to all the touchpoints an employee has with their employer. Starting with HR, but now increasingly used in the digital workplace and IT space too. We’re certainly seeing it being mentioned by clients and prospects when talking about the aims of their digital workplace, intranet project or Microsoft 365 roll-out.

While it’s easy to dismiss it as another buzzword, actually the concept of “employee experience” is fundamental to the digital workplace. The technology that employees experience every day makes a difference, especially now that more people are working remotely; in fact, good technology and platforms like Microsoft 365 can even help keep your employees happy. Solutions have to be user-centric to succeed, and in 2023 we’re likely to see employee experience continue to grow as a dynamic in the digital workplace. And that’s a good thing.

Conclusion

2023 is going to be another important year for the digital workplace with a focus on supporting hybrid work and improving employee experience. Microsoft 365 and its constituent tools will play a major role, through some of the tools and areas that we’ve highlighted in these themes. Change management will also be important in ensuring employees get the best out of the tools at their fingertips.

*Images in this article were generated by Midjourney AI.

The post Five digital workplace themes for 2023 appeared first on Browser London.

Why does Twitter need so many developers?

Browser — Tue, 22 Nov 2022 15:58:20 +0000

Much has been made lately of the impact of Elon Musk firing vast swathes of staff after his takeover of Twitter. In particular one discussion that keeps presenting itself is the question of why Twitter has many thousands of engineers — and in particular, a comparison to WhatsApp is often made.

First, some numbers:

On average, there are around 800 million new Tweets per day.
WhatsApp handles around 100 billion messages per day.

Circa 2014, before being bought by Facebook, WhatsApp allegedly only had 55 employees. The repeated question is that If WhatsApp can scale with so few employees, why does Twitter need so many?

To best explore this, let’s go on a journey. Your name is Elmo Mask, and you just bought WhatsApp for $44, how do we change WhatsApp so that it works like Twitter? We’ll build TwitsApp.

Busy chats

First of all, WhatsApp sets a limit of 512 people in a single group. This won’t do, part of Twitter’s unique appeal is the reach and amplification that can be given to a message — so we need to change this. All users are now in one chat group. All 400 million of them.

Now each of our users has to contend with a fire hose of content that’s constantly updated and can never be seen in its entirety. The only way you can use TwitsApp is to keep up with the flow, and the only way to do that is to be online 100% of the time.

Can you imagine what that would be like as a user? Just a constant high-speed stream of messages, everybody seeing the same thing. There would be no way to amplify a single message it will flick past everybody’s screen in a nanosecond.

Now I’m drowning

No, we need some way now to work out what each user gets to see, and the only way to make TwitsApp appealing is if each user sees what’s relevant to them and the people they’re interested in. We need to let users indicate who they are most interested in seeing content from, perhaps based on follows. That’s not just a case of bringing back groups, because we also need a way for TwitsApp to mix in new content based on the sort of content you’ve already shown interest in. How else are users going to find new people to follow!

This needs to be computed for every single one of our 400 million users. That’s hard enough without even thinking about the 6,000 new messages per second that need evaluating, assigning to interested users and then mixing into their home screens.

So let’s assume we have “messages from people you follow” and “messages on subjects similar to the ones you follow”, and we found a clever algorithm to efficiently compute what each of our 400 million users should see. What’s next? Do you want to see content based on who people you follow are replying to? Retweets?

This all needs to happen in a few seconds for every message.

Perhaps we need a service that will show a real-time list of trending subjects — so we need to identify those subjects and list the most popular ones… repeatedly. Perhaps we want to show the messages that are relevant in your region or areas of interest.

What about storage? WhatsApp doesn’t store users’ messages, they only ever live on the recipient’s phone. TwitsApp will need to be able to show you the history of messages from any given user, quickly. We’ll need a lot of storage.

We’re going to need some help here.

Who’s paying for this?

Sir, I’ve had the bill from the hosting provider, we need a way to monetise all of this so that we can pay for all the sheer compute power, storage, and bandwidth we’ve used up so far, let alone all the smart people to built and run it. We’re going to do that using adverts, so we need to mix those into our timeline, but we have a few problems before we even get to that.

The first step is that we need to get adverts into the system. We’ll need some tools to allow advertisers to create and manage their adverts. A few small-time advertisers probably won’t cut it though, we need the big ad brokers involved here — so we’re going to need a whole bunch of ad salespeople.

Nobody is going to buy our ad space unless we can not only target specific demographics, but also prove that the adverts are effective. We need analytics tools to demonstrate this to our customers because remember, the advertiser is the customer, and the users are the product. Oh, and all these systems will need beautiful UX design, too.

Keeping the community happy

TweetsApp is growing rapidly, but there’s a problem. Some of these new users are… disruptive!

We need a way to deal with that so that our advertisers aren’t associated with “spam” and “fake news”. We need a team to moderate user-generated content — and that team needs tools.

This team should probably also look into some of the targeted abuse and bullying we’re starting to see. Beyond simple compassion and ethics, we could get sued or lose ad revenue if we’re seen to condone or not take action on this.

Do we want some system to confirm to users that the person claiming to be the politician really is the politician?

Tip of the iceberg

All this is the tip of the iceberg though because we need to do this on a global scale, in different languages, different cultures, and for people with different accessibility needs. TwitsApp needs to grow in developing markets to find new users, so it needs to be just as reliable and enjoyable a user experience on a phone with a poor data signal as it is for somebody with gigabit broadband.

We need to worry about data hoarding governments demanding access to our user data, and we need to ensure that data is secure to protect our users. Does our mobile app work well in all markets, where different networks and devices are commonly used?

This is just the beginning of why Twitter needs a bigger team than an app like WhatsApp, despite handling far fewer messages and interactions per day. The reality is that each of these points has in turn its own smorgasbord of considerations, trade-offs, and issues.

All these people will need HR, Payroll, and a team to onboard and train employees.

And now my head hurts.

James first posted this article to Medium under the title Why does Twitter need so many developers?.

Should we still be using ‘Agile’ as a selling point? Aren’t we all Agile now?

Browser — Mon, 14 Nov 2022 10:20:46 +0000

At Browser Group we use Agile development methodologies in our projects. But you know that already, right? It’s not particularly unique as all our peer agencies are also Agile. In fact, Agile is so ubiquitous it’s hard to argue that it’s a selling point. I mean, aren’t we all Agile now?

The answer to that last question is yes and no, or “yes, but”, or a yes with a pretty hefty list of caveats. Agile has become the dominant development paradigm and its influence has become widespread, but its application is certainly not as consistent as it should be. Outside software development projects, Agile is still embryonic, meaning it can still feel somewhat alien to our business stakeholders and user groups.

From methodology to mindset

Over the past few years, Agile has become more than a methodology to deliver software development projects. It’s arguably now a culture and philosophy that has influenced wider organisational project management and even some team structures beyond IT. It’s a mindset, as much as it is a set of techniques.

At the same time, there is also an increase in general business thinking about the power of more agile and iterative approaches to business, as a source of innovation, competitive advantage and greater responsiveness to customers. Agility and speed to market give you the edge, and a better ability to navigate the challenges of a pretty volatile world. McKinsey even wrote about three main outcomes of “agile transformations” with more satisfied customers, happier employees and improved operational performance, resulting in tangible differences to the bottom line.

When agility is valued by an organisation, Agile development offers a compelling and mature example of applying a methodology that results in greater agility. The Agile (with a capital A) has influenced the agile (with a little a). Techniques such as the daily stand-up and sprint planning are sometimes encountered in more general project management. It’s also possible that among business stakeholders who don’t fully understand Agile development, the distinction between Agile and agile has become blurred.

To what extent are we Agile?

Back in 2015, our current Head of Product Robert McWhirter wrote a piece on this site called the “Agile web development process explained for non-technical people” which did exactly that, giving the ins and outs on Agile methodology. Robert wrote that Agile development was for many “something new, exotic or unknown”.

Seven years on and there’s certainly much more awareness of agile among non-IT folk; it’s been a methodology and influence that’s been put into practice in many more organisations, and many more marketers have been involved in an Agile or nominally Agile project. They’ve participated in stand-ups, think in sprints, and even adopted a Kanban board for their own use. Agile development is no longer exotic or unknown.

But this knowledge is certainly not universal. Occasionally we still point people towards Rob’s blog and when we undertake client work, we do encounter many who have never really taken part in a project run on Agile lines.

So how mature are Agile development practices? The Annual State of Agile report from Digtial.AI provides potential answers, suggesting that we have some way to go. Although overall 94% of companies practice Agile, there are many who have practices that aren’t mature; 36% have been implementing Agile for two years or less or aren’t Agile at all. And outside software development, the influence of Agile starts to drop off: while 86% of software development teams have “adopted Agile principles and practices”, this falls to 63% for IT functions as a whole, 29% for operational teams, and only 17% of marketing departments.

Fifty different shades of Agile

One of the problems is there are differing interpretations of Agile. A project that is labelled Agile doesn’t always end up being so. Using a bit of imagination, we can label these different shades of Agile:

Agile in name only: a project that is actually Waterfall with perhaps some stand-ups and a Kanban board

One way Agile: a project where the development team are sticking to Agile principles and methods, but the other stakeholders aren’t playing ball

Selectively Agile: a project that cherry-picks some of the key techniques for Agile, but ends up not really delivering the benefits

Sprints-only Agile: a project that is not Agile, but where there are sprints which are just periods of two weeks rather than being proper cycles

Start Agile, end Waterfall: a project that starts out Agile with good intentions but ends up being Waterfall because Agile is applied in a loose or half-hearted manner

More fragile than Agile: a project that aims to be Agile, but inexperience or lack of commitment means Agile components are not rigorously applied and keep breaking down.

Of course, there is nothing wrong with taking elements of Agile development and making them work for you. Some organisations do this successfully, recognising cultural or structural barriers to going fully Agile. But often not going fully Agile can mean you’re less able to enjoy the benefits.

Agile doesn’t guarantee success

It’s also important to stress that, even applied in full, Agile methodologies do not guarantee successful outcomes. There are various estimates of the percentage of Agile projects that fail, but most seem to suggest that at least they have a greater chance of succeeding than Waterfall. (Personally, I find the black-and-white of success/fail is unhelpful when applied to projects, as outcomes and their consequences have to be taken into context.)

Agile is also not universally popular. There’s a UK indie band called MJ Hibbett & The Validators whose most recent album contains quite possibly the world’s first pop song about Agile methodologies. The lyrics are very funny and convey some of the valid criticisms when Agile is misapplied, including immortal lines such as “Cos when we muck the whole things up, We can call it Minimum Viable Product, If you don’t like it – tough luck, it’s Agile” and “The Project Team says that’ll do, We’ll not be here for BAU.”

The lyrics reflect a feeling that Agile can become a mantra that can legitimise any output, an overarching methodology where the process seems to be valued more than the actual product. It’s a sentiment that we do encounter among business stakeholders and product teams, and sometimes among IT staff outsides the development team. Perhaps unsurprisingly, it turns out MJ Hibbett has a day job as a database administrator.

What can we do to make Agile development better?

The most pressing question in all of this is how teams who are wanting to make Agile methodologies work better in their organisation. I think this is both about demonstrating good practices, but also about spreading awareness:

Setting out the roles, rules and process details of the project before it starts, and walking through these in more detail for the entire team, even if it’s treading old ground for some team members.
Creating a climate where it’s acknowledged that not everybody is used to Agile so people feel OK to ask questions rather than feeling they should know and not asking.
Being explicit about Agile maturity and identifying where practices need to move.
Creating an Agile community within your company that can swap tips and tricks, and where teams can ask questions to more experienced practitioners.
Being disciplined and sticking to the processes and structures, applying persistence across each sprint even if not everyone is playing ball.
Never using Agile as the mantra to justify poor output or not addressing issues which need to be fixed.

Conclusion

Are we all Agile now? Well, we’re getting there, but the more truthful answer is no, not really. And should we use it as a marketing term? I’m not sure it’s really helpful, as it’s open to misinterpretation and not always understood. Instead, we need to focus on making Agile development work better, so it truly delivers projects built on human-centred design with fantastic output that makes a difference. As that happens and Agile delivers its true potential, then more people are going to truly embrace Agile methodologies.

The post Should we still be using ‘Agile’ as a selling point? Aren’t we all Agile now? appeared first on Browser London.

Why user stories belong in the garbage

Browser — Tue, 30 Aug 2022 08:06:26 +0000

User stories have become ubiquitous in software development. We write and phrase everything as user stories. But in reality, we don’t live our lives in stories; we tend to think in terms of carrying out tasks like sending an email or buying the weekly online shop. And while the information that user stories contain is useful, that disconnect between the story and the reality of the way users think has made me wary about our reliance on them.

In fact, I’d go as far as arguing that user stories should eventually end up in the garbage. When I’ve read others propose this idea, I’ve found it strongly resonates. Like them, I’m not trashing user stories completely – they have a valuable role in enabling developers to have the right conversations – but they also have a lifecycle. User stories are of the moment, and they do not need to live forever.

What are user stories?

Defining a user story is not hard, though it may be difficult, even impossible, for everyone to come to a consensus. There are entire alliances of people who have got together to address this question in excruciating detail. Instead of giving a detailed answer of what a user story is and getting caught up in navel-gazing semantics, I’d like to offer a description of the lifecycle of a user story.

To begin, I want you to understand what I think the purpose of a user story is, or at least what I believe its scope to be – when it is useful, and when it stops being so. The question of when a user story stops being useful is the most informative, but in order to understand the death of a user story, let’s understand its birth.

Change conception

Let’s explore how we typically record a problem that a user has. And there is always a problem. In fact, there are a lot. The problems are multivariate — something isn’t working, or works unsatisfactorily, or doesn’t exist — and something needs to be done to solve those issues.

We all know the solution to the problem is coding some software, but we also know that writing code is incomplete solution thinking. So, we need documentation! Let’s document the problem. But how? And where to start? Let’s begin with the person who has the problem. She can tell us what’s wrong.

So, we ask the person with the problem for more detail. It turns out, as expected, there are many problems and they all differ in depth or complexity. We ask her to document her problems, and she creates a list. For some developers, this can make depressing reading which highlights the problems with the solution, and it can even feel like she’s demeaning the development team’s previous efforts! Most importantly, the list doesn’t describe motivations or reproducible behaviour. So, what do we do? We write user stories!

‘As the person with the problem, I want to use some new or augmented thing to solve my problem.’

Great! Well… pretty good. It’s a start. At least it’s not a depressing list of broken and missing features. Instead, stories are well-motivated and reasoned, and phrased proactively so we can feel good about our upcoming work.

Further, we no longer need to talk to the person with the problem as we already know her desires and motivations. We can go away and code, and we’ll just tell her when everything is done. So, we should start writing the code, right? Well, not so fast…

Teamwork and distribution of responsibilities

The problem is that we now have some information, but we’re missing an actual list of things to be done, which is crucial. But what kind of list do we need? Because we work in a team, it needs to be visible to everyone, clearly stating responsibilities belong to whom and when, and in what state each task is. So, we use a board. But what do we put on it? User stories?

Of course not!

User stories describe too much. In particular, they have ‘who’s and ‘what’s and ‘why’s and sometimes ‘how’s and ‘when’s too (that’s a lot of ‘and’s). None of those things describes what actually needs to be done by any given team member.

So, we get together and chat. ‘What actually needs to be done to satisfy this story?’ This is where we get into creating tasks. Tasks are the individual units of work necessary to get larger units of progress completed. We take the user story and, as a team, have a conversation to break down each story into tasks. It’s the tasks that we put on the board, not the stories. Now we can get to work.

It’s worth pointing out that dividing a user story into tasks isn’t purely a divvying up of the work at hand. It’s actually an important piece of analysis that translates the user story into action and involves insightful discussion and debate. It’s only by breaking the story into tasks that we can go through the user story mapping story mapping process, for example. In my experience, these task-based conversations have real value.

The end of a story

But what about the user story? What happens to that? If you ask me, you destroy it.

If you put the story in your icebox/backlog/cooler/hat, it’s time for it to go. It’s now duplicate documentation. That story was only there because you were yet to break it down into tasks. Now you have, so you delete it.

I don’t mean tick it off as complete, I mean right-click on it and hit the ‘delete’ button. It may seem harsh — after all, that’s how the original issue was communicated, and it informed your task list. However, it is no longer informative.

Why? Let’s be honest about the role of a user story – it’s just a placeholder for a future conversation while we’re collecting data about how a system needs to work, what it needs to output and for whom. Once we’ve had the conversation, the components of the story should have been documented. This renders the original user story irrelevant. Keeping it alive is meaningless, and often distracting. And no, it’s not particularly good for documentation.

It’s important to remember that a user story is not documentation. It’s a bit of a tautology, but it’s worth noting that documentation of how the system works is documentation. The change log is documentation of what has changed. In this kind of thinking, user stories are documentation of change yet to come.

But what about retrospective value?

One argument about retaining user stories is that they provide useful context for the next project team and future development. But apart from shining some light on the internal development process itself, perhaps promoting a flicker of interest, they don’t really offer anything of substance.

User stories are projections of desire. They don’t offer retrospective value because they are written before anything happens. We may deliver a perfectly fine product, but still never achieve any given user story; requirements change over time, better solutions are found and users’ roles sometimes change before their stories are ever satisfied. Those only matter if we treat the history of user stories as a source of truth.

Essentially, user stories are a record of what was intended to happen, not what actually happens in the development; using them as a starting point for further work only provides a distortion.

Having said this, there are two places where user stories can live more indefinitely. One of these is in the backlog where they can create places for conversations that you’re not ready to have yet, and you can continue to update user stories with requirements, acceptance criteria and so on. User stories might also have an effective shelf life as a label for a release, although that will depend on the nature of the release.

There’s also a place for user stories as epics. For example, JIRA epics are effectively user stories, albeit at a slightly higher level, which are intended as collections of other more granular user stories. Once you discard the latter, you can keep your epics around.

Towards user story lifecycle management

The correct lifecycle of a user story is to collect data, write stories, gather as a team to discuss the stories and create tasks to satisfy them before deleting said stories and moving on to completing the tasks. User stories are simply documentation of a pending conversation.

Once the conversation is had, we need to document the outcomes and progress into the next section of work. If you want to communicate back to the users what has changed, you have a change log. Document the new possibilities and behaviours there. Not ‘As a subscriber, I want to…,’ but ‘Now subscribers can…’

Carrying out proper user story lifecycle management like this means you can start to improve development cycles; for example, when you get to the point of ditching the user stories, how do you feel about dumping them? Because if you sense that you’re going to lose important detail, it may be that you haven’t had the right conversations or derived the right tasks. Considering whether you’re ready to bin the user stories can be a useful checkpoint.

Fetch the bin

There is a tendency to treat user stories as the gospel source of truth, and the suggestion to delete them can raise some eyebrows. But we’ve grown to be over-reliant on them. If you look back to the Agile manifesto or Scrum Alliance training, user stories are designed to document the desires of users, not actually document how a system works. If you handed somebody a list of user stories and said ‘here’s how our system works’, they wouldn’t understand it. Ultimately, our records and documentation are designed to aid in understanding.

So, it’s okay. Bin the user stories.

The post Why user stories belong in the garbage appeared first on Browser London.