product design Archives

Tag Archive for: product design

In this post, we look at non-functional requirements are tracked by agile product teams and how they impact the product development cycle.

Imagine that you’re in the market for a new car. As you shop, you have a couple of non-negotiable features or attributes in mind, such as saving destinations within the car’s built-in GPS navigation system or that the car must be black. Although you may consider these to be “must-have” features, they would be considered non-functional requirements tied to the user experience.

What are Non-Function Requirements (NFR)?

Non-functional requirements are global constraints on a software system e.g., development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.

A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability, and portability.

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.

Non-functional requirements may be found in adverbs or modifying clauses, such as “The system prints invoices quickly” or “The system prints invoices *with confidentiality.”

Software has non-functional requirements that are essential to creating a positive experience for the user. And if you miss the mark on these requirements, you may have scheduling delays, budget setbacks and unsatisfied clients.

A project that lacks non-functional requirements may also lack clarity, which can result in vague project scope and a disconnect between the designer and client expectations.

Non-functional requirements bridge the gap between what developers believe customers want and what customers really want.

One study found that 60 to 80 percent of the cost of software development involves rework. And when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.

So, now that we’ve defined non-functional requirements, how do you integrate them effectively into your product development process?

Non-functional requirements focus on the “ilities” of the product

The “ilities” of a product include quality, reliability, manufacturability, usability, serviceability, upgradeability, etc. See SEAri MIT for more information.

Non-functional requirements focus on the user experience. A non-functional requirement is a statement defining a system quality, constraint, or external interface. For example, you might want to build a system that can manage expansion in the future. But saying so isn’t enough. You need to be specific. Instead, you might define that as “building a system that can manage at least 50,000 users over the next 24 months, so customers don’t experience the frustration of system crashes.”

Additionally, a non-functional requirement may:

Follow any legal or adherence rules.
Define quality attributes of the software.
Ensure performance in key areas such as reliability, availability, scalability, and more.
Focus on the user experience so the system is easy to operate and the risk for potential rework is minimized.

Just as with car shopping, not everyone needs the same features to make their user experience great. You might want warming seats in a new car, but somebody else might want a third row of seats. So, the non-functional requirements that you define for your project will vary based on client expectations. A list of potential categories, however, can give you a starting point to consider which non-functional requirements need to be on your list.

What are the different types of non-functional requirements?

Think about non-functional requirements as buckets that hold attributes important to the user experience. Remember, it’s not what a product will do (which are its functional requirements), but it’s what a project will be.

If you have selected the right buckets and measured the right things, then you can feel confident that you’re handing over a product that will meet customer expectations – because you’ve clearly defined these expectations up front. Everyone is on the same page, which is even further enhanced when you centralize your requirements management, which we’ll touch on shortly.

For now, let’s look at some of the potential categories for non-functional requirements:

Performance and scalability. What are the required response times, benchmark specifications, and other attributes related to performance? How fast does the system provide results, and how will the performance change with higher workloads?
Operating constraints. Operating constraints may include any required software requirements, system requirements, and run-time constraints that need to be considered in product development.
Platform constraints. Most projects include some sort of platform constraints. Clearly define these upfront.
Modifiability. How much effort is required to make changes to the software? Defining this upfront can help the customer better plan for any potential changes.
Portability requirements and capability. How difficult will it be to move the software to a different platform? What hardware and operating system does the software run on? Does it conflict with other processes or applications within these environments? Clearly define these elements.
Reliability. How often does the software fail? Outline any consequence of software failure and strategies for detecting errors, plans for error correction, and more.
Security. Security focuses on the requirements for protecting the system and data. How much time and effort does it take to break into the system, and how can you mitigate these exposures?
Usability. Usability is focused on the user experience. How difficult is it to learn and operate the system, and how can you improve any potential uses?
Legal. There may be legal issues around data privacy, intellectual property rights and more.

Categories vary by project, yet some common categories include availability, capacity, reliability and security. Using a few of the more common ones to start and then expanding to other areas can help you build a template for new product development projects.

Functional vs. non-functional requirements: What’s the difference?

Attributes of Functions vs Nonfunctional Requirements

Functional requirements are focused on how the software needs to perform or the desired behavior of the system. For example, if a specific condition is met, a system will send a new user a welcome email. A functional requirement is focused on what the system does when a requirement is met. Other functional requirements might involve business rules, reporting requirements, audit tracking, and more.

A non-functional requirement focuses on properties and characteristics of the product that are generally passive. Non-functional requirements are focused on attributes such as privacy, portability, reliability, stability, and more.

What is a non-functional requirements document?

Non-functional requirements are one component of the software requirements specification document (SRS document). This document focuses on what the software is expected to do and how it’s expected to perform. It also addresses what is required in terms of functionality from a user perspective.

The SRS documents include a few sections, such as:

Overview of the system. The overview includes high-level details about the system. Any useful terms are defined upfront in a glossary-like format.
General description. This section outlines any assumptions about the project and the overarching vision or theme.
Specific requirements. This section is where the functional and non-functional requirements are included.

If you haven’t written an SRS document before, or if you want to improve on your existing document, check out examples as a starting point. These also provide inspiration for how non-functional requirements examples flow into the entire document.

What templates exist for tracking and managing a non-functional requirement?

Software and hardware teams collaborate throughout the entire development process as they define functional and non-functional requirements. However, this collaboration becomes problematic when teams use different tools. Centralizing requirements management allows you to save time, align more effectively, and ensure the quality and compliance of product development. Using a single solution enables you to effectively:

Experience a single source of truth. A single source of truth offers greater visibility throughout the entire product development cycle.
Benefit from real-time iteration. Working within a requirements management platform that has visibility and communication across all development teams enables more informed decisions and improves collaboration abilities.
Enjoy stronger visualization. You can more effectively visualize how tests trackback to requirements, resulting in higher quality and compliance.
Reuse validation requirements. Reuse validated requirements to quickly replicate features across products.

Centralizing requirements management allows you to build stronger and more effective non-functional requirements, which improves product development. A single source of truth empowers you to connect data, conversations, and decisions – all within a single system.

The result is that you can collaborate and communicate critical pieces of information around product development, resulting in less rework, fewer missed deadlines and happier clients.

See How Jama Connect Streamlines Tracking and Tracing Requirements.

As more companies pull design functions in-house, knowing how to properly execute a good product design critique is becoming a core competency for development teams. That’s according to Jon Kolko, the founder and director of the Austin Center for Design. In an article for Fast Company, Kolko outlines a structure for improving the critique process, demonstrates how a good design process can foster team collaboration, and argues why critiques matter in the first place.

The Problem with Product Design Critiques

Kolko points out that for years, companies outsourced their design functions. Outsourcing allowed businesses with some amount of distance from the product design process and made the design firm a “garbage dump,” he writes. “If a company didn’t like the design firm’s ideas or the ideas didn’t gain traction, the company could simply fault the designers — and the in-house team could feel vindicated, as if the problem were not their responsibility.”

But as companies bring design functions in-house, people who are not traditionally associated with creative functions have to learn a whole new skillset — one that doesn’t come naturally for most people.

Product design itself is one thing. Product and business experts have the knowledge and expertise to provoke innovation in the design phase of product development. But often, these “experience owners” have not developed the skills necessary to critique design — or to receive the critique themselves. In an environment where there is no robust culture or language of critique, product design teams have no proper means to course correct when ideas languish or suffer from poor delivery.

Key Ingredients: Trust and Team Collaboration

In an environment where the experts responsible for the design phase of product development — product managers, marketers, engineers, developers, etc. — have little or no previous experience giving or receiving design critique, working to create a culture of healthy critique isn’t just a nice thing to have, Kolko considers it an imperative. “Critique is one of the pillars of a successful design team,” he writes. “It walks hand in hand with execution and craft. And it’s evidence of a high-performing team, because it externalizes one of the most important parts of creative execution: trust.”

Kolko quotes Rachel Hinman, product design manager at StitchFix: “If you don’t have that trust in the team, it’s really difficult to have a productive critique. It’s either people don’t say the hard things because they don’t want to deal with the confrontation because they aren’t sure how somebody will react, or they do say those things and it becomes a passive-aggressive competition almost.”

He also quotes Ben Fullerton, vice president of design at OpenTable, who says that part of maturing as a designer is detaching from the work and becoming willing to receive feedback from others with the understanding that the intent is to move the work forward and make it better.

In order to build the kind of trust and team collaboration that result in good product design and execution, design teams need to actively foster a culture of healthy critique — one that opens the door to real market disruption and innovation.

To learn more about the growing number of organizations adopting product development solutions to manage the complexity of connect systems, download our eBook, Your Guide to Selecting the Right Product Development Platform.

Qualities of a Healthy Product Design Critique

In his courses at Austin Center for Design, Kolko conducts critiques as frequently as possible and rarely waits until a project is “done” before asking the student to offer it up for critique. “Design is iterative and is never done, and if a student starts to treat his work as ‘finished,’ he will be reluctant to change it even when confronted with a better solution,” he writes.

The same is true in the design phase of product development. If those responsible for design hold their ideas too closely to vest or resist critique until the design is “finished,” there is little to no opportunity for team collaboration or for others to improve the product — and, as it turns out, little opportunity to build trust.

Trust is only built when it’s given the opportunity to grow, and the only way for trust to grow is to intentionally stimulate it through exercises such as the design critique.

Kolko defines a critique as a process that “emphasizes the negative in order to help designers improve their work. During critique, designers present their work to a group. The group identifies places where the work can improve. They discuss alternative solutions, sketch those solutions, and work collaboratively to explore which changes will benefit the work the most.”

For product design teams to develop a good critique process, there are several elements that Kolko recommends based on his classroom experience:

“Pin up” the work. Displaying the work on a wall or in some physical manner gives the entire team the opportunity to see the work the same way in the same format. It gives a baseline that allows the group to see a full narrative context. And it gives the designer the opportunity to learn how to best present the work to an audience.
Ask the designer to set boundaries for the critique, then step back. Kolko tells designers to only offer parameters for critique, but not to offer explanations. For instance, a designer might ask for specific feedback on certain elements of design or tell the audience to avoid giving feedback on a particular element. This process establishes boundaries, but then requires the designer to detach from the design as feedback is offered.
Note feedback directly on the design. As team members offer feedback, Kolko recommends that they also annotate their recommendations directly on the designer’s work. This forces a degree of specificity in the critique and reduces unhelpful feedback.
Critique the critique if things get personal. Part of establishing trust is learning to avoid personal attacks — real or perceived. If the critique starts to get personal, Kolko stops and conducts a critique of the critique, often brainstorming ways to avoid similar personal reactions in the future.
Summarize comments with the designer. After the critique, Kolko makes sure the designer has everything necessary to make changes for future iterations.

When properly conducted, product design critiques have tremendous potential to not only produce better products, but also to unleash a creative spirit. When trust and team collaboration are established and fostered, teams have a safe environment to push forward truly innovative solutions.

To learn more about the relationship between rising product complexity and effective requirements management, download the full report: “Design Teams: Requirements Management & Product Complexity.”

This is a guest post from Mark Clark, Account Manage at the product development firm, Bresslergroup. It originally appeared on their blog.

Version one of a new product is what gets people excited, but versions two and three are what will really establish you as a successful innovator.

Taking an existing product to its next generation often has a greater impact on a company’s long-term success than the initial innovation. But only if you respect next gen design as its own unique challenge.

Why Go Next Gen?

For many companies trying to push the edges of what a product can do, simply getting something to market is an enormous effort. The Minimum Viable Product strategy (MVP) has a lot going for it, but it’s rare that an MVP on its own is going to hold market share for very long.

Competition is the most obvious reason to update. If sales numbers on your initial product are slumping, but competitors’ are doing well, that’s a good argument for a refresh, whether through improved tech, new functions (that users actually want), or a more refined aesthetic — especially if your MVP looks like it was released in a hurry.

Here are some compelling reasons to go next gen:

1. Technology Advancements

Technology is always improving, offering a steady stream of possibilities for your product: reducing size, extending battery life, cutting costs, or adding features. All of these expand a product’s appeal, moving it beyond the domain of early adopters and into the mainstream.

When Bresslergroup redesigned Temptu’s cosmetic airbrush system, for example, we were able to take a unique product with niche appeal and make it more portable, intuitive, and easy to use, opening it up to a much wider range of customers. Pump and battery technology advancements made this possible.

2. First Gen Failed to Resonate

In some cases, a truly innovative product may look or work so differently from what’s on the market that it fails to resonate with customers. Early versions of the Honda Insight, for example — the world’s first production hybrid car — were so high-tech looking that people felt self-conscious driving them. It took another couple of years for the Toyota Prius to come along, with its just-different-enough aesthetic, and truly break the market open.

As an innovator, you have the unique advantage of getting to watch firsthand how people react to and use your initial product. With a little well-directed user research, you can learn an awful lot about how to improve the experience it delivers, what features users might want in a second version, and what can be pared down or removed. Implementing these changes is a relatively low-cost, low-risk way of providing a UX that earns real love.

3. To Scoop “Fast Followers”

“Fast follower” products can be a headache: plenty of companies have done well for themselves by waiting for others to innovate, then swooping in with a cheaper, slightly more mature product a few months later. Developing your own next gen product can help stave this off.

4. To Improve User Experience

The best reason for a next gen design might be an improved user experience (UX). Rachio, a smart sprinkler system manufactured by a startup that Bresslergroup has worked with for several years, offers a good example.

Rachio’s first generation was a classic MVP, offering some unique functions (a smart, Web-connected sprinkler system that could adapt to changing weather) in a no-frills package. The initial product was a hit with early adopters, willing to accept certain functional limitations and a nearly non-existent interface in exchange for a truly game-changing product.

Looking closely at what those early adopters were doing with their Rachio units, and what they wished they could do, gave some clear ideas on how to improve the UX in the next round. Rachio’s version two allowed direct control of the unit (not just via app), an easier installation process, and greater WiFi reach — and sold dramatically better than version one.

The approach was so successful, in fact, that Rachio now has a dedicated User Research team on staff — an unusual investment for a small startup, but one that’s yielded huge returns, especially now that version three is on the market.

How To Approach Next-Gen Product Design

Evolving a product to make it more competitive can take many different forms, but in our experience, most next-gen redesigns fall into a few common categories, each with its own advantages.

1. Give It A New Look

A new form factor is an obvious place to start. The technology inside makes the product work, but the external form is what people touch and see. Updating that form is the most direct way to show them your product is grown up and here to stay.

An aesthetic redesign can also help bring a new product into line with a coherent visual brand language, something Bresslergroup has done numerous times for clients including BD and PetSafe. A coherent visual brand can create a network effect, adding legitimacy to each product in the line, and inviting one product’s customers to embrace another as their needs grow.

2. Refresh the Electronics

Refreshing the electronics can serve as both a cost-saving measure and a way of adding function, especially given the speed with which off-the-shelf components are improving.

Trice Medical’s mi-eye+ arthroscopic probe, for example, got an update from Bresslergroup that switched out its custom display for a modified Surface tablet. This not only cut manufacturing costs significantly, it also opened up software options that let us improve the UI and expand the device’s capabilities.

As products age, companies are often forced to switch out individual electronic or physical components in manufacturing, to replace obsolete ones or take advantage of price reductions. At a certain point, this can actually become more expensive than redesigning the entire product with new components in mind. Knowing when that tipping point is reached is crucial to long-term product success, and in our experience, companies are more likely to wait too long than redesign too early.

3. Redesign the App

Since so many products these days also have a digital component, redesigning the app can be a relatively quick, low-cost way of refreshing a product. Customers have gotten accustomed to apps that update every month or two, so last year’s digital experience (on a smartphone or the device itself) can make a product feel dated.

A redesigned app offers another advantage as well: it’s a way of field-testing new features, UI elements, or visual designs. The rapidly changing landscape that makes users expect frequent updates also makes them fairly comfortable with digital change, so you can use an app as a kind of design sandbox, then take cues from it later on when you’re ready to commit to a physical redesign. For many products, two to three rounds of app update per physical redesign is a ratio that works well.

Innovation Is Ongoing

Innovation is an ongoing process, and the truly successful innovators are those who view a new product not as the end of a design process, but as the beginning of a refinement process.

We’ll always love reading about what’s new and novel in products, but when it comes time to open our wallets, we’re more likely to go for the product that’s benefitted from time and careful improvement.

“There are so many moving objects when managing a product. You must be aware of them all (managing vendors, internal politics, management structure, development teams, testers, project managers, designers, architects, businesses, customers, etc.), and like a game of chess, you must be thinking ahead several moves in order to react (or not) properly.
Nailed it. And, we would add, the processes you depend on to bring products to market must also adapt.

The many steps involved in building products—moving from product idea to release and, hopefully, to customer approval—have traditionally been relegated to product and engineering teams, at least until something goes wrong. Companies strive to update product delivery processes for the way business works today by involving stakeholders from multiple departments and including executive leaders. “Many hands make light work” goes the saying, the idea being that a collaborative, dedicated effort toward a shared goal should lead to desired results.

“Should” is the key word here. The challenges of integrating hardware and software, handling employees in multiple locations and different time zones, and dealing with immediate customer feedback, among many other things, adds a great deal of complexity to an already high-stress, fast-moving process. Companies recognize the business value collaboration can bring, but it’s much easier to advocate for than to organize and execute. Too often, collaboration devolves into design by committee.

Forrester Consulting conducted in-depth surveys with 150 senior business and IT professionals at enterprise organizations and found that a hefty one-third of companies release their products late. The top reason? A classic: Unclear or changing requirements. The surprising drag on reaching the finish line in time? Delayed decisions.

Executive leaders are the acknowledged decision-makers at the high level—giving the green light to build product X with Y specs for Z cost—but during the cycle of product development to release, no one has to make or push through more decisions than product managers. And at the rate 21st century companies conceive, build and release products, the time spent getting to market matters more than it ever has.

So while Matt Khoury astutely testifies to the many ways that product managers encounter problems on the path to release, we would add a note of caution for all companies who conceive and bring new innovations to market:

If you expect your employees to focus on outcomes, you need to adapt and you must also align teams; enable fast decisions, reuse and stakeholder involvement; iterate quickly and provide stakeholders and all participants with real-time context right up to the point of release.

The success of your product depends on it. Just ask your product manager.