UX is typically an early part of the software development lifecycle, but let's look deeper into the steps a UXer should take before really beginning to put a UX design together. I want to refer to this as Nascent UX. Nascent) simply means "beginning to exist or develop". Nascent UX is the gathering and organizing of information prior to the actual design phase of UX.
This concept important because it sets us up solidly for putting together a well-informed UX design which fits our goals, limitations, and available resources.
It comprises a few steps:
- Question asking
- Information gathering
These steps will provide you with the information and parameters necessary to start your designs. One of the biggest points of emphasis in Nascent UX is ask lots of questions. The more questions you answer up front the fewer bugs and issues you'll run into later.
The very first step is to define your end goal. What is it you are trying to design? How does this help your users? This will shape and guide what you are working towards. Without this, you have zero reasons to be putting a design together. It provides a definitive point to focus on and should shape every question you ask. It allows you to ask if each thing you are doing is working towards that final goal.
A few top level questions will help you establish this end goal.
The first, and most important, is which users are you designing for? Again, this is the single most important question in UX. The U in UX is pointless without this question. If you don't know who you're designing for then you're aiming at a moving target while blindfolded. At this point, it's not essential to dive deeply into a formal User analysis, but you need to at least answer some high level demographic questions. You also need to establish how and why they would use whatever you are designing.
You also need to identify both the overlapping and delineating points between your users' goals and your business goals. This can often be a tough spot for a UXer as it requires careful balance. The business goals often win out, but you need to have the ability to show the end value of meeting your users' needs as well. Identifying these sore spots early will mitigate friction later in the project.
The ability to amalgamate these goals into a great experience that meets your users' and your business's goals simultaneously is a trait requisite of great UX professionals.
Part of my job as a UX Architect is also Information Architecture. Information is composed of pieces of data. Therefore, in order to create IA we need to know which pieces of data we have available. Typically, there's going to be a lot. If you're looking to dig deeper, Stephen Anderson does a great workshop on Information Visualization where he hits on this (and much more). Let's look at some basics to identify your data and get it in order.
Data can come in many forms. It can be numbers, letters, words, phrases, or any combinations thereof. We need to be able to identify and list all of the types of data we have available.
Then we can take our comprehensive list and begin to categorize it. Some data may fit into multiple categories. Categorizing will put data together that makes sense and start to create groups that will inform the interaction design.
We need to then prioritize that list. It's likely that a lot of the data is not data that needs to be exposed to the user. Paring it down to the most meaningful data will clarify what the user really wants to see and interact with. Without this prioritization we'd likely be exposing data that is not necessarily extraneous but that is not as meaningful to the user. It can also easily cause cognitive overload for the user.
The last step is to figure out meaningful combinations of the data. Some data combined with other bits of data help to create even more meaningful displays and interactions for the user. Deciphering and creating these combinations will likely be the most difficult step but can prove to be the most valuable to your users.
Once we know the data we need to use then we can start Interaction Design where we start to piece together how the user interacts with this data. Again, we go back to our goals to assess our users end goals. This will drive the interactions you design.
This is a good spot to do your task analysis. It will help determine the interactions needed. If you can, it's also a great time to get quick feedback from your users in the form of surveys, questions, and interviews. Sometimes, what you think users want to do is very different from what they actually want to do.
The key is not figuring out how users will do something, but rather what they will do. In other words, let's abstract our thoughts even higher than interaction patterns and figure out what our users need to do with the data provided. Often, an interaction pattern will fall into place after this step but thinking at a higher level can spur a different pattern or combination of patterns that betters the overall UX.
If this is not part of an entirely new product, then we need to identify the existing areas this feature touches. This needs to be absolutely comprehensive. Even errors and fringe cases can touch seldom used pages and areas that you otherwise might not have thought about. Identifying all these areas at the onset will help you scope your work and have fewer surprises later. It will also help your designs to account for the full scope of its affects.
We also need to define any new pages or areas needed. How does a user reach these areas? Where do these new areas link out to? Where do their interactions cascade across existing pages?
How would Youtube have to change their home page if they started streaming 24/7 networks and wanted to heavily promote them?
If we're designing onto an existing system this is where we perform what I call Regression Usability. It consists of going back to pages that already exist and figure out how our new features affect those pages. Does it change data? Is there new data we need present here? Are there design updates that need to be made? Performing Regression Usability can also help your QA from discovering a bunch of bugs when they do regression testing.
There are also a few other sundry questions you should explore before diving into wireframes. These may have quick answers, but they're no less important.
Which technologies will be used? Knowing the technology will help you determine what's possible. It defines limitations and difficulties. Meeting user goals and business needs is priority but making sure it’s possible to build is ostensibly a critical element you need to identify before delving too far in the UX architecture.
What tone should this take? Knowing the tone of your content has typically been seen as a bigger aspect in design, content strategy, and copywriting. However, interaction design certainly plays into this. Making a playful design or business-like design should depend on your audience. While it may not break the design, choosing the right tone with your UX could greatly enhance the experience for your users.
I mentioned Stephen Anderson earlier because I think he has some great stuff. One other thing of his I recommend is his Mental Notes deck.
They are a deck of psychological principals and how they apply to interaction design. One exercise I've found highly effective is to go through that deck and try to see how each principle fits in with a design. It draws you out of your comfort zone and may spark some really creative designs and ideas. At worst, it will make you look at your thoughts in a different light and give considerations for improvement.
You should now have a fairly substantial set of information. It's time to start sketching. Don't go straight into wireframing. Rather, draw on the bank of information you just gathered and begin to sketch what that looks like in interface form.
None of your designs are solidified so go crazy. Throw things out there that seem a bit weird or too far out there. It'll likely get tossed but it may spur something else on that improves the UX.
Defining the requirements and taking the Nascent UX steps above will guide you to great UX. You won't be aimlessly wireframing something that you hope meets some hazy set of requirements. The steps above will equip you with the preparation and steps to put together great UX that users and your business will appreciate and celebrate.
- Dictionary definition of Nascent
- www.poetpainter.com by Stephen Anderson
- Mental Notes by Stephen Anderson