Welcome back to Part Two of Amped-UX’s “Minimal Viable User Experience - UX for Start-ups” series. In the last part of this series, we described a high level overview of what User Experience is and talked about the importance of several concepts and "flavors" of UX, such as Usability, User Research, and Content Strategy. For this installment we’re going to take a look at the practices of Information Architecture, UX Design, and UX Prototyping.
WHAT IS INFORMATION ARCHITECTURE?
Information architecture (IA) is a fancy word for the process of designing multiple end-user experiences or "environments" that are all intended to share or access a similar base of information. At its core it is the process of tackling a big complex problem (consisting of all the data, requirements, and features that a product or platform needs to support) and organizing a plan to distill it into smaller, more discrete, and more manageable chunks. Each of these chunks may be focused on the needs of multiple yet dissimilar end-users who all need access to the same source of information. Sounds important, doesn’t it? It sure is! Truth be told, I dislike the term "IA" as good UX is about promoting clarity and reducing confusion, so it’s ironic that this term is less immediately obvious than others, but it's arguably the most complex part of UX. A helpful metaphor I picked up is that information architecture is the design of a holistic structure of a building, like a museum, including the public galleries as well as all the wiring, lighting, plumbing, security, and AC system. One user's experience may entail following one path through the front-door of this metaphorical museum where they see the latest public exhibits, but much of the underlying complexity remains hidden. Another user experience defines how an electrician or plumber accesses and interacts with the museum, which entails both more "under-the-hood" information and complexity that offers a completely different experience from what public users see. |
IA, then, is a form of research, but unlike content strategy and user research which focuses on the needs and behaviors of external customers and how best to reach them, IA focuses more on the technical needs and constraints of internal resources with a greater emphasis on information technology and engineering. An information architect not only needs to think about the needs of multiple end-user needs as uncovered by user research, but they have to balance those against internal needs and resource/technical constraints when making important architecture decisions .
Why is Information Architecture Important?
Coding is hard, mentally taxing work. Software projects don’t have unlimited funds, good programmers are expensive, and development almost always takes longer than you expect. If you have bad IA or are lacking in it, then like a house built with no plans, you risk building something that lacks durability, cohesion, or structure. As your startup operation grows and you add weight and pressure to this house beyond what it was designed to handle, it will start to strain under the pressure. This manifests itself as confusing UX, friction, or unmet end-user needs. It may lead your engineers to implement band-aid fixes or temporary work-arounds, when what is really needed is to start from scratch and architect a new, robust solution to handle more complex needs. | "If you have bad IA ... you risk building something that lacks durability, cohesion, or structure ... This manifests itself as confusing, poor UX, friction, and unmet end-user needs ...What is really needed is to start from scratch and architect a new, robust solution to handle more complex needs." |
Also, if insufficient time is spent on information architecture, you may find that you’ve overlooked critical tools or that other end-users on your team or your client needs to do their job effectively. For example, a content marketing team for a big e-commerce site might need a web-based CMS tool to upload photos and videos onto your site to promote new item releases or promotions, while your customer service end-users need back-end tools to track and document complaints or associate them with specific orders. Good information architecture boils all these requirements and data into the simpler, more actionable plans, anticipates as many of the unexpected use-cases and exceptions as possible so that a large-scale software can deliver holistic value to all your end-users most efficiently.
When Should I Use Information Architecture?
The short answer is that it depends! There is a natural overlap between UX Designers and Information Architects, as both roles entail asking effective questions to uncover end-user needs, internal constraints, and making decisions based on those findings. Some projects are sufficiently simple that hiring an official, formal Information Architect separate from a UX Designer may not be necessary (for example, a simple mobile game). Other projects have massive amounts of information to sift through, such as websites that can be accessed from mobile or desktop in multiple languages, and have teams or other departments that are not customer-facing. If your project is likely to have a large team of engineers or multiple end-user personas to support, or large distributed teams and departments, then Information Architecture is likely to be something you’ll need to front-load as much as possible before any major coding or development efforts begin. It should also occur in parallel with User Research and Content Strategy and should precede or run in parallel with UX Design.
If you'd like to learn more about some more in-depth Information Architecture books and resources for further review, check out this helpful article from UX Matters.
What is User Experience Design?
UX Design is the process of taking the all the requirements, features, and constraints informed by other UX practices and starting the official process of organizing information, and features into a form that defines the moment-to-moment experience of moving through your software. This can take the form of rudimentary sketches, flowcharts, screen mockups, and diagrams called wireframes. The purpose of these materials is to detail step-by-step how the software guides users to experience and interact with functions and information, and how all the pieces of the UX puzzle start to fit together. Sometimes these diagrams can be large and intricate, other times interactions are chopped up into smaller flows. Often it’s necessary to annotate UX Design materials with notes that may convey additional details or information for developers. This can be especially important if the team is distributed or the UX Designer may not be immediately accessible to relevant stakeholders. While there’s plenty of dedicated tools out there for creating UX Design materials, some also believe that good old-fashioned pencils and paper can be best. |
WHY IS USER EXPERIENCE DESIGN IMPORTANT
For the other user experience practices, usability is of general, but not necessarily primary importance. For example, a User Researcher gathers quantitative and qualitative data from users, or produces analysis documentation or persona sheets, but they’re not creating usability just yet. The same applies to an Information Architect: they may have to understand both internal and external needs and constraints and come up with a high-level plan showing how to organize all the relevant information systems in an abstract sense. While they don’t want to propose solutions that are unusable, they are not directly responsible for producing usability on a tactical, moment-to-moment level.
"UX Design materials can outline a holistic, detailed, and comprehensive blueprint for a product, but it’s useless unless it’s used to spark conversation and to build consensus amongst stakeholders, so that other developers down the line ... can understand what it is that they are expected to create. " | However, this is not the case for the User Experience designer. The Designer has to take all of the findings from the User Research, think about the Information Architecture requirements (if the project is complex), how the Content Strategy will position the product, and start producing screen layouts and flows in an organized way that is intuitive and promotes usability. In my experience, UX Design materials can outline a holistic, detailed, and comprehensive blueprint for a product, but it’s useless unless it’s used to spark conversation and to build consensus amongst stakeholders. This helps other developers down the line, such as Visual/Interaction Designers and programmers, understand what they are expected to create. Thus, UX Design provides the foundation from which later phases of development stand upon. |
While some UX wireframes and flows do closely resemble what your final software looks like, they are still just assumptions, and there are lots of twists and turns on the path to development. Also note that UX Design materials can support ongoing user research and usability testing. UX Designers are just as liable to make incorrect assumptions about what’s best for users, so if you can add this to your process, especially for uncertain or contentious aspects of your UX design materials, it can help validate that your project is staying on-course, saving time and money.
When Should I Use User Experience Design?
In general, UX Design should always run ahead of functional development or programming, but ideally should take place after some inital end-user research has been done (and information architecture, if it's needed). However, you may encounter a school of thought that wireframes should be as quick as possible, or even something that you skip over. You may hear about “designing in the browser,” this refers to skipping over creating traditional UX Design going straight into implementation using HTML, CSS, or Javascript. I think it's important to make a distinction that this doesn't mean that you skip over UX Design, it's just that it takes a different form.
For example, I love getting caught up in the creative momentum of clarifying a strategic and visual plan using wireframes, mockups, and flows as much as anybody, but I didn’t create any when building Amped-UX.com (maybe this is obvious...you tell me!) My goal was to revamp my online branding and presence as quickly as possible to learn as much as possible. I knew that if I chose to make wireframes, it could easily add weeks to the process. Weeks where my site would not be up and running. So in my case, there wasn’t any external pressure or deadlines, so it made sense to skip wireframes and "design in the browser" so to speak. | "You may encounter a school of UX thought that wireframes should be as quick as possible, or even something that you skip over... I think it's important to make the distinction that this doesn't mean that you skip over UX Design, it's just that it takes a different form." |
It all depends on your situation and how effectively the UX Design can be communicated to other relevant parties and stakeholders. In general, I wouldn’t advise skipping wireframes for large or complex projects, if there’s signficant Information Architecture needs, or if external enterprise clients are involved. The budgets for these projects can be quite large, and there’s a lot riding on them, so if there is time and resources allocated for wireframes and the client is paying for it or expecting it, I wouldn’t short-change it.
This doesn't meant that wireframes are the best way to do UX design - they are static and in some instances it can be challenging for stakeholders to understand dynamic elements, how the user experience changes or flows over time, or how your UX Design might look on web, versus mobile, versus tablet. If you choose to streamline wireframes, replace it with other forms of UX Design. Take the time to consider the risks, benefits, and potential outcomes of all the approaches at your disposal, then you can make an informed choice that makes sense for your project.
To learn more about this debate within UX Design and some pros and cons (well, mostly pros) to the "No Wireframes" approach, check out this article from Zurb.com.
To learn more about this debate within UX Design and some pros and cons (well, mostly pros) to the "No Wireframes" approach, check out this article from Zurb.com.
What is UX Prototyping?
UX Prototyping is a specialized user experience design practice where UX Designers take initial ideas for user experiences and implement them into an interactive form in a fast, efficient way. Wireframes, mockups, and flows can be great for clarifying the big picture, but to an untrained eye they can be difficult for assessing usability. While knowing how to program using HTML or CSS can be an effective prototyping method, the good news is that you don’t need to know how to program to create UX Prototypes. There are a variety of dedicated tools for interactive prototyping, like Pixate, Invision, or Sketch, that enable you to quickly create beautiful animated prototypes that replicate the superficial look and feel for real apps without writing a single line of code. Or you could get old-school simple and bust out the crayons, scissors, glue, and table, and make paper prototypes of screens or target sub-portions of your product. |
WhY is UX Prototyping Important?
If there are differing ideas or assumptions about what product features are important, useful, or intuitive for your end-users, prototyping, in conjunction with user/usability research, can save your start-up a ton of money and time. Also, if a UX feature is innovative, there’s a good chance that it may be quite different from what end-users are used to, and potentially confusing. Prototyping with User Research can take ideas out of the realm of the theoretical and get them in front of actual users and stakeholders for further testing, evaluation, and decision-making. This can validate innovative features and reduce the potential for confusion. This is critical to mitigate risks in the fast-paced start-up world, as once you code a feature or implement a portion of your product for real, it becomes crazy expensive and risky to make changes in code if you discover your assumptions were incorrect.
When Should I Use or Do UX Prototyping?
Prototyping is another practice that should occur in earlier phases of the project and it's important to consider doing it if you’ve decided to bypass some of the more traditional UX Design materials (like mockups and wireframes). Like information architecture, it should definitely precede the bulk of development and programming, but it has the most potential to be useful when it's done in conjunction with usability research. Just be aware that UX prototyping is not the same as development! The purpose of a prototype is to learn things from your users as fast as possible, then be ready throw it away. Remember when we said that bad Information Architecture is like building an unstable house? If you are not using a dedicated prototyping tool and you are using an HTML framework or doing actual coding for prototyping, be wary of the temptation to continue to build on a the foundation of a hastily built prototype for actual development. I'm not saying this is always the case, but sometimes when making code prototypes, you'll cut corners just to get it done as quickly as possible, and this makes it risky or unstuitable for longer-term development. Once you’ve learned what you need to learn from a prototype, carefully consider the pros and cons of moving forward with it versus starting development from a clean slate. | "The purpose of a prototype is to learn things from your users as fast as possible, then be ready throw it away... Be wary of the temptation to continue to build on a the foundation of a hastily built prototype for actual development... " |
LET'S TALK ABOUT YOUR USER EXPERIENCE CHALLENGES
Thanks for continuing to read our Minimal Viable UX Series. Do you feel like you're getting a better idea of what kind of UX practices could benefit your start-up team best? Describe your challenges or thoughts in the comments. I’d love to share further insights with you to help you solve your UX problems.
And don't forget to come back for Part Three, where I'll go over Interaction Design, Visual Design, and Gamification.
And don't forget to come back for Part Three, where I'll go over Interaction Design, Visual Design, and Gamification.