Analyzing UX of UXPin – the rabbit hole goes deeper and deeper
One of the very first things I learned at Lucid Agency, so many years ago, was how to use wireframing software to create website prototypes. For years, I used Balsamiq mockups for all of my prototyping needs. Balsamiq is a fantastic solution, with a native desktop as well as a web-based option.
I consider Balsamiq a low to mid fidelity wireframing solution. To me, low fidelity mockups are great for quick-and-dirty sketching, producing several screens quickly, and separating “design” from wireframing.
However, as my career (and Lucid Agency itself) progressed, I found that Balsamiq alone was not an appropriate prototyping solution for all of our clients. As a project manager, one of the hardest lessons to learn is that you have to be flexible to meet the needs of vastly different clients.
To solve this problem, we signed up for UXPin. UXPin is a high-fidelity mockup solution that offers greater flexibility and a less “cartoon-like” view than Balsamiq. This is great for situations where a project is farther along in the lifecycle, or when I am trying to communicate something more complex. Now, I use both UXPin and Balsamiq, depending on which one is more appropriate for the situation or client. Interestingly, I do not find that the hi-fidelity UXPin mockups take much longer to create than the lo-fidelity Balsamiq mockups.
The learning curve for the program was relatively easy, though this might have been due to my familiarity with Balsamiq and Photoshop. I would imagine that users coming in without that background may have a more difficult time learning conventions such as layering and grouping.
For onboarding, UXPin offers video tutorials, as well as a sample project. I found the sample project on the dashboard to be the most helpful tool, because I was able to drag around and edit existing elements of the sample project to get a feel for the mechanics of UXPin. From there, I jumped straight into making a “dummy” project of my own, and felt pretty comfortable with the program after about 4 hours. I’ve been UXPinning for about 3 months now and I love it!
My creative director Jeremy, recently reached out to a contact at UXPin who connected us with a member of UXPin’s user-experience team. We totally geeked out when UXPin asked us if we’d like to jump on a call to share our feedback about the program, specifically, any issues we experienced with the user experience in the UXPin interface.
We were pumped! We thought this would be an especially interesting experience for us, since we’re usually on the flip-side of UX testing. It felt like Karate Kid in reverse – “ah, now the teacher becomes the student!”
Preparing for the call was not difficult. I use UXPin nearly every day, so I simply made a list of the features that I love and the features that give me problems. On Monday, we spoke face to face (thanks Google Hangouts!) with Ben from UXPin. We started with some basic feedback about the onboarding process, then I jumped into my “gripe list”.
A few times on the call, Ben jumped in and let me know that a feature I was asking for actually already existed, and was able to show me, via screen share, how to access the feature. This was great for me because it instantly solved some of my problems, but also super beneficial for Ben because it gave him insight into features that power users might think are difficult to find.
As I went through my list, we collectively began to realize that several of my “gripes” were actually related to taxonomy and meta-tagging. For example, the mobile-menu hamburger stack icon, which I use constantly in my prototypes, is listed in the search as “reorder”:
The “comment” icon, which I also use frequently, is listed as “pin”
To me, these meta keywords are dissonant and made these important elements difficult to use. The overarching suggestion that evolved from this subset of “gripes” was to evolve the meta data for program elements so that each element could be tagged with more than one keyword, thus making it easier for users to find. Ben mentioned at the end of the call that this was his number one takeaway that he would discuss with his engineering team
The call was great for us because it instantly improved my experience with UXPin. At the end of the call, I knew how to do things that I had no idea existed. Jeremy and I also relished the experience of being the UX-testers for once, rather than the UX-analysts. Going at it from the other direction once in a while is great because it gives us experience that will help us tailor our questions, attitude, and response to UX-testers in future projects.
Perhaps most importantly, it gave us a conduit to UXPin so that we can submit feature requests and report bugs with ease (thanks Ben!). My hope is that UXPin will be able to address some of our requests in future releases to make the user experience better for everyone!
Overall, I am so appreciative of UXPin being an open company that welcomes feedback from its users. Software is always iterative. The only way to thrive is to constantly update your product. We preach this to our software clients every day! It’s great to see a company whose software we use daily actually adhere to this principle. This gives me confidence that UXPin is serious about its product and is definitely here to stay. This already solid product will likely get better with each release! I can’t wait to see what they come up with next.
For a complete list of my “gripes” please read on! I will update this list as UXPin solves these issues. If any of our readers have any suggestions on workarounds for any of these issues, please comment below!
- adding subpages to the page tree (Ben showed me how to do this on the call, it’s as easy as drag and drop)
- color eyedropper tool (funnily enough, this eyedropper tool had not existed when I made my list, but was there by the time we got on the call with UXPin. Talk about moving fast!)
CONFIRMED BY UXPIN TO BE COMING SOON:
- ability to create your own “customizable libraries” of elements (Ben said this is coming soon!)
- hard return when leaving comments submits comments – would like opportunity for paragraph breaks in comments (UXPin is working on this)
- adding Google Map element (Ben let us know that we could accomplish this ourselves once the Customizable Libraries upgrade is released)
- adding Google material design elements (Ben let us know that we could accomplish this ourselves once the Customizable Libraries upgrade is released)
NEW IDEAS GENERATED FROM OUR CALL:
- grouping within groups
- more options for leaving comments; changing the meta search tag for the “comment” element
- autoexpand sitemap by default on preview link
- default to “auto-resize” setting on preview link
- line element to be searchable by “rule” or “horizontal rule” and mobile menu icon to be searchable by “menu” (Ben’s biggest takeaway from the call was expanding the meta tag search options for elements in the library)
- saving color libraries on a project-by-project basis rather than globally
- ability to edit smart elements globally as well as locally
BUGS IDENTIFIED ON THE CALL:
- deleting a responsive breakpoint from a single page on a project deletes that breakpoint across ALL pages in that project (Ben said this was a bug they’re aware of)
- icon search bug when searching through “all” icons (another one the UXPin team already knew about)
- cutting or copying from within a group to outside a group
- where’s the zoom? (Such an oft requested feature that it is apparently a joke at the UXPin offices)