-
3 Ways to Screw Up Your MVP After Its Release
When your Minimum Viable Product (MVP) is successfully released, you can still screw things up. Here’s how to avoid squandering your MVP and messing up your full product.
The best possible start
Let’s paint a picture where your startup has done everything right, from concept through first release.
You identified a customer problem—a need—and envisioned a novel product solution. You pared your idea down to the essentials that serve an initial target user group, and judiciously scoped a Minimum Viable Product (MVP).
Quickly and nimbly, your team designed and built a spartan but pleasing-and-effective version of the product. You identified how to measure the success of the MVP (i.e., how to determine whether your solution sufficiently meets the user need). Your team releases the MVP to your initial users without incident.
All of the above is difficult enough to do well, but let’s take it one further: your proof-of-concept MVP passes the big test with users!
So, from concept to validation, you have relatively quickly confirmed that your core idea for addressing a customer need is a good one, and that the product is worth building on.
Everything is great. But it’s still pretty easy to screw up from here.
What’s NOT a screw-up
Let’s take a step back and imagine another outcome.
What if the released MVP showed that your product doesn’t effectively solve you users’ problem? That’s not a screw-up. That’s the reason why you went the MVP route to begin with; if the idea was going to fail, you want to fail quickly and cheaply.
But again, that’s not your story. Your core product is effective, and clearly worth moving forward with.
What’s left to screw up?
Ways to screw up your MVP, post-release
1. You don’t fully leverage your MVP as the experiment it is
Even if your main focus was to confirm market viability, there is still a bunch more you can learn from your MVP and its users. Test deeper.
Your measurements met your success thresholds, sure, but what else can they tell you? What else could you measure? How exactly do your users use the product, and how does that map to your expectations? What do your users have the most trouble with? How do they feel about the current product and its potential? What features and enhancements do they say they want the most? What do potential paying customers care about vs. what free-version users do? Etc.
Wring all the knowledge you can out of your MVP while it’s still active.
2. You rest on your laurels, or simply wait too long
The next big step after validating your core idea is to move toward developing your full product.
Don’t wait
If you built your MVP in a not-really-production-ready fashion—which it often makes sense to do, to facilitate cheap rapid development—then it will likely be obvious to you that you need to move quickly to replace it with the real product.
If, however, your MVP was developed in a production-ready fashion and is a suitable foundation to build upon immediately, then, ironically, you’re a little more likely to get complacent and put it off.
Either way, waiting too long to follow up on your MVP is a mistake. It was an experiment of its time, and its lessons get staler and less reliable the farther it gets in the rearview. Planning an MVP effort from the start should include time and resources to immediately follow up on the result.
Don’t stay minimal
Also, don’t lose your way after your MVP test. The lesson of the MVP process thus far wasn’t that the narrowest of core functionality is all you need, indefinitely. Just because you were able to eliminate a bunch of potential features and enhancements from your successful MVP doesn’t mean those features aren’t good, or even business-critical. They just weren’t essential to proving out market viability in your MVP experiment.
Your early adopters were likely only a subset of your target user base; your product may require additional features and smoother edges to satisfy the next set of users. (The early adopters won’t have infinite patience, either).
Your product won’t remain viable for long with just the minimum set of features. (Just checking, if I’d written “Your P won’t stay V if is remains M for too long”, would you have understood what I meant?)
3. You move forward with your head down
You had a ton of ideas that didn’t make it into the MVP. You made a prioritized list of all the features and enhancements that you still want and need to do.
This is your vision for the full product. Your MVP tested the waters. Now that you can dive in, how do you proceed?
Don’t stubbornly stick to your roadmap
Even before your MVP was released, you probably had a well-thought-out roadmap of future features and enhancements to pursue.
But no matter how good your roadmap is, it’s going to be at least a little wrong.
Don’t work on the full product with your head down. Listen to and observe your users, and observe the realities of the market as it’s playing out with your MVP.
Listening and observing will:
- tell you what features you should prioritize,
- show you what needs to be redesigned for usability,
- guide you toward promising revenue streams and away from bad ones,
- inform you as to how your users view your product vs. similar existing products,
- inspire important features that aren’t already on your list,
- and eventually make you realize that some of the features on your list don’t need to be.
Keep iterating
Even though your MVP experiment is behind you, you should continue to apply a similar philosophy to the rest of the product lifecycle.
Keep applying a build–measure–learn approach. Adding a new feature? Get it to market quickly, get feedback, then develop it further or fix it if it’s not effective.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Benefits of Using Variable Fonts
Variable fonts are becoming increasingly viable for use in your web projects. Here’s what variable fonts are, and how using them can benefit the user experience.
Variable fonts vs. the usual way we deal with fonts
When you pick a named font to use on your website, for example “Arial”, “Helvetica Neue”, or “Open Sans”, you’re actually picking a font family (a.k.a. “typeface”).
You might use just a handful of fonts in that font family on your site, e.g. Arial Regular, Arial Regular Italic, Arial Bold, and Arial Bold Italic. Typically, each of these fonts is defined in a separate font file.
So, even though Open Sans Semi-Bold is rather similar to Open Sans Bold, each is represented by an independent font file of roughly equal file size that would have to be downloaded to your site-visitor’s browser. And the file sizes of all those font files can add up.
Variable fonts allow more of a font family to be defined in a single font file. Within a variable font file, font designers develop “master” font style variations, as well as the math-based rules under the hood that allow users of their font to morph between those variations by modifying simple numeric values. The result is a font file that can produce a lot of variation in relatively little file space.
The user-controllable style variations don’t end at thickness and slanty-ness, though. Variable fonts allow font designers to get creative and provide font consumers many more dials to play with.
Some benefits of using variable fonts
Here are some of the benefits of variable fonts.
Faster-loading pages
Less font data to download means faster page-load times.
This will likely be the single biggest benefit of variable fonts on the web, at least initially.
Let’s say you’re visiting a web page that uses six font styles, but requires just two variable font files. Those two font files are smaller in total size than the six you would have had to load otherwise, so that’s fewer server requests and less data to download for that page to display properly.
Thus, your web pages load faster. And faster-loading pages make for better user experiences than slower-loading pages.
Fewer compromises for designers
Another consequence of having overall smaller font file sizes: designers who are file-size conscious—or who are reined in by managers and technical leads who are—do not need to make as many compromises to their design.
The more that variable fonts proliferate, the fewer conversations you’ll need to have that begin: “Do we really need the Light Italic version of this font? It costs us an additional 100kb.”
Finer tuning
Variable fonts allow users of the font to adjust its supported parameters in relatively small increments, allowing for fine-tuning where desired.
Take the common example of font weight. With traditional fonts, font weight values range from 100 to 900, but are limited to nearest-hundred (and that’s presuming that each hundred is available as a separate font file).
Variable fonts, however can allow the font weight to be meaningfully adjusted to any number in the supported range. Want to split the difference between Semi-Bold (traditionally 600) and Bold (700)? Set the font-weight to 650, and that’s what you’ll get. Without a variable font, you’d be forced to choose between one or the other.
Far more options for font designers and font users
Axes of variation
Variable fonts let typeface designers design fonts that users can modify in a variety of ways. Each kind of style variation that a font supports is an referred to as an axis. Font weight is one example of an axis of variation in a typical variable font.
For each axis of variation, the font user can modify the style value within a predefined range. For example, one font might allow users to set the font weight to any value between 300 and 800; another font might allow a range of 1–999.
Tons of style combinations
A single variable font can support a large number of axes (if the font designer so chooses), and a font user can adjust any or all of the supported axes’ values.
As a result, the number of possible style combinations can get enormous fast.
For example, if a variable font supports weight in the range of 200–900, and width in the range of 50% to 150%, that’s 70,000 style combinations right there (and that’s presuming whole-number values only). If it supports a third axis with a range of 500, you’re already at 35 million combinations!
Please don’t make me do any more math.
Creative variations
These axes of variation can allow UI designers to modify normal stuff, like a font’s weight or width or italics-ness. But a font designer can also create custom axes for more creative modifications.
This might be as dry as decreasing the size of capital letters, as specific as increasing the number of thorns on a rose-themed font, or as wacky as changing the size of the hat that appears on the head of each emoji in an emoji-icon font.
Practical axes
Benefits of custom axes of variation don’t just cover aesthetics, they can be practical as well.
For example, some variable fonts have a “grade” axis that allows you to change the weight of the text without affecting the width of the text. This would be useful in a UI design where, for example, text labels are bolded when the item is selected, but it’s important to your design that UI elements don’t change size.
Text animations and transitions
Because an axis values can be modified incrementally, variable fonts allow for smooth CSS transitions between text states.
This page contains some interactive examples of text transitions triggered on mouse hover (as well as some examples of creative axes of variation): https://pixelambacht.nl/2017/variable-hover-effects/
In addition, variable fonts will provide more opportunities for interesting text and icon animation effects, based on font designers’ creative axes of variation.
More-responsive responsive design
Variable fonts provide tools for enhancing responsive design.
Some of this ties the concept of fine-tuning with responsive techniques. An example of this would be setting the font weight of a headline to always be a function of the current screen size, to preserve balance in your visual design.
You can also take readability into account, based on the size of the screen and the size of the text. With decorative fonts, you may wish to tone down the decorative styling of a heading when the text gets too small for the flourishes to be effective. Along the same lines, if a variable font supports the optical size axis, then you can give your users the best experience by tuning the font for optimal legibility based on the current size range of the text.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Gradually Master Cross-Platform Mobile App Development: Learn Flutter and Dart as You Go
You’ve gotten started with Google’s Flutter SDK to build mobile apps on both iOS and Android, but what now? Here’s how to keep the momentum going and learn Flutter and Dart over time.
Keep going after “getting started”
This article is about how you might learn Flutter and Dart over time in a sustainable way, to grow your mastery of the technology so that you’re ready to use it to enhance your career or your business.
Prerequisites
This article presumes that:
- You know what Flutter is, and
- You might have already gotten started using Flutter
The latter article is about how you can get started with Flutter. In particular, how to do so without quickly losing steam or immediately bouncing off.
Losing steam and dropping out are common when you’re just getting started with learning a new thing, but it continues being a risk afterward, too. Things can get dry, unrewarding, and frustrating if you’re not careful, and there are so many other shiny things to learn out there!
How do you avoid losing steam learning Flutter and Dart? Rack up small victories, bite off interesting pieces as you go, learn from others, and keep going.
Set achievable Flutter goals to learn as you go
Once you’ve done all of the hand-holding courses and tutorials that are available to you (or that you can stand), it’s time to give yourself some small, achievable mini-projects to drive your learning.
In his article for newcomers to Flutter, Nick Manning recommends setting “motivation milestones”, which can include both building and research milestone goals. Some of his examples:
- Milestone Three: Learn how to hook up a button, change some state and render it on the screen by using a StatefulWidget.
- Milestone Four: Take a few hours to read up on Dart.
- Milestone Five: Be able to fetch some data from a public API and render it on the screen. Understand how to work with JSON and deserializing it.
- Milestone Six: Release an actual iOS and/or Android build to a friend. This […] is really an amazing way to stay motivated and confident that you can crank out an app to the public one day.
Get input and ideas to learn Flutter as you go
Whether you’re giving yourself milestones or mini-projects to learn Flutter, it’s important to keep them relatively small and achievable.
You might want to assign yourself a project that is interesting to you and break it down into sub-goals. Or perhaps you want to be more reactive to outside forces, where the internet brings ideas to you.
Here are some places where you might be inspired to learn bits of Flutter as you go.
Flutter articles and media
A bunch of fine folks write informative articles about Flutter. This content might teach you something new, bring an aspect or capability of Flutter to your attention for you to pursue further, or simply allow other developers’ projects to inspire your own.
You might occasionally search the web landscape for such articles, train your phone to bring them to your attention, or follow authors who periodically publish content on the subject.
For example, on Medium, you might browse stories tagged “Flutter”, search through content on the official Flutter channel, or follow individual authors like Deven Joshi or Burhanuddin Rashid, who periodically write articles about Flutter.
Similarly (and yet differently), there is also The Boring Flutter Development Show, a video series on YouTube.
“Cookbook” and other Flutter.io documentation
Flutter.io has a bunch of great documentation to browse through, including a “Cookbook” of Flutter solutions to specific small goals (e.g. “Working with Tabs”, “Fade a Widget in and out”, “Introduction to unit testing”).
Poking through these might help you assemble your own milestones list.
Pick a widget and try using it
See below!
About those Flutter widgets
Everything is widgets / widgets are everything
Flutter is all-in on an abstract concept of widgets. In a Flutter app, effectively everything is a widget: UI text is a widget, input fields are widgets, layout containers are widgets, gesture detection is a widget, the app itself is a widget… you get the idea.
Learn Flutter widgets as you go
You might be tempted to dive into the documentation and learn about each and every widget type that the Flutter framework provides.
That’s not what you should do when you’re getting started, and it’s probably not what you should do afterward, either. Instead, you might investigate only the widgets that fit the need for your current project. Or pick an interesting widget first, and build a mini-project or milestone around learning it.
For identifying interesting or useful widgets, you might:
- Browse the catalog of categorized widget types in the documentation
- Run the Flutter Gallery app (from the Google Play app store or build it from GitHub). You can visually browse and interact with some of the widget types and samples, and inspect the actual code.
Learning Dart to learn Flutter
Flutter uses Dart for its programming language. Dart is not a language that most developers have prior experience with, however. Fortunately, when you are starting out with Flutter you can do a bunch of tutorials without really having to think too much about Dart.
But even when you’re “on your own” and learning Flutter as you go, it’s best not to let learning Dart bog you down and sap all of your momentum.
Learning just enough Dart
Android developer Gurleen Sethi wrote a useful tutorial series called “Just enough Dart for Flutter”. The four tutorials provide a focused Dart education for the impatient Flutter learner. A lot of it serves to show you just how similar Dart is to Javascript and Java.
Google also provides resources for you to “Bootstrap into Dart”, including a relatively lengthy tour of the Dart language.
Dart as compared to X
Want to learn about Dart from the perspective of…
- …Java? Try this Google codelab: Intro to Dart for Java Developers.
- …JavaScript? Try this: “Introduction to Dart for Javascript Developers”
Full docs
And there’s always the full Dart documentation at https://www.dartlang.org/. It’s reference material. You don’t need to try to read it top-to-bottom.
Help, support, and learning from others’ questions
You don’t need to struggle through Flutter problems all on your own.
Get used to going to the Flutter Google Group if you can’t find an answer to a problem on Stack Overflow. I recommend the former over Stack Overflow when asking questions actually. You can read more advice here.
There’s also a friendly community-driven live-video help session, available all day every Wednesday.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Getting Started with Flutter SDK to Build Native Android and iOS Apps
The Flutter SDK allows you to build native Android and iOS apps, with advantages over other cross-platform methods. Interested? Here’s how to get started with Flutter.
Google’s Flutter SDK is a relatively new way to build native mobile apps for BOTH Android and iOS.
Since being able to quickly produce apps for both platforms’ app stores may be very important to your business or your professional career, you may want to begin moving forward with Flutter, or simply try it out so that you know what’s up.
Before you get started: learning about Flutter (and getting motivated)
Flutter may have already piqued your interest. But that might not be enough motivation to push you through learning a new technology.
So, before you jump in, you might first want to strengthen your resolve (and increase your excitement) about using Flutter.
First, if you haven’t already, you can read my previous article about what Flutter is and why you might want to use it.
Beyond that, you might want to:
- Read “What’s Revolutionary About Flutter”, which lays out the whats and whys of Flutter, outlines its developer-pleasing aspects, and reinforces its potential advantages over other cross-platform approaches.
- Or maybe watch the six Flutter sessions and related videos from Google I/O 2018.
- Or you could listen to these two podcast episodes first:
Rohan Teneja recommends the two above podcast episodes as a great way to get started, adding:
If I had not listened to these back in March, I probably wouldn’t have been excited to try out Flutter immediately. The two episodes include everything you need to know about the “What” and “How” of Flutter.
Getting started
Set up the Flutter SDK
Google’s official Flutter site Flutter.io is a great resource for getting started.
The first four steps walk you through getting the proper things installed and configured, taking the Flutter SDK for a “test drive”, and quickly building a simple app.
Related to the step 1—Installation—Android developer Harshit Dwivedi has this recommendation that you may or may not want to keep in mind:
Note : You don’t actually need libimobiledevice , ideviceinstaller, ios-deploy and CocoaPods unless you want to build an iOS app, so ignore flutter doctor’s advice on installing them and you’ll save a hell lot of a time.
“Flutter doctor” refers to a tool that you’ll be installing and running as part of the overall Installation step.
Supported development environments
Installing/configuring an IDE is step 2 of the setup process.
If you wanted, you could develop Flutter using just the command line and your favorite code editor (and, if so, I will gladly refer to you as “hard core”). But, when getting started with Flutter, it’s advisable to use one of the supported Integrated Development Environments (IDEs).
Supported IDEs:
- Android Studio,
- IntelliJ, and
- Visual Studio Code
Being overly stereotypical: If you’re an Android or Java developer, there’s a good chance you’re familiar with one of the first two IDEs; if you’re a web developer, there’s a reasonable chance you’re familiar with VS Code.
However, if you’re not partial to any of the supported IDEs, then using Android Studio seems to be your best option for getting started for Flutter.
Android Studio offers the most features, such as a Flutter Inspector to analyze the widgets of a running application and well as monitor application performance. It also offers several refactorings that are convenient when developing a widget hierarchy.
VS Code offers a lighter development experience in that it tends to start faster than Android Studio/IntelliJ. Each IDE offers built-in editing helpers, such as code completion, allowing exploration of various APIs as well as good debugging support.
(Note also that installing Android Studio is required for using the Flutter SDK anyway, whether you plan to use it as your code editor or not.)
Trying it out to make sure you’re set up properly
Following step 3 (“Test drive”) and step 4 (“Write your first app”) right away will help you make sure everything is installed and configured correctly. You’ll also, of course, get introduced to Flutter and learn a bit about how the tools generally work.
What next, though?
After step 4, Google provides a number of different directions you might want to go next. This includes additional “codelab” tutorials you might want to work through—including adding enhancements to the starter app you just created—as well as various additional documentation on Flutter and its programming language Dart.
While Google still has a lot of materials for you, you’re essentially on your own now. You’re still in the “getting started” phase, and yet you have to chart your own course for how you want to learn Flutter.
Here are some ideas and advice on that front.
Learn how Flutter compares to what you know best
The next thing you might want to do is start bridging your current UI development experience to how UIs are built in Flutter.
Flutter.io provides documentation sets that compare and contrast Flutter code with UI code that you’re used to. For example, comparing HTML/CSS code to the equivalent Flutter code if you’re coming from a web background.
Flutter for Android developers
Flutter for React Native developers
Flutter for Xamarin developers
Take Google’s Free Online Course at Udacity
I don’t feel comfortable directing you to paid online courses. If that’s what you’d want to do next, I’m sure there are a bunch you can find on your own. I wish you good luck in evaluating whether they’re for you, and whether it’s worth your money.
Here, however, is a free online course on Udacity produced by Google. This is separate from the materials provided at Flutter.io.
This course is marked as “intermediate” (as opposed to “beginner”), but expects that you do not know about Flutter or Dart before you begin. Instead, the prerequisite is that you “should have at least one year of programming experience, ideally with an object-oriented language like Java, Python, or Swift.”
The course is described as self-paced learning that might take you “approx. 2 weeks”. Google software developer Mary Xia—who contributed to the course—stated that you could conceivably finish the course “over a weekend” in her article that describes the training in a bit more detail (as well as why you might be interested in learning Flutter).
Parting advice about getting started
- Don’t try to learn about the entire catalog of supported Flutter widgets right away
- Don’t get bogged down trying to learn Dart up front
- Give yourself achievable goals you’ll be interested in doing, and use this method to learn as you go
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Does Color Affect Mood in User Interfaces?
In physical spaces, color can unconsciously affect our mood. But does color affect mood in user interfaces? Not exactly.
If you are about to paint a room, you’ll find no shortage of web articles ready to give you advice about what colors to choose. Some of these articles will assert that color can affect our mood, and suggest how you might select a paint color to produce a particular emotional effect you want your room to have.
Some of this advice regarding color-mood effects is anecdotal or based on assumption, but some of it actually has some basis in science.
There is good reason to believe that the colors on the walls around us can affect our mood somewhat. But should we seriously consider this when picking paint colors, or ignore it?
And what about user interfaces? Does color affect mood there?
Mood effects vs. other effects
First, some clarification.
While some web resources combine multiple kinds of color effects under a single umbrella of “color psychology”, in this article I’m intentionally isolating mood effects from other potential effects.
So when I’m talking about the mood effects of color in this article, I’m referring to the idea that certain colors tend to have direct unconscious effects on a person’s general emotional state.
For example: the idea (however true or untrue) that orange walls tend to cause people to become agitated, regardless of whether those individuals happen to prefer the color orange or not.
What I’m not referring to:
- Colors’ various meanings and inferences, which can vary based on culture, industry, context, etc.
- Color preferences
- Color’s influence on aesthetics
- Color’s other psychological effects, such as impact on task performance
Does color affect mood in the physical world?
Yes. But…
1. The effects of color on mood are often overstated
Many psychologists are skeptical of the extent to which color actually affects us, compared to common claims. The reliability and amount of mood change caused by color are probably much lower than your average web article implies. There is also reason to believe that the effects are rather temporary.
2. The effects of color on mood aren’t well understood
Plenty of research shows that color can affect our mood, but a lot more research is still needed.
As professor of psychology Andrew J. Elliot wrote in 2015:
The focus of theoretical work in this area is either extremely specific or extremely general. […] What is needed are mid-level theoretical frameworks that comprehensively, yet precisely explain and predict links between color and psychological functioning in specific contexts.
Color psychology is complex, and clearly not as simple assigning colors to emotional reactions for all humans. For example, some color effects are tied to or affected by culture (e.g. life-long associations regarding color), and some color effects are highly dependent on context. But we don’t have nearly enough research to predict how these interacting factors come into play in any particular application of color.
Does color affect mood in user interfaces?
When it comes to software user interfaces, the color-mood effect isn’t really a thing.
Some web articles, infographics, and resources appear to be based on the mistaken assumption that the color-mood effects of physical spaces can also be applied to media.
However, for a color to affect your mood, you need to be surrounded by that color. Smaller patches of color, such as on mobile phones or computer screens, aren’t going to have that effect.
Color on our screens can have interesting and unexpected psychological and physiological effects on users. For example, particular colored backgrounds can have an effect on the performance of certain kinds of tasks, and the bright bluish light that pours out of our phones and tablets can negatively impact our sleep patterns.
But our understanding of how color affects mood in physical spaces—as limited as that understanding is—does not translate to user interfaces.
Conclusion
When it comes to selecting a paint color for a room, feel free to pay some attention to the color-mood charts. Or don’t. In most cases, color preferences will matter far more than pure mood effects would. If the room ends up looking pleasing and appropriate, you probably did fine.
But when it comes to picking colors for your user interface (or logo, or what have you), just ignore the color-mood effect all together.
But don’t worry, there’s still plenty to worry about.
With consideration of color-mood effects out of the way, you’re still left with all of the other important aspects of color in your UI. This includes aesthetics, setting user expectations, lending meaning to data and UI elements per culture and context, accounting for color vision deficiency in your users, etc.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
How to Prototype a Scroll Shadow in Adobe XD
Adobe XD doesn’t provide scroll state settings or scripting, but you can still imitate scroll shadow behavior in your prototypes. Here’s how.
Desired design
Let’s say you’ve designed this scrollable screen.
The header casts a shadow at all times when you run the prototype. But let’s say, for the purposes of keeping this article moving along, that this isn’t exactly what you want.
What you really want is a scrollable screen that displays the header shadow only when the content isn’t scrolled all the way to the top.
Adobe XD doesn’t support doing this directly via settings or scripting, but you can still simulate the effect.
The basics of scrolling in Adobe XD
First, let’s address the basics of how scrolling works in Adobe XD.
If you already know this stuff, skip ahead to the “Prototype a scroll shadow” section.
Scrolling elements and fixed elements
Adobe XD allows for vertical scrolling when the artboard height is taller than the viewport height. This just means that you designed a screen with more content than fits in the viewable screen area.
On a scrollable screen, every element on the artboard moves when you scroll, except the elements you’ve marked as Fixed Position. This means that if you want a particular element to stay put when you scroll, you’ll select that element and check the “Fixed Position” checkbox.
Layers of elements
Just because an element’s position is fixed doesn’t mean that the element will automatically appear in front of the scrolling content like you might intend.
Elements appear in front of other elements based on their position in XD’s Layers panel. Typically, you want the fixed elements to appear higher on the list than the scrollable elements. Otherwise, the resulting prototype will look odd when, say, the scrolling content slides over a navigation bar instead of under it.
Prototype a scroll shadow
Adobe XD doesn’t support element settings that let you automatically toggle a shadow on or off based on scroll state. Adobe XD also doesn’t support event triggers or scripting to allow you to program things like that yourself.
Still, you can pull off a good approximation of the scroll shadow effect in Adobe XD.
Here’s how you do it:
- Create a sneaky element that obscures the shadow when the content is scrolled to the top
- Arrange things so that the sneaky element slips in between the shadow and the rest of the header
1. Create an element to obscure the shadow
This part is simple. Create a rectangle that matches the color of the background and position it to obscure the shadow.
The sneaky rectangle will covers the shadow until it moves upward when you scroll, revealing the shadow.
However, when you scroll, our new rectangle will pass in front of the fixed header. That won’t look good, so we have to…
2. Make a “sandwich”
Your fixed header, including its shadow, is probably an element group. If you’re re-using the header on multiple screens, then you’ve made it a symbol, in which case it’s definitely a group.
You want your sneaky rectangle to pass above the shadow but below the rest of the header. That’s only possible if you rearrange the header a bit.
You need to make a layer sandwich: a top header layer without a shadow, a bottom header layer that displays a shadow, and the sneaky rectangle that will appear in between the two.
“Sandwich” steps:
a) Isolate the background of the header group.
b) Copy it, exit the header group, and then paste it as a new “under-header” element. Check Fixed Position for this new element.
c) Arrange the new element to appear below the header group on the Layers panel.
d) Keep the shadow on the new under-header, but turn off header’s shadow.
e) Arrange the sneaky rectangle to appear between the header and the under-header.
Limitations
This approach approximates a real scroll shadow you might implement in your website or app, but it’s not quite the same thing. Here are some of the limitations of this approach.
- The bigger the shadow, the more the effect of this approach—revealing the shadow from the bottom up—looks a little weird.
- If the shadow already overlaps the topmost scrollable UI element, then it’s not possible to obscure the shadow cleanly.
- If the background is an image or pattern or gradient, this approach isn’t very effective. Even if you copy a bit of the background to cover the shadow, you’ll get a “tearing” effect when you scroll.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
When Well-Meaning UI Text Makes Things Less Usable
If you want users to successful, it helps to know how users actually read your UI text (spoilers: they don’t), and how more text can ruin everything.
A real-life example of well-meaning UI text making things worse
Years ago, I joined a large desktop application project as the lead designer, taking over for another vendor.
One of my first tasks was to observe usability testing on the existing UI design. A realistic prototype of the desktop application had already been developed for that purpose.
One page of the application was a menu screen for navigating to discrete sections of the application. The menu consisted of 6 items. Each item was a large clickable icon button, with a button title and description text to the right of it.
The menu screen exhibited a surprising problem in user testing.
Usability Testing the Menu Screen
During user testing sessions, one of the tasks given to users was to update their data by downloading the latest data records from their device.
Usability results from the menu screen with regard to the download task included:
- Several users clicked on the title label first, and then when that didn’t work, they clicked on the square icon button to the left of it
- Several users clicked the 6th button (“User’s Manual”, lower right) to begin their download task, instead of clicking the 1st button (“Download”, upper left)
The first problem was not surprising. The second issue was very surprising. In each of the cases, the users in question navigated to the User’s Manual section, were disappointed with what they found, backed out the main menu again, and then picked the Download button.
Why did they go to User’s Manual section first? Was it to try to read help documentation about their task?
No. The users who clicked on the User’s Manual button did not do so with the intention of reading about how to download data. They thought they were navigating to the place where they could begin their task.
So why would any users make that mistake?
Well, part of it has to do with how users actually read UI text.
The way users “read” your user interface
Despite our earnest wishes, users don’t actually pore over your user interface and read all the UI text before carefully deciding what to do next.
No, users don’t really read your UI, they scan it.
Users have a goal. It might be paying a bill, or finding the answer to a question, or getting to content they want to actually read (maybe). Regardless, all the UI text they encounter along the way is just a means to an end. The user is scanning the landscape for words and elements that are applicable to their goal. And, if further navigation appears to be required, they are probably jumping at the first thing they notice that seems promising.
Once you know how users read your UI, you can focus on making your app or website more scannable. This includes hierarchical design, concise text, headings and subheadings that stand out appropriately, and emphasizing things that are important to your users.
Back to the problem with that menu screen
Okay, so users “scan”. But how the heck does that explain why users would click on User’s Manual instead of Download for a download task?
Scanning is part of it. Users’ knowledge and unintended consequences are also part of it.
Aside from the button labels being neither clickable nor part of the button, the problem we observed with the menu screen was the “helpful” description text below each button title.
Some users were clicking the User’s Manual button instead of the Download button because of that descriptive text, combined with some knowledge of what the task would entail.
Many users already had a good idea that downloading data from their device would require connecting their device to the PC via cable.
And some of those users, when scanning the UI text, saw the “connecting devices” bit, and—perhaps while thinking, “that’s what I need to do next!”—clicked the associated button.
Note what these users (likely) did not do.
These users did not circle back to the top to see if any other buttons were a better candidate for their download task. These users did not even look up a half inch and chew on the fact that this was the “User’s Manual” button, and therefore probably not what they want. A user’s attention can be extremely narrow.
The description for the User’s Manual button could have been written any number of ways. The unintended consequence of how it happened to be written caused a surprise usability issue.
But rewriting the description text would not have been the right solution to the issue.
A problem of superfluous UI text
The description text, while well-meaning, caused more problems than it solved.
When it comes to scanning, the description text made scanning harder for users.
- More text to scan through
- The additional description text either took more time for users to scan or was actively ignored
- More text competing to define the meaning of a UI item
The description text was also a bad idea for these additional reasons:
- It was mostly unnecessary – most of these buttons had no need for examples.
- It feigns importance – the descriptions’ mere existence made them seem worthy of attention—more meaningful than the button labels, even—but they were not.
- It diluted the meaning and importance of the button labels, which were pretty effective on their own.
- It was misleading to users – once you start listing the contents of a section, if you can’t list everything (and you probably can’t) then users might think that a lack of mention means it’s not in there.
Lesson: Optimize your icon-and-label pairings, and keep labels meaningful but concise. That should almost always be enough. Avoid the temptation to add text to help “explain” things. Or, at the very least, test with minimal text first, and then see if you need to add anything to address actual usability issues.
The menu page that worked better
An iteration on the UI design proved to eliminate the Download / User’s Manual problem, due to simply removing the description text and making the button labels stand on their own.
This would not be the final design for the menu screen, but making this quick change to the prototype between rounds of user testing showed that the problem was indeed understood (well enough) and effectively corrected.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
-
Announcing ErliBird + Instabug Integration & the New Instant Bug Test
We’re happy to announce that ErliBird (Now BetaTesting.com) and Instabug have joined forces to make it easier than ever to recruit bug testers and get actionable bug testing results in as fast as one hour.
On ErliBird, we have created a new Instant Bug Test package, which makes it easy to link ErliBird and Instabug. This new test provides a great way to recruit targeted testers from ErliBird to conduct on-demand bug testing for iOS and Android apps. By integrating the Instabug SDK in your app and connecting to ErliBird, your testers will be able to submit bugs directly in your app, with additional contextual information to help you discover and squash important bugs.
The Instant Bug Test (designed exclusively for Instabug customers) is inexpensive and you’ll typically start to see results within just 1 hour of starting the test once your company is approved for self-service submission. When planning your timeline, note that we will manually review your company’s first test submissions, which can take 3-24 hours. Once you have a clear understanding of how to design bug tests using our tool, we’ll activate your account for completely self-service submissions.
In addition to the Instant Bug Test, ErliBird is also offering Instabug clients that require more in-depth testing a 15% discount on any ErliBird Beta Testing package. Just contact ErliBird and mention the Instabug discount. Likewise, Instabug is providing ErliBird customers with a 15% discount on all paid plans.
What is possible with the Instant Bug Test?
Exploratory Testing
In an Exploratory test, your testers will explore and report bugs they discover, without any specific guidance from you. This is the easiest and fastest way to get started with an Instant Bug Test with minimal setup. You can optionally provide a basic description of what you’d like testers to focus on, along with a list of known bugs and issues to avoid.
QA / Functional Test Cases
Run a functional QA test with set of test cases to test specific functionality and features within your app. When users run into an unexpected or failed result, they’ll submit a bug report detailing the issue. Mix functional test cases with UX or UI based survey questions for a robust and powerful test.
UX Feedback (with Bug Reporting)
Design a custom test process for your testers and create a set of tasks and survey-based questions for your testers to follow. Whenever a tester runs into a bug or issue during this process, they will submit a formal bug report using Instabug. You can decide how general or specific you’d like the test process to be: For example, you can provide only a few high-level instructions if you’d like (e.g. register, complete your profile, etc), or you can provide very specific test cases (e.g. Click on the package icon. Do you see an image of the package?).
How ErliBird + Instabug Integration Works
During the test setup process on ErliBird, you’ll be given a WebHook URL. Within Instabug (Settings->Integrations->WebHook), create the WebHook to send your bug reports to ErliBird. See this training video to learn how.
Instant Bug Test FAQ
What is the Instant Bug Test?
The Instant Bug Test allows you to recruit real-world bug testers to test your app and generate bug reports and feedback. Once your company is approved for self-service submission (without ErliBird review), you’ll be able to launch tests on-demand and start to get results within 1 hour. Your test can be Exploratory (users explore the app on their own to discover and report bugs on their own), Functional (driven by formal tasks and test-cases) or a mix thereof.
Can we customize our test process?
Yes, you can design your own set of tasks, questions, and formal test cases.
Do we need to design our own test?
No, if you’d like, you can use our Exploratory Bug Testing template which requires absolutely zero setup of the test design process. Users will explore your app on their own to discover and report bugs they encounter.
Can we target a specific device or operating system version?
At the launch of the Instant Bug Test, we’re allowing for some customization of operating system versions and device types (e.g. Most popular, older phones, etc). Shortly, we’ll be launching the ability for full customization of the operating system versions, device manufacturers, device models, and more. What’s better, these are not lab-based devices or even cloud devices. These are real world users that own and use these devices every day.
Need More Robust Beta Testing?
Instabug Customers Get a 15% Discount On Our Beta Testing Packages.
Need something more in-depth? We also offer our full Beta Testing product with Instabug integration. Our beta tests provide quality in-depth beta testing and user experience feedback from targeted real-world users over 1-week test iterations. We provide a Project Manager and provide our industry expertise to design a successful beta process. While our new Instant Bug Test is a single session test process (i.e. testers use your app in one sitting to explore and report bugs over 30-60 minutes), our Beta Testing process is perfect for tests that last days or even weeks, and include multiple sets of tasks/questions during this testing process.
This makes it possible to run tests that match your real-world organic usage scenario. For example, need 100 testers to play your new Steam game together and provide feedback on the experience? No problem. Need 50 testers to use your new News Reader app each day for a week? Solved. Need users to track their sleep with your sleep tracking app and help hunt down all of the bugs and technical issues? You get the idea (we can do that).
About Instabug
Instabug is a comprehensive bug reporting and in-app feedback SDK that is helping companies worldwide build better apps. With just one line of code, beta testers and users can report bugs and provide developers with detailed feedback by just shaking their phones. The level of details Instabug’s SDK grabs with each bug report attracted tens of thousands of companies like Lyft, T-Mobile and eBay to rely on Instabug to enhance their app quality and iterate faster.
Check this link to know more about how can Instabug help you receive better feedback.
About ErliBird
ErliBird gives you the power to beta test with real people in real environments and collect on-demand user feedback for Android, iOS, websites, desktop apps, and tech products. Powered by a global community of 100,000 real-world testers.
-
Real-Life Lessons from Design Testing Failures
Whether you’re a startup or a mature corporation, you should user-test new features and UI designs. Sometimes design testing will end in failure, but you can learn from your mistakes, as well as others’. Here are some lessons learned from real-life design testing failures.
When you redesign your product, you do it to satisfy your users in a way that meets your business goals. If you fall short, it could cost you. So it pays to test your new features and UI designs with some of your users before rolling those changes out to the whole world.
You’ll find, however, that design tests often fail—meaning that your new design didn’t perform better than the old one.
Take solace in the fact that those failures happen to everyone. Take heart in the fact that there’s a lot you can learn from those failures. And take some of the lessons learned by others and use them as your own.
Here are some real-life examples of design test failures and lessons-learned from two companies: a startup you may have never heard of, and a juggernaut that you definitely have heard of.
Groove’s neutral results
Helpdesk software provider Groove wanted to increase their conversion rates: more landing page visitors signing up for the free trial, and more marketing email recipients actually opening the email.
The startup experimented with different design and content tweaks. The changes included color and copy choices on website pages and subject-line text choices on marketing emails.
The changes Groove experimented with were not random ideas. They came from conventional wisdom and credible sources who found legitimate success employing similar changes. All sounded promising.
Groove individually tested their many design variations using A/B tests.
Most of them failed.
When failure looks like no difference at all
Failures aren’t always dramatic.
Sometimes you test out that new design you think will work better… and it works just about the same as the old design. It’s not a spectacular failure, it’s just “meh.”
Groove experienced a lot of these shoulder-shrug “failures”. Company founder Alex Turnbull straightforwardly calls them “neutral results”.
Groove’s design testing included trying out different colors on call-to-action buttons, and listing prices in different suggested forms (e.g., “$15” vs. “14.99”). Groove tested these and other types of design variations, but often found the results to be inconclusive.
When an individual test has neutral result, it can be difficult to draw any meaningful conclusion.
For Groove, lessons arose from the aggregate of their design testing efforts.
Lessons
- Expect failures. For each winning result, you’ll rack up a whole bunch of failures.
- Don’t rely on “proven” design tricks. Tactics that worked great for other companies:
- May not apply to your particular audience
- May not work well in your particular design
- May have lost effectiveness over time
- Optimize your designs AFTER you’ve settled on a well-researched approach that is specific to your users.
Quote
From Groove Company founder Alex Turnbull:
[…] one of the most important lessons we’ve learned as a business is that big, long-term results don’t come from tactical tests; they come from doing the hard work of research, customer development and making big shifts in messaging, positioning and strategy.
Then A/B testing can help you optimize your already validated approach.
Netflix’s failed feature
Netflix had an idea for a new feature to add to their home page that would increase new user sign-ups.
The folks at Netflix are experts at A/B testing, so naturally they A/B tested their new design before rolling it out to the whole world.
It failed.
Undeterred, the product design team created variations on design and approach for the new feature. Over the course of a year they tried these variations out in four additional A/B tests.
They all failed.
What’s going on?
The feature in question: allow potential users to browse Netflix’s catalog of movie and TV offerings before signing up.
Netflix had very strong evidence to believe this feature would increase user sign-ups. Users were requesting the feature in significant numbers. The design team liked the idea, too. It made a ton of sense.
But in every test, the home page with the browse feature performed worse than the home page without the feature. The sign-up rate was simply lower whenever the new feature was available.
Over time, Netflix came to understand why the browse feature was a failure. This included learning more about their users and learning more about their own product. They were hard-fought lessons, but valuable ones.
Allowing potential subscribers to see what Netflix had to offer? At its core, this was still a good idea. But the “browse” feature was the wrong approach.
Part of the reason for this, the team learned, was that to really see what Netflix has to offer, you have to actually use Netflix. The customized experience of the service is the key, and that experience is not captured by impersonally browsing the media catalog.
The barrier to entry for potential users was already low: a free one-month trial. So the goal of the Netflix homepage should be to direct potential users to the free trial. The browse feature, in all of its incarnations, was actually a distraction from the conversion goal, no matter how it was designed.
In the end, a static background image that gave users an impression of Netflix’s breadth of offerings was better than a full-fledged browse feature. And directing visitors’ focus toward the free-trial sign-up was far more effective.
Lessons
- Users don’t always know what they need
- Fully understanding what makes your product experience special to your users will help you make better design decisions
- Don’t distract your users away from the goal
- Test your new design before rolling it out, even if you’re *sure* it will work
Quote
As Product Designer Anna Blaylock said about the string of tests: “The test may have failed five times, but we got smarter five times.”
Design testing: Better to try than not try
All in all, testing designs before rolling them out to all your users is wise, and relatively inexpensive:
- only a small portion of your user base see the experimental interfaces while the tests are being run, so any negative impact is minimal;
- despite the many likely failures, there are valuable lessons to be learned…
- let alone the occasional “big win” successes that make your efforts worth it.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
BetaTesting Blog 