Weekly UX and User Research Roundup

In case you missed our earlier posts, here are our recent posts from guest bloggers, JustInMind and Cyrus Innovation, as well as a roundup of some UX articles that are great reads!

Recent Guest Posts on our blog…

Collaborative Prototyping to improve the design process
By Victor Conesa, VP of Product at Justinmind
Web design is becoming a more collaborative process, and we require tools that can support us with this. Read the full blog post on Collaborative Prototyping to improve the design process to learn how a collaborative prototyping platform can improve the design process, serving as a communication tool to integrate everyone involved in a project.

JustNotSorry: A Lean Case Study
By Tami Reiss, CEO at Cyrus Innovation
We love how Tami and her team developed and launched their app, JustNotSorry using solid Lean practices and are excited to share their story with our followers. Read about the steps they took that are based on solid Lean and Agile practices that led to the successful launch: A Lean Case Study

User Research & UX Weekly Roundup

  • The Business of User Experience
    By Jonathan Beckman, Founder of Apptourage, on InvisionApp.com. “Delivering a top- notch user experience is about more than effective product design – its good business.” David gives you the business case for investing in UX.
  • Usability Testing: Don’t Guess, Test.
    By Jacob Creech on uxbooth.com. “Just because nobody complains doesn’t mean all parachutes are perfect. The same goes for web design; usability testing is often overlooked by clients and designers alike, but the value that can be gained from it is immense.”



Collaborative Prototyping to Improve the Design Process

horizontal-logo-colorThis is a guest post from Victor Conesa, VP of Product at Justinmind. Validately is excited to team up with Justinmind. Validately’s tools will be available to Justinmind users later in January.




Web design is becoming a more collaborative process, and we require tools that can support us with this.

For any company that produces apps and websites for its clients, one of the risks is in fact that after weeks or even months of hard work, the intermediate product releases may not meet the clients’ expectations. There are many factors that cause this, however one of these is certainly lack of effective communication and collaboration with all project stakeholders during the design process.

In this post we will explore how a collaborative prototyping platform can improve the design process, serving as a communication tool to integrate everyone involved in a project.

Fill the communication gap with a prototyping tool

Collaboration is a key component of web design thinking and it is enhanced only when the right systems are in place to facilitate efficient communication. In the software world this is crucial, because one of the biggest challenges is to communicate how the design is going to come across in the business world, to people who don’t necessarily speak the same language (tech, or otherwise). It’s only after seeing the ‘final’ product that people really understand and can explain what they actually want.

Prototyping platforms are the obvious solution to fill this communication gap between the business world and the software design world, because thanks to high-fidelity simulation features and highly interactive wireframes and prototypes, clients can actually see a near real-life app or website before developers have even started to code.

“Requirements definition has always been a problem in software, and making it come to light with interactive prototyping really made a difference to a lot of people”. (J. Bellis, Elsevier, Justinmind User, read his story here).

Optimize Collaboration

The web design process is built upon creation, communication, collaboration and validation. Collaboration tools help to boost productivity, especially in larger enterprises where there are distributed groups of designers involved. And when you look at it from the client’s standpoint, where many are coming from all over the world and different working environments, collaboration management is key to keep everyone informed.

Furthermore, the input of other people, who may be directly or indirectly involved in the web design process, is crucial to any type of project. What we do alone we can always do better with the help and feedback of our peers.

Let’s think of all the times you’re getting close to your desired output but you’re just dried up. Then someone comes in suggesting a small change and suddenly everything makes sense.” (M. Lukkarinen, Tieto, Justinmind user, read his story here).

When it comes to prototyping, the whole team should be able to edit and make changes to prototypes together. One person or a small team can easily produce a fully functional prototype that lets the client see and experience a coherent model of the app or website early on. All potential kinks can be ironed out efficiently at this stage, if an appropriate collaboration system is put in place.

Collaborate with your team to create your prototypes

Now the design process can start. A great way of working together is to create a shared prototype at the beginning of the design process, so that the whole team can comment, edit and adapt it simultaneously. Consider sharing assets with your team, keeping the same design code throughout a single project and all the others, thus enhancing brand consistency and improving productivity, as things won’t need to be redrawn.

Furthermore, during the creation process, it’s key that the chosen prototyping tool makes it quick and easy to share the prototype online. The prototype should also be available to view in any browser or device so that the simulation is always available for any type of reviewers to give feedback.

Share and review your prototypes online


Once the first process of creation ends, you’ll have a first design that can be evaluated to check whether it meets the corresponding needs and expectations. Taking advantage of the online account, the prototype can be shared online with clients and users, who can review it and leave useful feedback. To ensure the success of your final product, giving and receiving feedback at the prototyping stage is essential. Feedback is a powerful tool that has become a requirement of the design process. It is conducive to effective teamwork, as it gives everyone the opportunity to voice their opinion at all stages of the process. Moreover, feedback from users is crucial to understanding where our focus should lie when addressing customer needs.

Having detailed screens and a complete view of the overall end user experience allows for real-time testing, iteration and validation. Mapping and testing the entire design enables the designer and reviewers to consider the overall UI and flow as well as the details, and to check for requirements and specifications compliance.

 “I can share the prototype through the cloud with my colleagues and clients, and get their feedback, and then quickly do the requested changes and put it back to the cloud to let the clients see it. They are so happy when you do that”. (M.Lukkarinen, Tieto – Justinmind user)

Once the content and features are set and validated, a more detailed and high fidelity prototype can be built based on feedback, and the iterative design process can start again.

To learn more about collaborative prototyping with Justinmind, read on here, or try it for FREE getting the PRO TRIAL version here. Some of our best collaborative features include Publish, Share and Review Online, Real-time Collaboration, and Online and Offline teamwork.


JustNotSorry: A Lean Case Study

This is a guest post from Tami Reiss, CEO of Cyrus Innovation, about the app they built called Just Not Sorry which was an instant internet success. We love how Tami and her team developed and launched their app using solid Lean practices and are excited to share their story with our followers.

Tami_Headshot_SquareTami Reiss is CEO at Cyrus Innovation, a NYC based software product studio that improves the design processes with companies. They believe quality, people, practices and code are pillars of business success. She leads the Cyrus team to deliver great results for their clients. Over the past 10 years, Tami has worked with teams to develop technology solutions on platforms ranging from mainframe systems to modern microservice architectures and iOS.

We launched JustNotSorry two weeks ago and oh what a journey this has been! In a matter of days, we have had tens of thousands of installs of this application. We’re pretty sure that if the app worked on more than the combination of Gmail + Chrome that the usage would be even higher. (We have the dozens of emails and tweets requesting it to work on Outlook as proof.)

How does an app or anything else go viral? The instant success of JustNotSorry is a testament to a number of things.

First, this app is FREE! JustNotSorry is a Gmail plug-in that helps you be a better communicator. If you are trying to get ahead in your professional life, downloading this app provides some of those “smart is simple” moments where it is essentially a no brainer. [Just Not Sorry underlines words that tend to detract from a reader’s confidence in your message such as “just”, “sorry”, and “I think”.]

Second, it was a slow news week when we launched and hundreds of blogs, radio shows, and even some TV shows picked up the story because there wasn’t much competition. I’ve learned to never underestimate the power of press and good PR to spread the word.


Third, and potentially most importantly, we designed the app using Lean/Agile principles. Here are  the steps we took that are based on solid Lean and Agile practices that led to the successful launch:

  • Quick idea validation : When we first thought of the idea, we told a dozen people about it. Everyone said they loved it, but only when Kara Silverman offered free PR services from her company for the app did we know we were on to something. As Steven Cohn (the Founder of Validately) said at LeanUX15, unless someone is willing to provide you their time, money, or social capital, they don’t really love your product. Kara was willing to give us all three. As we shared the app with some beta users, the most common response was “when can I share this with my whole team?”. That’s pretty strong validation.
  • Know your ideal user : Can Just Not Sorry be used by anyone? Sure! Did we build it for everyone? Absolutely not! The key to any MVP is knowing your ideal customer and building something to meet their specific need. Our product design centers on a 25-35 year old woman, working to advance her career but weak communication is getting in the way. She wants to change, and we built a tool that nudges her to be more mindful about word choice in email. Knowing our target user also led to very focused marketing for the launch. (Possibly too narrow as it created a backlash against us for policing women’s speech when that wasn’t our intention… but that’s a story for another blog post.) We tailored the messaging and the outreach to women in this age range and encouraged them to spread the word to their friends. Some of the emails we sent were opened over 400 times thanks to key people forwarding them.
  • Build small : The app only works on Gmail on a Chrome browser. Could we have built it for a variety of email clients and browsers? Of course! But, why would we invest that time and money unless we were sure it would take off? When people complain that Outlook isn’t supported, we show them that we’ve open sourced the code for anyone to leverage and build it if they want. If there’s a real need for the product, others will make it a priority to help. I’ve often said an MVP should be able to be made within 6 weeks, Just Not Sorry took only 4 days before it was ready for beta testers.
  • MVPs aren’t perfect : As Lauren Gilchrist preached at Lean Startup Conf in 2014, “Be a scientist, not an expert, and ship imperfect products. We knew that there were some conflicts with other gmail plug-ins that would cause the app not to work all the time. Rather than try to fix all of the issues ourselves. We shipped it anyway, knowing only a small percentage of people would be impacted and that they’d help us diagnose the issues if we were responsive.
  • Test with actual users : Every step along the way we spoke with potential users about their thoughts on the app. We gathered feedback from our target market to ensure we were headed in the right direction. A “short” list of some of the things we tested:
    • The name – It was originally “Don’t Say That”, can you imagine the hashtag or the backlash that would have created?
    • The look and feel –  We switched from highlighting to underlining the trigger words so that it looked like spell check. We were having difficulty explaining that the highlight wouldn’t be visible once the email sent, it wasn’t intuitive. By using a familiar element, we took away the need to explain. We received not a single question about this.


    • Marketing e-mail subject – If you were part of the 10k people we emailed on day 1, you saw “We’re Just Not Sorry” in your inbox. Our tests that led up to that had longer subject lines that mentioned Gmail, they didn’t create as much intrigue or as high of an open rate. Many of my friends reported opening the email simply because they wanted to know what I was sorry for.
    • Landing page content – At launch there were three versions of www.justnotsorry.com built on Instapage each with different copy but identical layouts. Within a day, one of the variations was a clear loser so we paused it. After the press picked it up, we added references to the press coverage and created two one more variations: one with logos and one without. The option with no logos performed 1.3% better for conversion, but we decided to keep the logos anyway.
  • Iterate often : The app went through 3 iterations during the 7 days we built it. Aside from the highlight to underline switch above, big changes included the addition of helpful hints when you hover. This came from the realization that most people who use the phrases at the inappropriate time don’t realize why it’s a problem. One week after launch, based on feedback we’ve received, we changed the color of the underline to make it more distinct from spell check and added “trying” as a trigger word.
  • Tie into human behavior : The promotions we did for JustNotSorry are attractive to the top of Maslow’s hierarchy of needs; people want to feel part of something bigger than themselves (esteem and self-actualization). One of our advisors suggested that we make this a New Year’s resolution, part of someone’s annual routine. Similarly, we noticed that more shares happen on Twitter and Facebook when there’s a common goal, so we created a target of 10,000 signatures by NYE. Hooks, such as these, attach people to a greater purpose and often creates virality.
  • Guide people : Good user experience design is all about getting a person to take the right action without instruction. When the first visitors on our site didn’t do anything more than provide their email, we moved the download link to action #1 and providing email to second place. Similarly, rather than only encouraging tweeting, the redirect after providing your email goes to a ClickToTweet pre-formed, “lazy” tweet, which takes only a split send to post.





  • Measure the important stuff : We spent over a day adding Google Analytics so we could track the number of installs. It was really important to be able to know that, not only for ourselves but for the marketing campaign around getting a certain number of signatures by New Year’s Eve. Instapage tracked pledge signatures, but only Google Analytics could track all of the downloads from all sources. By keeping track of these figures and promoting them, we were able to get users and the press pretty excited and our app virally spread across the world, 140 countries and counting!


JustNotSorry has been a huge success. We’ve been covered everywhere from the BBC to the Today show, every women’s magazine, and even some newspapers in print. We had tens of thousands of downloads in a matter of 2 weeks for something that only a portion of the population can even use. We attribute our success to building a smart simple product and using the Lean methodologies of validating, testing, and iterating. Could we have been wrong? Absolutely! But we only spent a week or two working on it, so there wasn’t much to lose.

If you’re interested in building something small and fast to meet a market need, setup some time with Tami and her team at Cyrus Innovation and then work with Validately to test your product with real users.

Product Management Thought Leaders of 2015

Thanks to Alpha UX for including our founder Steven Cohn in their Top 40 Influencers on the 2015 Product Management Year in Review. Steven is profiled with other thought leaders such as Marty Cagan, Ben Horowitz, and Sam Altman. Read Steven’s Profile below.


Steven Cohn // Validately

How to Collaborate with Prototypes

horizontal-logo-colorValidately sat down with Victor Conesa, VP of Product Management at JUSTINMIND, the wireframing and prototyping tool, for an in-depth discussion on how to collaborate with prototypes, best practices prototyping for mobile, and more. Validately is excited to team up with Justinmind. Validately’s tools will be available to Justinmind users in early 2016.

Collaboration is crucial to successful protoyping. What are best practices for collaborating and getting buy-in from stakeholders?

Prototypes serve as a communication tool. A lot of time and energy is invested in the software industry to describe how an app or a website should look. This is generally done through specification documents and diagrams, but very few people read them, and even fewer understand them.

In the end, the only thing each and every software project stakeholder (i.e. executives, Business Analysts, UX designers, developers etc.) understands is the final application or something that looks very much like it.

Use a single tool to enable an efficient and collaborative prototyping process. At each step of the prototyping process, a good prototyping tool should enable collaboration and make sure that everyone in the team and the stakeholders are on the same page. The cost of rework should never be underestimated.

A Shared Prototype should be created at the beginning of the design process, and the whole team should be able to edit and make changes to it simultaneously.

During and after the creation process, it’s key that the prototyping tool makes it quick and easy to publish and share the prototype online or on remote user testing tools. The prototypes should be available to view in any browser or device so that the simulation is always available for any type of reviewers to give feedback.

The project owner should have complete control over the people who can access and review it. Managing reviews and comments, and being able to link comments to any specific feature or requirement is important too. The tool should also organize these elements well so that no details get lost.

When the reviewing phase comes to an end, the web or app prototyping building cycle can re-start, enriched with feedback and comments from all the interested parties. Published projects should also be easy to replace with updated versions.

For all of these reasons, we created Justinmind, so that all project stakeholders could clearly communicate between each other, and define together the application or website they want to build. And that’s also why we focus so much on all the collaboration and teamwork features (such as shared prototypes, online reviewing and commenting, versioning) that make Justinmind a great collaborative prototyping platform.

Collaboration and teamwork features are even more important in our Enterprise version, you can contact us to find out more about it.

What are some tips for mobile prototyping?

Test what you’re doing in a real mobile device. Testing mobile gestures and visualizing your app in the right resolution is key. You can’t just imagine it and leave it up to fate. In Justinmind we dedicated a lot of time and effort to make sure that this step is simple, so that immediately after defining a web or app prototype, it can be tested on an actual device by anyone. Putting the prototype in the hands of real users in a real environment also helps to detect conceptual errors and inconsistencies in the apps or websites.

Validately’s tools will be available within Justinmind in early 2016.  Click here for a demo of Validately.



What’s the difference between wireframing, prototyping, and hi-fi simulating?

Although there are many people who mix the terms, usually a wireframe refers to a schematic representation of a page or screen that does not contain any type of design. It serves the purpose of validating the elements that will go into a given screen, their size, the way they’ll be distributed, and so on.Wireframing generally doesn’t imply any sort of interaction.

However, a wireframe can’t convey important design components. Grey boxes and lorem ipsum content can’t communicate how colors and contrasts will influence content, the visual impact of brand design, the visual weight of graphics element and the visual path created by colors, contrasts and components. Additionally, a wireframe can also look dull and little attractive to a client when the real design is meant to be very effective and impacting.

That’s where prototyping comes in. Prototyping is often used to display interaction and it includes design too. According to my view, a prototype should be something that allows to test the experience of a user with the software that is being designed. In the same way as a car prototype is a real car you can sit in and drive, a prototype of an application should be something very similar to a real app, which you can actually use and test the user experience with. A prototype is functional: you click, you go to another page; you fill a form, you get real data and use them. And much more.

Hi-fi simulation is a complement to all this: you have a fully interactive prototype when you can simulate and test it in high-fidelity, i.e. when you can convey a high-tech representation of the design concepts, resulting in partial to complete functionality, ideally on the actual device. You don’t have to explain, or trust your client’s capabilities of imagining an app or website: what he sees is what he gets.


When is the right time for wireframing vs. prototyping?

Wireframes may be useful in the early stages of a project as long as no interaction plays an important role in the represented screens. For example, when designing web sites, usually the weight of the design is more on the content than on how the user will interact with it (although this is something that is slowly changing because websites are getting increasingly interactive). So a wireframe can be useful to set a number of screen layouts without having to involve the graphic designer, describing the general content, and the basic layout and interactions.

However, if the screens have a lot of interaction, you should move to a prototyping phase. Imagine Facebook defined only with boxes and arrows, clearly not enough. High-fidelity prototyping lets you show relations and rich interactions with a “file” that works just as if it was the real website or app, reacting and interacting with the user.

A final step is validation and testing, performed through hi-fi simulation with real users and project stakeholders.


How does Justmind help with wireframing, prototyping, and hi-fi simulation?

Consider the following scenarios:

  • You’re a designer, and the programmer didn’t understand that tiny little detail that makes a huge difference to the final product.
  • You’re a coder and need to know exactly what to code, and not change it every other day.
  • You’re a UX Designer, and need to test everything, but it takes too long and it’s very expensive to get it all tested.

That’s where Justinmind comes in and makes a difference letting everyone involved in a project see, understand, approve and start working on the real, final version.  Justinmind is a WYSIWYG drag and drop tool that can be used both to draw wireframes and to build fully interactive prototypes.

Justinmind also integrates with the most popular design tools, and includes advanced navigation and simulation with real data, in order to create prototypes so realistic-looking that a user might not be able to differentiate them from a real application or website. Data simulation comes in particularly handy: there is nothing like data visualization to give you and your client a clear understanding of how the project is going to work.

This way, you can test your future app or website before starting to develop it, and with no coding skills. It’s drag and drop, by learning some basic commands and tricks, anyone can create some advanced navigation interactions.

As far as hi-fi simulation is concerned, in Justinmind you can simulate your prototypes in any browser, choosing actual devices’ simulators, where you can simulate mobile gestures too. Most importantly, through our app, it is possible to simulate on the actual devices.


How can I test my Just in Mind prototype? With whom should I be testing my prototype?

Justinmind is a very versatile and flexible tool, and you can perform all sorts of tests with it.

The Simulate button lets you work with the prototype directly on your browser and realize moderate testing remotely or in person, in an extremely easy way.

The advanced commenting system, the simulation features and the possibility to upload your prototypes online allow you to share your designs and let other users simulate and give feedback without the owner of the prototype needing to be there in person.

Also, since the simulation basically uses HTML5, it is possible to integrate the prototypes with testing tools, like Validately. And this can simply be done with a click from our online platform.

As far as who should test the prototypes: the more the better. Ideally, prototypes should be tested with potential users but it’s also very useful to test them with developers, and in general with anyone involved in the project, in order to make sure that the plan has been correctly understood by all contributors.