As you read this, the AMARO UX Framework is changing. Not because we changed our minds, but most likely because we discovered something new, the business changed, the company understood and we adapted to it or someone from another area made a good suggestion. The framework is open to the entire company and everyone can contribute to its evolution.
It was first written based on concepts from “The Elements of User Experience”, by Jesse James Garrett, after I spent somewhere around two weeks talking to everyone and visiting every department at AMARO. This is important to point out because I believe that a design framework has to reflect the culture of its company. As I’m still learning and the company continues to change, the framework is also constantly evolving. In fact, because of our business model (AMARO is a digitally native direct-to-consumer brand), we have a stronger notion of user experience than usual, so the framework needs to reflect this.
It’s an exciting time to work with UX, being that most companies that have a digital presence understand they can’t compete on price or function alone because, at the end of the day, the user experience is the highest indicator of value that you offer to your customers. When you deliver value, you are more likely to receive that value back from customers.
“GOOD DESIGN BECOMES INVISIBLE”
I’m not sure who wrote that, but I agree. Let’s talk now about our five framework stages. What we basically want to do with this practice, process, and result is to create experiences that minimize cognitive effort, make the steps to the conclusion of a task look simple, give immediate feedback and minimize user error.
People tend to think of the UX designer as the guy who designs screens. Other areas of the company may come to us with a problem where the only thing we have to do is draw interfaces, or add a button. Frankly, it’s the easiest thing I could do, but, if I want to build an experience that will bring value to the user, I need to understand much more about what the expectations of the users and the business goals are.
So we have to be careful not to give up good UX, where there should be research, cognitive bias, strategy, and understanding behind a useful interface. That’s why you’ll see much more information in the stages before interface design. It’s important to understand that good interfaces are only built over strong and structured strategy pillars.
1 — IDEATION
In this step, the most important thing is to find out a point of convergence between user expectations and business objectives. That’s where we’ll find a product or feature that has the most chances to bring great results. It’s also important to research your market to understand the context that the brand or the product is in, as well as what competitors are doing.
To do so, we use a set of techniques like existing product reviews, user and stakeholder interviews, benchmarks, A/B testing, usability tests, and remote research until we have enough information to come up with a creative solution. Or at least to find out a feature that already exists but we’re missing.
It’s important to mention that we don’t use a strictly scientific approach for all this research but a more lean, guerrilla, “insight as soon as possible” approach. Something that you can do almost by yourself, for two reasons: first, if you outsource your research, you’ll have one extra layer of interpretation of results and this will move you away from your users and, secondly, you have to be fast, so it’s important that you can have almost the entire process in your hands. One thing you should outsource, as Lean UX recommends, is recruiting. It’s too much work, in most cases, for the designer to handle.
Every user interview and all of your research needs to be carefully interpreted because what users say they like may not necessarily be what they truly need. But it can be your first step, based on your findings, to discover what they don’t even know they want.
This is the most time-consuming phase and, to make matters worse, we don’t have too many deliverables to share during the process. So this would be the moment to control your anxiety and talk to people about why you are dedicating this time to find out things that don’t relate so directly to the interfaces everybody is waiting for.
One good argument is that, as numbers show, a sloppy strategy is responsible for digital products that don’t work; one bad decision made during this phase can lead a company to invest resources developing a product or feature that isn’t relevant for the users or that doesn’t solve their problems.
In the ideation process, it’s important to have other team members involved, especially developers, so we can anticipate possibilities and limitations. A collaborative team is essential here and you can use some technique like Design Thinking to create a solution that most of the team believes in.
Deliverables: at the end of this phase, you’ll [hopefully] have a document with interesting things to look at — existing product reviews, benchmarks, best practices, feature spreadsheets — and, if your project involves creating a new product or feature, you’ll have the conceptual idea based on data to align and validate with the company.
2 — MEASURE
This is where we’ll define the project scope and features, create the product evolution plan and define which KPIs will help us understand how good our new product is performing and if it will, at the end of the day, accomplish its objectives.
To scope the project, we have to think about the user scenarios so we can figure out the content and system requirements. In the project evolution plan, it’s important to distribute the features considering how important and feasible they are, in a plan that can bring value early on and keep surprising the user along the way. Bring the developers on board here. They have to believe in the project too because they’ll choose which technologies to use and can start working on it.
It’s time to guarantee that everyone involved shares the same product vision, especially the commercial department or the client, in case you are working in an agency or consultancy. Typically, we have different visions in different departments about the product, just like the Blind Man and The Elephant parable. So It’s recommended to document this scope to avoid misunderstanding during the development process. How much documentation will depend on your team and how aligned and collaborative is everybody. Once the scope is closed, keep a hold on it and avoid to say yes to every new suggestion. Try to schedule new features for future sprints.
Some tradeoffs may happen for the best during development but we define a scope so it won’t turn in to development hell.
Deliverables: Scope document with user scenarios, version planning, and KPIs.
3 — STRUCTURE
Things are starting to get more concrete now. In this stage, we’ll design the information architecture to support this new product or functionality. The focus is to organize information with a consistent logic in order to have intuitive access to the application content. Affinity, relevance and search frequency are the main criteria for findability along with consistent labeling the areas.
Try to create an architecture that is able to grow over time without having to reorganize everything. Also, there are a lot of models like hierarchy, nest, hub, filtered vision, dashboard or tabs that can be used depending on the product you are creating and for who you are designing.
We start to think about Interaction design here. That’s how your system will respond to every user input, like a conversation. In this case, the more predictable you are, the more intuitive your system will be, and more comfortable will be the user to navigate. So, to follow design patterns can help you create a more enjoyable, consistent and accessible experience.
Where is all the creativity? Well, not in navigation or micro-interactions. To change one pattern we first make sure we have a good reason and we’re making our user’s life easier.
Deliverables: Product flow and information architecture.
4 — SURFACE
It’s finally time to draw the interfaces, to give form to the function. The objective here is to start testing some solutions or possibilities in the interface, navigation and information design before going to the computer in a very fast paper prototype way. We draw and redraw some key interfaces to have an idea of how can we best organize the navigation tools and the content of each screen. In some cases, we can even prototype in low rez.
After that, we move to a UX design tool to draw the interfaces and make a high fidelity prototype. With this prototype, we can validate some more hypotheses and make new adjustments. Once we believe we have the experience we want, developers can start coding using this prototype as a reference, along with the Zeplin project and some additional documentation that, in most cases, refer to micro-interaction, transitions or behaviors.
Even though it may be difficult to gather everyone on the squad to discuss every aspect of the product, ideally the more the team is involved and takes part in decisions, the less you’ll have to document your work.
Some principles we use to guide our work in this phase are:
- Reduce the number of function the user has on each screen so we can have a more usable interface;
- Make consistent use of conventions, patterns, and our own design system so we can have a more intuitive experience;
- Personalize the experience as much as we can (and this has to be considered from the ground up) so we can show less but more relevant content;
- Create a predictable experience so the user is confident to move forward;
- Consider all the principles that are not particular to UX but are part of Design itself, including alignment, redundancy, contrast, proximity, narrative sequence, typography, color, and visual identity;
- Aim for sleek visual design. More than other players, AMARO values beautiful interfaces and the most important thing we have to pay attention to is guaranteeing that these best-looking visuals are intuitive and easy to navigate.
Deliverables: Interfaces (finally), hi-rez prototype and user testing results.
5 — MONITOR
We now track and experiment to see how the product is performing and how can we evolve it. The information we collect here can impact the product version planning or even change the business direction. We’ll follow the KPIs, collect data, A/B test, share what we learned with the company and connect again with another IDEATION phase, in the continuous product improvement loop.
We have analytics people dedicated to the product evolution and here they can not just create reports but come up with insights that can become data-driven design decisions in the future.
Deliverables: Performance reports, new improvement hypothesis.
WRAP UP
It’s important to notice that not every project has to go through each one of these five stages. In some cases, we may need to do something simpler, that doesn’t need that much research or, in others, urgent adjustments arise and we just need to be pragmatic. In these cases, we’ll most probably come back to the issues after everything settles down.
This was a brief explanation of what we’re working on as the AMARO UX framework today. Stay tuned for more updates in the coming months. If you’d like to know more on how the AMARO UX Framework looks like now, my suggestion is to visit our careers page and find an opportunity to join the team, we are always looking for new talent.
