UX pros, what are even doing with these prototypes
April 18, 2019 12:11 PM Subscribe
I know that this isn't a UX-focused forum and this is a very niche question but here we go. I'm a UX designer and I really like using Axure because it lets me quickly mock up realistic interactions with conditional logic and a data set that I can manipulate easily. For a bunch of reasons I've been tasked with looking into alternatives and I'm not having much luck.
When I'm designing things I like to be able to set up how I think the interaction should go, and then click through it to see if it feels natural. As I'm clicking through it, things that are missing or that I need to change become apparent because my brain is in that mode. Having to manually draw all the possible states, like I've been doing with Sketch lately, seems to me to be prone to errors like, forcing the design to do things that don't make sense once you actually try it, leaving things out because I was just pulling the states out of my ass, interactions that are actually harder to use than anticipated (like, it seems fine to make the user have to click a little circle to select something, but when you actually try it you find out that the selection area was too small and if they miss the circle they have to start over. That would have been caught if the designer had the opportunity to try it out before they built it). And also a lot more manual labor of having to imagine and then draw and then manage all these teeny tiny states. And then even if I can piece the drawings together in invision, there are some interactions that cannot be demonstrated (or accurately user tested) without conditional logic.
But the problem is that while I know how to get Axure to do what I'm imagining, the prototypes that I make with it wind up being pretty complex and therefore buggy as a result. I always feel like I'm feverishly tracking down a bug right before a usability session.
None of the alternatives seem to be working for me though:
1. Invision and others like it (there are so many) are just linking together drawings, no different or more useful to me than a slide deck. A slide deck would probably be easier to work with. It just seems like having to manually imagine and draw the states that a thing should have instead of letting the states evolve organically is an old-fashioned method that produces inferior results.
2. I don't have the time or patience to learn the amount of code this would take to do it in code. Like that would be a whole new profession and take up 100% of my time. Right? I would have to learn how to set up the coding environment, how to manage code with git or something. On top of that my bosses criticize my work in Axure for "trying too hard to do what the developers do when I am not a developer" and "being so comprehensive that it confuses and bores stakeholders". So, I have that to deal with as well.
3. I tried UXPin which feels like an Axure competitor but with less functionality, so basically going back to an earlier version of Axure. Axure's repeater widgets are amazing, wonderful and perfect and I don't want to live without them.
Am I missing something here? What is everyone else doing?
When I'm designing things I like to be able to set up how I think the interaction should go, and then click through it to see if it feels natural. As I'm clicking through it, things that are missing or that I need to change become apparent because my brain is in that mode. Having to manually draw all the possible states, like I've been doing with Sketch lately, seems to me to be prone to errors like, forcing the design to do things that don't make sense once you actually try it, leaving things out because I was just pulling the states out of my ass, interactions that are actually harder to use than anticipated (like, it seems fine to make the user have to click a little circle to select something, but when you actually try it you find out that the selection area was too small and if they miss the circle they have to start over. That would have been caught if the designer had the opportunity to try it out before they built it). And also a lot more manual labor of having to imagine and then draw and then manage all these teeny tiny states. And then even if I can piece the drawings together in invision, there are some interactions that cannot be demonstrated (or accurately user tested) without conditional logic.
But the problem is that while I know how to get Axure to do what I'm imagining, the prototypes that I make with it wind up being pretty complex and therefore buggy as a result. I always feel like I'm feverishly tracking down a bug right before a usability session.
None of the alternatives seem to be working for me though:
1. Invision and others like it (there are so many) are just linking together drawings, no different or more useful to me than a slide deck. A slide deck would probably be easier to work with. It just seems like having to manually imagine and draw the states that a thing should have instead of letting the states evolve organically is an old-fashioned method that produces inferior results.
2. I don't have the time or patience to learn the amount of code this would take to do it in code. Like that would be a whole new profession and take up 100% of my time. Right? I would have to learn how to set up the coding environment, how to manage code with git or something. On top of that my bosses criticize my work in Axure for "trying too hard to do what the developers do when I am not a developer" and "being so comprehensive that it confuses and bores stakeholders". So, I have that to deal with as well.
3. I tried UXPin which feels like an Axure competitor but with less functionality, so basically going back to an earlier version of Axure. Axure's repeater widgets are amazing, wonderful and perfect and I don't want to live without them.
Am I missing something here? What is everyone else doing?
Also it sounds like there might be a design communication issue going on, not an Axure issue. If stakeholders are getting bored, you may need to figure out how to stay out of the weeds when doing a demo, rather than using a different tool. (But I’ve also worked places where the details of interaction design were the job of developers and guarded jealously. Why? Idk.)
posted by chesty_a_arthur at 12:26 PM on April 18, 2019
posted by chesty_a_arthur at 12:26 PM on April 18, 2019
Response by poster: I could do that but the bugginess is killing me.
posted by bleep at 12:28 PM on April 18, 2019
posted by bleep at 12:28 PM on April 18, 2019
Names my colleague named:
Interplay
Modulz (which uses a react framework according to his text).
posted by chesty_a_arthur at 12:40 PM on April 18, 2019 [1 favorite]
Interplay
Modulz (which uses a react framework according to his text).
posted by chesty_a_arthur at 12:40 PM on April 18, 2019 [1 favorite]
I am quite fond of Balsamiq. It may not tick all of your boxes, but if you've never used it before, it is worth checking out.
posted by TheCavorter at 1:24 PM on April 18, 2019
posted by TheCavorter at 1:24 PM on April 18, 2019
I run a design team that used all kinds of stuff to prototype:
- pencil and paper
- web-based whiteboards
- Sketch
- Adobe Illustrator
- Adobe XD
- InVision (both the clickable prototypes as well as freehand wireframes)
- physical props acted out over video chat
- Unity3D for physical interactions
- etc
We use whatever tool works for the level of fidelity we need to prototype at, given the questions we're trying to answer and who the answer needs to come from. For context, we're a VR company that does extensive interface work crossing back and forth between 2D and 3D, so we're kind of all over the place, and do a lot of ad hoc prototyping to validate all kinds of stuff. When we do specifically 2D work, we were using Sketch but switched over to Adobe XD for Reasons.
Interaction usability prototypes, fully-functional graphs with live data, etc always get handed off to the engineers. We do build clickable prototypes based on real data sets, but we never try to simulate live data in a way that is faster and cheaper to code, rather than a designer's time building it by hand.
Tools and how they are used aside, it sounds like your boss is saying you are going overboard on the level of fidelity for the stakeholder presentations, even though you personally find it useful to go super-hifi when you're sorting out how granular interactions should work. There's a balance between a) level of design fidelity you need in order to get answers to the questions you have, and b) how long it will take you to build a working prototype at that level of fidelity.
While that deep high-fidelity level of prototyping might be the best way to answer your own questions about e.g. how big should this button be, the fact that you're encountering buginess due to the complexity of your prototypes (and considering coding them on your own!) is a sign that you're going way off into the weeds on details that might not be necessary, given the phase of design you're in, or the decisions your team has to make to move forward.
Before anyone on my team picks their tool to prototype with, we are thinking about the goals of presenting the work. What does color get us? Animation? Live data? Why are we presenting this particular thing to the stakeholders, what answers are we looking to get so we can move forward? And then we pick the prototyping tool that does that best/most efficiently, and do only as much work as is necessary to get that set of questions answered.
posted by Snacks at 1:51 PM on April 18, 2019 [12 favorites]
- pencil and paper
- web-based whiteboards
- Sketch
- Adobe Illustrator
- Adobe XD
- InVision (both the clickable prototypes as well as freehand wireframes)
- physical props acted out over video chat
- Unity3D for physical interactions
- etc
We use whatever tool works for the level of fidelity we need to prototype at, given the questions we're trying to answer and who the answer needs to come from. For context, we're a VR company that does extensive interface work crossing back and forth between 2D and 3D, so we're kind of all over the place, and do a lot of ad hoc prototyping to validate all kinds of stuff. When we do specifically 2D work, we were using Sketch but switched over to Adobe XD for Reasons.
Interaction usability prototypes, fully-functional graphs with live data, etc always get handed off to the engineers. We do build clickable prototypes based on real data sets, but we never try to simulate live data in a way that is faster and cheaper to code, rather than a designer's time building it by hand.
Tools and how they are used aside, it sounds like your boss is saying you are going overboard on the level of fidelity for the stakeholder presentations, even though you personally find it useful to go super-hifi when you're sorting out how granular interactions should work. There's a balance between a) level of design fidelity you need in order to get answers to the questions you have, and b) how long it will take you to build a working prototype at that level of fidelity.
While that deep high-fidelity level of prototyping might be the best way to answer your own questions about e.g. how big should this button be, the fact that you're encountering buginess due to the complexity of your prototypes (and considering coding them on your own!) is a sign that you're going way off into the weeds on details that might not be necessary, given the phase of design you're in, or the decisions your team has to make to move forward.
Before anyone on my team picks their tool to prototype with, we are thinking about the goals of presenting the work. What does color get us? Animation? Live data? Why are we presenting this particular thing to the stakeholders, what answers are we looking to get so we can move forward? And then we pick the prototyping tool that does that best/most efficiently, and do only as much work as is necessary to get that set of questions answered.
posted by Snacks at 1:51 PM on April 18, 2019 [12 favorites]
I'm like you: I do much better design work when I can click through a working mockup. I honest to god go straight from pencil wireframes to built-out Vue.js prototypes these days -- but I can only get away with that because I've spent half my career as a developer instead of as a designer, and I've built up enough of a reusable code library that I can throw them together relatively quickly.
I don't always show these prototypes to the client, though. Often they're just for my own benefit, so I can work out all the interactions to my own satisfaction; then I reduce that to a slide deck that communicates the important parts to the stakeholders and developers. Or sometimes I'll show bits of the prototype after the main presentation, if there's some particularly complex interaction that would be easier to demonstrate that way -- or, honestly, because it makes for a great "but wait there's more" moment to be able to pull out a working mockup after walking the client through the slide deck. But it means I don't have to worry about tracking down every little bug, or building out more than is absolutely necessary to work through the design, when design is the job I've been hired for.
You might consider something along those lines, since it sounds like your problem is more with the last-minute bug hunting and the overwhelming-the-stakeholders-with-too-much-detail thing.
posted by ook at 2:27 PM on April 18, 2019 [1 favorite]
I don't always show these prototypes to the client, though. Often they're just for my own benefit, so I can work out all the interactions to my own satisfaction; then I reduce that to a slide deck that communicates the important parts to the stakeholders and developers. Or sometimes I'll show bits of the prototype after the main presentation, if there's some particularly complex interaction that would be easier to demonstrate that way -- or, honestly, because it makes for a great "but wait there's more" moment to be able to pull out a working mockup after walking the client through the slide deck. But it means I don't have to worry about tracking down every little bug, or building out more than is absolutely necessary to work through the design, when design is the job I've been hired for.
You might consider something along those lines, since it sounds like your problem is more with the last-minute bug hunting and the overwhelming-the-stakeholders-with-too-much-detail thing.
posted by ook at 2:27 PM on April 18, 2019 [1 favorite]
Response by poster: It's necessary and I explained why in the question. If sketch worked for what I wanted to do I wouldn't need to ask.
posted by bleep at 2:28 PM on April 18, 2019 [1 favorite]
posted by bleep at 2:28 PM on April 18, 2019 [1 favorite]
Have you tried Framer? While I haven't bought into their newest version just yet, it's meant to solve exactly these pain points you mention around statefulness, reusability etc. that a drawing-based piece of software isn't great for.
posted by thirdletter at 3:03 PM on April 18, 2019
posted by thirdletter at 3:03 PM on April 18, 2019
Have you looked into Protoshare? I haven't really used Axure to know how the two compare on a feature-to-feature basis, but Protoshare lets you have states and master components. It's really intended more for wireframing than detailed visual design comps, so it might be up your alley.
posted by heliotrope at 3:12 PM on April 18, 2019 [1 favorite]
posted by heliotrope at 3:12 PM on April 18, 2019 [1 favorite]
What version of Axure are you using? Version 9 is launching in just a few weeks and they seem to have revamped pretty much everything about it. I've created some robust prototypes in Axure using repeaters and I hear you! It can be such an elaborate process to hack Axure into submission. Might be worth a try to see if the new authoring environment/workflow is smoother and involves less into-the-weed-ing. If so, Axure has a lot going for it.
posted by oxisos at 6:07 PM on April 18, 2019
posted by oxisos at 6:07 PM on April 18, 2019
I can validate that no, you are not missing something here. This is a legitimate problem.
Sketch and others like it can really only handle one or two branching paths and are really best when the branches converge back onto the happy path. This is ideal for the type of research where you're validating concepts, gathering impressions, testing out the end-to-end journey (from the perspective of staying on the happy path and seeing where users might fall off).
Axure is excellent for testing true interaction, where and how users actually explore, and how they might navigate back to and through happy (or other) paths. Your next best thing is front-end code.
Another dimension to add to this is fidelity. There are several pros and cons that align with the richness/completeness of the prototypes and the tools used to create them. For example, with Axure (or code) you end up with a more realistic setting which can uncover more issues (and is also very helpful for developers to build from), but you might not get feedback you would otherwise because the design is too finished and therefore fixed; users can get really lost in details that might overshadow their overall impression. This may be okay (or ideal) depending on which stage of design you are at with the project (e.g., well past discovery) and what constraints you have (e.g., legacy code with an established design language system).
I too suspect that there may be a communication issue underlying all this. Stakeholders might not be understanding what is lost by switching from Axure, but also might be feeling that this is ok owing to what is needed from testing based on where you're at with the project and the business needs/constraints. If interaction isn't the focus of what's being validated, then Axure is going to seem like overkill to them and no amount of convincing will dissuade them from thinking that Sketch, Balsamiq or something more lightweight will do.
Without knowing your situation, I can guess as some of your reasons for not being able to continue using Axure (e.g., version compatibility, steep learning curve for others joining in on the fun, licensing and pricing). I feel for you.
posted by iamkimiam at 11:55 PM on April 19, 2019
Sketch and others like it can really only handle one or two branching paths and are really best when the branches converge back onto the happy path. This is ideal for the type of research where you're validating concepts, gathering impressions, testing out the end-to-end journey (from the perspective of staying on the happy path and seeing where users might fall off).
Axure is excellent for testing true interaction, where and how users actually explore, and how they might navigate back to and through happy (or other) paths. Your next best thing is front-end code.
Another dimension to add to this is fidelity. There are several pros and cons that align with the richness/completeness of the prototypes and the tools used to create them. For example, with Axure (or code) you end up with a more realistic setting which can uncover more issues (and is also very helpful for developers to build from), but you might not get feedback you would otherwise because the design is too finished and therefore fixed; users can get really lost in details that might overshadow their overall impression. This may be okay (or ideal) depending on which stage of design you are at with the project (e.g., well past discovery) and what constraints you have (e.g., legacy code with an established design language system).
I too suspect that there may be a communication issue underlying all this. Stakeholders might not be understanding what is lost by switching from Axure, but also might be feeling that this is ok owing to what is needed from testing based on where you're at with the project and the business needs/constraints. If interaction isn't the focus of what's being validated, then Axure is going to seem like overkill to them and no amount of convincing will dissuade them from thinking that Sketch, Balsamiq or something more lightweight will do.
Without knowing your situation, I can guess as some of your reasons for not being able to continue using Axure (e.g., version compatibility, steep learning curve for others joining in on the fun, licensing and pricing). I feel for you.
posted by iamkimiam at 11:55 PM on April 19, 2019
Another option is Figma:
* Dealing with multiple state components
* Prototyping
posted by Sharcho at 1:30 PM on April 21, 2019 [1 favorite]
* Dealing with multiple state components
* Prototyping
posted by Sharcho at 1:30 PM on April 21, 2019 [1 favorite]
I haven't done a deep dive on this program yet so I can't fully vouch, but it looks like Justinmind can handle conditional programming and might be able to handle a lot of the tasks you'd need it for.
posted by helloimjennsco at 9:56 AM on April 23, 2019
posted by helloimjennsco at 9:56 AM on April 23, 2019
This thread is closed to new comments.
I do mostly research and am consistently frustrated by this combo’s gap around complex workflows with lots of forks. I hate asking designers to link 3 unhappy paths for every happy one, in the service of a quick usability test.
posted by chesty_a_arthur at 12:23 PM on April 18, 2019