From Flow to Function to Form

Let’s spend some time talking about the design process. Of course, we’re not going to hit every step here but we’ll hit the basic steps of getting to the wireframing step. Ideally, this would all be proceeded by steps such as some preliminary user research, persona creation, requirements gathering and other necessary steps in the UX process, but this article will focus on the meat of creating wireframes and mockups. We’ll talk about how to set up flows, how to translate those into functions, and then ultimately transform those into a usable form.

Go with the Flow.

The first step in setting up our wireframes is figuring out the flow. If we don’t know the possible paths and sequences of action then it is near impossible to build wireframes that support the requirements. Actually, we need to look at two flows to fully map out what is needed for the wireframes.

The first set of flow diagrams to set up is the user flow diagrams. For the purpose of this article, we’ll leave out the details of syntax and diagram elements. There’s a fairly standard set, but it’s not really the super important part of what we’re discussing here. The takeaway from this article is that for a flow diagram you want to figure out all of the possible paths a user can take for a particular page or feature and diagram those paths. You want to modularize these diagrams or they will grow unreasonably large and increasingly arduous to read and interpret. You want to figure out what should happen when users click a particular button, select a particular option, or any other action the user will take. Ask yourself some of the following questions:

1. Should navigation take place? If so, where should the user be directed?
2. Should UI elements show/hide/transform?
3. Should an error occur?
4. Should a warning appear?
5. Should instructional text appear?
6. What kind of feedback is being provided that the action took place?

After you set up your user flows then you can take that and set up some system flows. These diagrams translate the user flows into actions taken by the system. These diagrams should parallel the user flows, but may also bring to light some actions that the system needs to take but that may be invisible to the user (ex: form validation when successful). This may even make you think about some system states that should be made visible to the user.

Oh Function Junction, what’s your function?

In a flow there’s always direction. There’s often many directions. A function explains how to move in a direction and to get from one point to another. For example, let’s say the simple flow below is your flow:

User Signs In → User Views Profile → User Changes Password

But there’s questions surrounding this flow. How does the user get to their profile? What’s the process to change the password? Let’s not get into the UI or design patterns necessary to carry out the actions, but rather what are the steps the user will need to carry out the actions. It’s an intermediary step between the flows and the form. We need to know if the user will open up a separate profile or if they can immediately see it. We need to know what steps and precautions there are in order to change a user’s password.

While flows are at a higher level, defining functions is at a lower, more detailed level. Often, defining functions and specifying the UI are combined into one step, but ideally the designer would think about them separately. You may have often heard that form follows function and I believe that’s correct. In the real world, that’s not always how it ends up working, but we are dealing in ideals here anyway. Also, if that’s not how it’s working then you should be convincing your company or client otherwise. Square pegs shoved into round holes can make for difficult user experiences.

Try on something a little more Form fitting.

Wireframe Example (using Balsamiq)

After we’ve figured out the user flows and the functions that drive these flows out then we’ve got to put that into a form that users can interact with. This is where wireframes come in. Now, a lot of people think they can do this step because everybody is familiar with UIs, right? Well, everyone can certainly put one together, but only UX experts can optimize that experience. This is where things like Fitt’s law and knowledge of design patterns comes in. Again, there’s a few questions to ask here:

• What design patterns will work with this function?
• Who are the users I’m dealing with?
• What is technically feasible? What kind of programming framework am I dealing with?
• What have I used in other areas of the design?
• Are there established UI standards based around this function?

All of these come together to shape the decisions you need to make when putting a UI together. Designing a table for kids when using Flex is completely different than designing a table for business associates in HTML/CSS. Consistency is something that should always be on the forefront when putting your designs together. Why would you design two very similar functions differently so that users have to learn two different processes? Consideration needs to go into your designs and you might need to make several different designs. Wireframing is not just about throwing some buttons and dropdowns on a canvas. It’s about taking the flows and functions specific to what you’re designing and applying UX expertise to them to create a physical (or virtual) experience for the user to carry out those functions.

Follow the Fewest Clicks Road

These three steps are crucial to putting together wireframes that ultimately lead to what the user interacts with. Ideally, things like user research, personas, and user scenarios would also be done before or during these steps. Prototypes and more research should also follow these steps, but we’ll leave all those for another post. Following these three steps will help to put together some strong wireframes that are backed up by a UX framework and infrastructure through the flows and functions defined.