You are on your way to work and waiting at the traffic signal. As you look aimlessly across the street thinking about a design problem you have been struggling with for weeks, you have the Aha moment. There is a fuzzy solution to the problem, hovering in your head, and you think it's a pretty decent one. You rush to the office and start cranking some rough mocks — something just one notch higher in fidelity than the typical wireframe — so that by the time rest of the team is here you have something to bounce ideas off. Sure there are interactions whose implementation is fuzzy at the moment, but you say to yourself, "that comes way down the line, finding the basic flow of things and aligning it with what we are trying to do is far more important for now". As soon as everyone is in, you ask them to gather around your desk and go on to talk about your ideas. During the explanation a team member asks ‘how does the animation work in landscape mode on the iPad’.
Ugh! You don't know. You are not even sure if that animation is the best animation at this stage. We have barely started thinking about the product and someone on the team asked a question meant for way later. Best case, you tell them that can be figured later. Worst case, the idea doesn't fly even when it could have been the one of the best solutions. In all cases, you lose momentum, because someone decided to ask a question, give feedback, for a different stage of fidelity in design.
It’s easy to critique color when you’re discussing layout, typefaces when you’re choosing border-radii, and copy when your exploring interactions. -Dustin
This happens so often that I have lost count of meetings I or other designers I talk to have been in where this led to more circling around ideas around the core problems, only to come back to the original one. This is not the same thing as trying 10 different ideas to find the best solution to a problem. This is having to look around for different solutions for the sake of looking because the last good idea was shot down before it had a chance to stand up on it's feet. Momentum is one of the best things for any product design process. It helps you from straying around the wrong path, or losing your core vision, or trying to solve too many things in the first release. This is why projects with no deadlines are often one of the most difficult ones. Because you then have to come up with some other form of milestones to maintain the momentum. Asking the wrong questions at the wrong fidelity or giving the wrong feedback kills momentum like nothing else.
Trying to resist the urge of asking questions or giving feedback at the wrong fidelity requires discipline, understanding and experience. But far more than that it requires immense trust in people who are trying to solve the problem, the designers, the engineers and everyone else on the team — each one of us. You need to trust that your designers, and the team at large, is capable of finding how that animation would work in landscape when the time comes for it. For now focus on getting the flow right.
So the question is how do you know what stage of fidelity you are at in the cycle. It differs from team to team, and the path you take to the end product. Here are some of the most common stages of fidelity I have come across. (This is an over-simplified model and a fair amount of overlap happens from time to time)
Product Exploration
You are still exploring the idea and how to implement it. You want to help creatives showcase their talent. But how?
Would it be a blogging platform? Would it be a photo gallery? Would it be more like a portfolio? Hmm…portfolio sounds interesting. What if we can add community aspect to it? That sounds like a good problem to solve.
This is the product exploration stage. You don't know what the product is at this point. Don't try to open photoshop or sketch interactions at this point. Most importantly don't ask the designer to create some mocks to see how this idea holds. It's like expecting the chef to give you Crème brûlée when all you tell them is that you are hungry, and then getting disappointed when they serve Lamb chops instead.
Sketching & Flows
Sweet. You know the idea you want to work on. You know what kind of people need this to exist. You know what their needs are, what the pain point of current solutions are. Now you want to come up with a solution that solves these pain points and also encompasses what you envision this product to be in the long run.
Sketch a lot of stuff. Think about what the overall flow of the user in your system looks like. Think about each screen in this system. Can some screens be combined? Would some screens be served better if they were separated into two distinct steps? What are the goals of the user at each stage. What are their expectations? Does the UI allow the affordances for those goals? Awesome! You are a step closer to your product's basic version.
Visual Design of the Interface
So now that the overall flow is all done, time to add a coat of paint to your idea. This is when most people open photoshop. You play around with visual relations between entities on each screen. By this time you are well aware of the overall flow that you know where the user comes from and where they can go to from this screen. So it is easier to design for continuity. Each screen begins to feel connected because of the homework you did with the last stage.
You typically worry about things like text color, button colors, grid, typography etc at this stage. Should you use an on–off switch or can you have something more fun like a slider to control the state? If the product has user uploaded content, you try to use the actual content instead of placeholders to see how the UI holds itself. Are there special edge cases you need to solve for. How does the screen look when there is no user data. (‘what happens when there is no user data’ should ideally have been solved in the last stage, but it is totally fine if you started thinking about it now too. Like I said, a lot of overlap happens). You should ideally also have the final copy in place now. This way you know if some screens are looking heavier or have way too much text. This is where you make decisions like 'can we replace that paragraph of text with a banner image instead?' But for all practical purposes and because of the way teams are generally organized, the copy comes more towards the end. Often that's ok, and sometimes, cause of a few last minute tweaks.
Your product has now started to look useful and beautiful.
Interactions & Animations
This has a lot of overlap with the last stage of visual design. There is a lot of back and forth because by changing visual style of some elements, the otherwise not so great animation, starts to shine. Often though, this begins after a basic amount of visual design has happened for most of the apps. How does the new view come in? Does it slide up or does it flip over the current view?
Once again, this is an over–simplified approach and there is often a good deal of back and forth happening. Also a lot of individual stages have a lot of sub–stages that happen in parallel. For example choosing typefaces and the button colors. The trick is to focus on one of them at a time when deciding which one works better and preferably with the most plausible candidate of the other kind. So if you are confused about choosing between Elena and Tisa on one hand and a green or orange primary action button on the other, then maybe try choosing them independently and without worrying about the orange button on the upper-right corner of the mock when you are deciding the typefaces.
When feedback and fidelity in design are calibrated against each other it makes the overall process lot more efficient. It helps the team as a whole thinking about the same problem at one time. The result is not just more ideas but people being more receptive to crazier ideas because they would have, most likely, thought about it at some point themselves.
