DEV Community: UPDIVISION

[STRESS TESTING SERIES] The feedback formula. Getting useful feedback from your clients

UPDIVISION — Mon, 31 Jan 2022 08:38:16 +0000

This article is part of the Stress Testing series of our UFOs UI/UX Framework. The framework is a tool we created based on our 10+ years of experience in building complex software and thousands of hours of design meetings and feedback. Developers, designers and entrepreneurs can use this framework to gain a better grasp of the UI/UX process and build awesome apps as a result. To learn more about the UOFs UI/UX Framework and each framework component, please go here.

This article is part of the “s” from UFOs, the framework component that talks about how to ask for and get useful feedback on your designs from stakeholders, including your end users.

If you`ve ever presented a UI design project to a client, this scenario might sound familiar. You go into the meeting prepared with a nice speech and mock-ups for the core features of the app. The meeting goes well, even better than expected. The client seems engaged and they appear to like your ideas. At the end of the meeting, they promise they'll send feedback after they review the screens in detail.

A few days pass and you receive the feedback email, only to realize there is actually very little useful feedback. Rather than commenting on how your designs align with their business goals or on unaddressed requirements, the client seems to have missed the point entirely. The feedback revolves around colour choices, the size of the logo or even the copy when in fact you are still in the product discovery stage. This is the stage where you should be mapping out the core features and flows of the app. What went wrong?

Rather than using the presentation meeting just as an opportunity to show off your work, you can turn it into a feedback guide for the app`s stakeholders. This means not only explicitly telling them what kind of feedback you need, but also providing them with enough context to understand what they should focus on.

The following formula will guarantee you receive useful feedback, regardless of the stage your project is in.

Feedback formula: (what/who + context/problem + stage + feedback instructions) x tools

Each element of the formula is detailed below.

WHAT type of app? WHO are you asking feedback from?

The first thing you should consider is whether this is an internal application or a commercial app. Will the stakeholders be using the app themselves? The second thing is who are you presenting your work to. Are they business owners, marketing people, engineering people or even UX designers themselves?

Keeping these two aspects in mind will help you ask for feedback appropriate to their expertise. Of course, the end goal stays the same (e.g. building an inventory management app), but you will be surprised to discover various business angles depending on who you are asking feedback from.

Particularly if you are building an internal app, make sure to ask your stakeholders questions about their workflow as you are presenting, even if it's just an educated guess. This might make them aware of things which would otherwise go unnoticed. It can also serve as a good starting point when it's their turn to comment on your work. It's important to encourage clients to approach the designs with a critical eye from the get-go, so issues don't surface later in the project.

What is the CONTEXT? What PROBLEM are you solving?

If it's one of the first few meetings, remind the client of the overall context. For example, you might be working on a redesign project. The redesign project might consist in small touch-ups or in a restructuring of the entire app. Remind the client of either of these cases. This will help manage expectations and prevent scenarios where the feedback demands major changes when you previously agreed upon only on small, incremental improvements. Providing context for your work might also mean specifying the type of users who will be using the screens you are presenting. Or when in the user journey will the user be seeing these screens.

After offering some context, move on to the actual problem your screens are addressing. What are you trying to achieve with these designs? What task should the user be able to accomplish using these screens? Make it clear that the feedback should refer only to that/those tasks.

What STAGE is the design in?

Emphasize during the presentation the stage the project is in and how this reflects on the design and the type of feedback you are expecting. This will prevent comments like “put an icon on that button and move it to the left” when you are debating whether the entire section is actually needed or if it's in the right place (a common thing in redesign projects). If you are looking to solve structural issues, make that clear from the start. If the designs are in a more advanced stage and you want to dig deeper into the look & feel, CTAs or even headlines, make that clear as well.

What kind of FEEDBACK are you looking for explicitly?

Now it's time to put everything together and explicitly ask for feedback. At the end of the meeting, summarize the points mentioned above and encourage your client to give you feedback (you can also point out what they should ignore; e.g. “please ignore the colors, because we haven`t settled on a color palette yet”). Include some example questions to serve as a starting point for your client.

As an Operations Manager, could you please give us feedback on the e-commerce app we are redesigning? We agreed to keep the overall UI pretty much the same and focus on enhancing some key flows. So, please ignore colors, fonts or other aspects related to look & feel and focus exclusively on the new functionalities. Today we talked about Fulfilment and we introduced the possibility to track packaging tasks, particularly to see who packaged a specific order and how long it took. We also added the possibility of generating reports for managers to track employee productivity. We would appreciate feedback on these new Fulfilment features. Do you find the flow intuitive both for workers who need to log in their hours and for managers who need to track them? Are there any additional metrics you would like to track?

You can also specify a deadline for the feedback or the format in which you would like to receive it. Which brings us to our last point.

What TOOLS should the client use to give you feedback?

If you would like to receive feedback in a specific way, make sure to let your clients know. This can range from a bulleted email to comments provided directly in the design file (Figma has an in-built comments feature) or even dedicated apps for gathering user insight.

Stakeholders are your design and development partners, so getting useful feedback from them is essential. Plus, they can bring a unique perspective since they know the ins and outs of their business. Use the formula to get good feedback, understand the design problem space and develop solutions aligned with the business objectives.

Book Review - The Design of Everyday Things By Don Norman

UPDIVISION — Fri, 21 Jan 2022 13:24:49 +0000

Back in the ‘80s, Don Norman wrote “The Design of Everyday Things” out of frustration from all the objects he had issues using when he travelled to the UK: faucets, light switches, and even doors. The edition I read is a lot more recent, but his key points still stand.

This book is about the psychological aspect of design - the way objects should follow human needs and abilities. And most importantly, the way objects should be designed for proper use. Although the key subject is not web design, I believe this book is very helpful in learning the foundations of user experience design. After all, whether you’re building an app or a robot, people are still people. And they’re the ones you’re it building for.

Chapter 1: The Psychopathology of Everyday Things

Norman begins by talking about his notorious issues with doors. You must have, at least once, pulled a door that was supposed to be pushed, or pushed a door supposed to be pulled, right? This book’s author seems to make this mistake so often, this whole issue is named after him: “Norman doors”

The author’s key point here is that when you open a door wrong, it’s not your fault. It’s the design’s. Why? A proper design should signal whether a door needs to be pushed or pulled. And it shouldn’t require a written message on the glass to let you know.

Here is where Norman introduces 2 key concepts: discoverability and understanding. He says these are the two main characteristics of good design. With any product you must be able to figure out what you can do with it and how to use it.

Now, a major problem with many products is that the engineers who work on them don’t think about the end users enough: all they know and see is the logic behind it. People shouldn’t have trouble using a product if they carefully read a manual, they say. However, that type of thinking, says Norman, is a mistake: people aren’t as rational as engineers think.

The solution here? Human-Centered Design. A way of putting human needs, emotions and even limitations first. The key here, says Norman, is understanding your products’ potential users through observation. What’s their everyday life like? How would they use the product? What kind of actions would they take with it? Where could they encounter problems?

Discoverability is based on five concepts from psychology:

Affordances: the connection between an object’s properties and a person’s ability to figure out how to use it. For instance, a chair affords for support, therefore, sitting.
Signifiers: any sort of signal that tells you how to use an object: a “pull” sign on a door is a type of signifier, as it tells you how to use it.
Constraints: to make sure an object is used correctly, some actions are restricted, so you don’t ruin or accidentally do something.
Mappings: the connection between a control and what results from interacting with it. Think light switches and the specific lights they control.
Feedback: error sounds, text, you name it. This concept allows you to know if you’ve used an object right or not.

Another key element Norman talks about is that of conceptual models; which he explains in the figure below:

Photo source: Norman, D. A. (2013). The design of everyday things. New York: Basic Books.

Chapter 2: The Psychology of Everyday Actions

As the chapter title says, the author gets into more detail about the psychological aspects of one’s everyday life, the decisions they make. So he introduces the following 2 concepts:

The Gulf of Execution, where people try to figure out how an object operates.
The Gulf of Evaluation, where they try to figure out what happened after they used it.

How does this affect design? Product designers have to ensure these two gulfs are bridged. The key here is for the product to provide clear information about its state, in such a way that it matches the way the user thinks and it’s easy to interpret. For instance, if you can’t open a cabinet door, you should be able to tell if pulling it is not working so you can try another action.

And it gets more specific: Norman also talks about the seven stages of action. These stages are each paired with a question that reflect the steps one takes when doing something:

Goal - “What do I want to accomplish?”
Plan - “What are the alternatives?”
Specify - “What can I do?”
Perform - “How do I do it?”
Perceive - “Is this okay?”
Interpret - “What does it mean?”
Compare - “What happened?”

But how do we apply these to design? When using a product, people have to be able to answer all these questions. To achieve that, the product’s design must give enough information, which resides in things like constraints, mappings or signifiers. Think of the earlier example of doors - the handle should clearly show how you’re supposed to act on it and not allow you to use it otherwise. Or when using a stove, you should be able to tell which burner corresponds to which control, so you light the right one.

Keeping in mind this sequence, Norman says, helps guide the design process. This way, it’s human-centered. Plus, it also helps with product enhancement, as it allows designers to find what’s not working and improve it.

“We’re humans, so we know how humans think”, is an incorrect perception, Norman says. A lot of what the brain does is actually subconscious. Especially with things we know how to do very well and don’t need to pay too much attention to: walking, talking, reading. After we do something subconsciously, we explain it to ourselves consciously. In this regard, Norman presents 3 levels of thought processing:

Visceral: your quick, basic human instincts. This lets you know if something is good, bad, cold, hot, and so on.
Behavioral: largely subconscious, based on skills and patterns. Designers need to cater to this level by giving feedback.
Reflective: where the highest level of conscious emotions go.

Chapter 3: Knowledge in the Head and in the World

In this chapter, Norman gets into some detail about the human memory and knowledge systems. There’s knowledge in the world, which is readily available, easy to access, but it might take you some time to understand it. And then there’s knowledge in the head, which comes to you faster or slower, depending on your memory and the difficulty of what you’re thinking of. What you ate today might come to your mind faster, but what you ate a year ago today will take much longer to remember. This type of knowledge needs to be learned and it’s harder to use at first.

How does this come into play with design? Human memory is a key element here. When showing important information, make sure it stays on screen long enough so the product users have time to remember it. The quicker you throw information at them and the more it is, the harder it’ll be for them. This will lead to errors, and we don’t want that. People can get distracted and miss an important signal. They can enter the right information in the wrong place. The role of design is to make sure that doesn’t happen.

A key concept that shows the connection between knowledge in the head and in the world is that of mappings: When a product’s controls are properly mapped, whether you remember how to use it or not, it won’t be hard to figure it out. When it’s not, you’ll find yourself clueless, thinking you’re unable to complete a simple task. The example Norman gives here are stove controls and their burners, where proper mapping is key.

Here are the best ways to map products, says Norman:

Mounting controls directly on the items they control
Putting controls as close as possible
Arranging controls in the same spatial configuration as their objects

His suggestion for customers is to always try products before buying them, or at least mimic using them. This is so they can see if they’re easy to use or not, if the controls are confusing, or if they’re comfortable to use.

Chapter. 4: Knowing What to Do: Constraints, Discoverability, and Feedback

After an entire chapter dedicated to knowledge in the head, this next chapter focuses on knowledge in the world. Specifically, how designers can point people in the right direction when they’re met with a new product, action, situation. To this effect, Norman tells us about the importance of constraints, discoverability and feedback.

The author names 4 types of constraints:

Physical: if an object doesn’t fit somewhere no matter what you do, it’s most likely not supposed to go in there. Designers may put in such constraints so that people use products properly even when not paying attention.
Cultural: every culture has a set of actions you can take in a particular situation. Norman says cultural issues are the root of problems with new inventions, as there are no use standards for them yet.
Semantic: the meaning of things. Think motorcycle designs, there is only one obvious spot for the rider to hop on. Also, traffic lights. You know you have to stop at a red light, or go at a green light.
Logical: Norman gives the example of a Lego police motorcycle toy, where a blue beacon usually remains last, so there is only one place where it can go. That’s what he calls a logical constraint.

Here is where we learn about the legacy problem: be it confusing batteries or USB cables, some products have obvious design faults that can be fixed. So why aren’t they? Norman tells us it’s because changing the design of often-used objects (such as batteries) is too difficult and expensive. Lots of other products would have to change. The author says this is a classic example of corporate thinking, and we’re not escaping it anytime soon.

Norman explains the importance of placing affordances, signifiers and constraints to everyday objects. He gives a handy example: when using a door, we first need to find which side opens and how to move it. That’s the affordance. Next, we expect to see a plate, an extension, something that we can touch, grasp, turn, and so on. That’s the signifier. Last, we need to figure out how it operates, which puts signifiers and constrains hand in hand. If you pull a door that’s supposed to be pushed, it won’t open due to its constraints. In the author’s opinion, the best design that fills all these requirements are car door handles. On the opposite side lay cabinet doors. The latter can become quite unusable due to an exclusive focus on aesthetics.

A major design problem the author has faced, and which he uses to set an example, is that of light switches. He tells the story of how he demonstrates his ideas at talks by relying on how bad the light switches will be. It’s quite sad to think this is so frequent that he can always count on it, isn’t it? Lots of light switches, he says, don’t properly signal which lights they control. So what happens is people press everything until they get it right. Wash, rinse, repeat.

The author introduces a useful concept based on this example: activity-centered controls. Aside from setting controls based on devices, he suggests making it based on actions. That means having specific controls for video presentations (where the lights will be dimmed and the projector turned on) or for lectures (brighter lights and projector on).

This is where we really see what the problem is: lack of communication between the people and companies making parts of a system. The proper way to design a product is by carefully observing how one would use it, the specific tasks they use it for. And then molding the product to those findings.

Norman also talks about constraints that force desired behavior. This is common in safety engineering and he names 3 types:

Interlocks, which force tasks to take place in a specific order
Lock-ins, which prevent you from accidentally stopping a task too early. Think MS Word’s common “Do you want to save changes made to [your document]?”
Lockouts, which prevent an action from occurring or keeps someone away from a place, for safety reasons.

Chapter 5: Human Error? No, Bad Design

Many accidents are classified as human-error. However, Norman says there is no such thing. The issue is bad design.

In this chapter, Don Norman gets into specifics about the idea mentioned in earlier chapters. He says many products are designed without keeping in mind mental limitations. People can’t always be fully alert, remember every step of an action or complete confusing tasks. They get sidetracked, interrupted. And many product manufacturers don’t think about that enough.

The interesting thing we find out about here is that slips happen more often to skilled people. Since they’re experienced, they act subconsciously and might not pay full attention. But proper design should help them avoid mistakes.

Thus, for design, there are 4 types of relevant slips:

Capture slips: when instead of a desired activity, someone does something they did recently. Thus, in design Norman suggests avoiding procedures that have identical opening steps but then diverge.
Description-similarity slips: here designers have to ensure controls and displays for different purposes are significantly different so you don’t mix them up.
Memory-lapse slips: think using an ATM and forgetting to take your card after you receive your money. This used to happen so much that now you have to take the card out first. In design, you should minimize the number of steps to take to complete a task, or provide clear reminders of what’s left to do.
Mode errors: this happens when a product’s controls do different things when it’s in different states. Such products are made to fit in a larger number of controls in a smaller space. But in good design, you should know for sure when your product is in a specific state.

The design advice we get here is to always guide users so they know the current state of things in their objects (where needed). To have a proper conceptual model. To understand and keep in mind possible social pressures.

Machines, Norman says, aren’t intelligent enough to determine the meaning of our actions. So here are some tips on designing a product aware of possible errors:

Discover possible causes of error and design in such a way that they can be avoided.
Check if actions on a product pass a common sense test.
Give users an undo option.
Make it easy for users to know if they’ve made an error and to correct it.
Guide users to complete an action properly. Make it so interruptions or distractions don’t ruin an entire process.
Ask users for confirmation so they avoid doing something they didn’t actually mean to do. Eventually, you can make the element they act upon more visible. This way they’ll be fully aware of what they’re controlling.
Using sensibility checks. This applies to numerical values which can vary with different currencies and measuring systems.

But what if people are really at fault? Norman says one way is to conduct resilience engineering. This implies designing systems, procedures and training so that people can respond to issues when they arise. This includes constant testing and improvement. Ensuring your products have constraints, natural mappings, and enough information on their usage.

Chapter 6: Design Thinking

Don Norman says one of his consulting rules is never solving the problem he’s asked to solve. Why? Usually the problem brought to him isn’t the real, root problem, but a “symptom”. He says it’s essential to look into the root issue, to ensure the right solution is taken. This is called design thinking, he says.

We’re introduced to the double-diamond model of design. Here you start with an idea, investigate until you find the underlying issue, and then test out multiple solutions. This process is divided into 4 stages: discover, define, develop and deliver.

The human-centered design process, on the other hand, is made up of its own 4 stages:

Observation
Idea generation
Prototyping
Testing

Norman says it’s critical to properly observe your targeted users. This is so designers understand their interests, motives and needs, which they can then apply in their designs. This should also go hand in hand with market research, which is just as important.

The author lists a series of steps we can take when generating solutions:

Idea generation: also known as brainstorming. Norman tells us to come up with as many ideas as possible, to be creative without regard for constraints, and to question everything.
Prototyping: Norman suggests building mock-ups of each potential solution. They don’t have to be complex - they just need to help you find out how the product might actually be used by real customers.
Testing: gather a group of people as similar as possible to your target audience and have them use the product. Ask them about their thought processes in using it and see what you can find.
Norman suggests doing this both during problem specification and after creating the new design.
Iteration: keep on building by looking for errors and fixing them. The key here is action-centered design.

Here is where Norman comes in and tells us not to mix up activities and tasks: an activity is made up of a series of tasks. And designers have to ensure that their products provide support for its central activity, as well as the tasks it takes to complete it. There is a three-level analysis that is said to help in analyzing someone’s user experience:

Be-goals: fundamental, long-lasting, they govern a person’s being and determine one’s self image
Do-goals: the plans and actions to be performed for an activity
Motor goals: how the actions are performed, tasks and operations taken

However, the sad reality is that product manufacturing doesn’t go like that. Features are added to match the competition or due to new technologies. And development is always behind schedule and above budget, Norman says. Product development involves a variety of disciplines, from engineering to marketing, and the key is for everyone to work together. But in reality, it’s quite messy. Plus, in some cases the end users aren’t taken into account - and designers must please their clients.

Chapter 7: Design in the World of Business

In this last chapter, Norman tells us about the less ideal, real world, where product development doesn’t follow all the rules. There is a lot of pressure on companies to be fast and innovative, whilst worries about cost and competition might make things extra difficult. The author introduces 2 concepts:

Featuritis: adding new features to a product because customers want more functions, competitors are adding new features, or the market is saturated.
Creeping featurism: the tendency to constantly add features to a product, sometimes extending them beyond all reason.

Next, Norman talks about the tricky field that new technologies bring. They can push companies to innovate, but some products might be ahead of their time and fail at first. This, however, is a great opportunity for learning. On the other hand, new technologies often take a long time to be adapted - the HDTV resolution was set up many years ago, but took a while to come to our TVs. Why? The inconvenience of broadcast stations and regular people changing their equipment. The author says the rule of thumb here is 20 years from the first product demonstrations and another 10 or 20 until a widespread adoption.

He gives us the example of keyboards, where development took a very long time. They had to decide on the layout - circular, piano-like, in multiple rows; and letter order - alphabetical or not. The QWERTY format we know today was chosen after multiple experiments, all trying to avoid jamming of the levers connected to each letter. In fact, it’s said that this current layout was made so you can type “typewriter” using only the 1st row of keys. What this story tells us is the importance of testing and of identifying how a product will actually be used.

Norman tell us about 2 types of innovation:

Incremental: makes things better
Radical: changes lives and industries

Lately, there’s been a push for constant upgrades, new features, new technologies. Norman says the design of everyday things is in danger of becoming the design of superfluous, overloaded, unnecessary things. For the designs to achieve success, products need to sell. And they need to fulfill various qualities: satisfy needs, be usable, deliver positive emotions. The product might need to be upgraded, and it shouldn’t be a burden on the environment.

To wrap-up, Don Norman encourages designers to fight the battle for usability. To observe, to give feedback and encourage others to improve. He encourages users to support good designs and to give feedback to or boycott bad designs. It’s only together that we can improve the way products are made, and all it takes is getting to know ourselves and how we use them.

Dear UI/UX designers: here’s how to work with developers

UPDIVISION — Wed, 19 Jan 2022 09:17:24 +0000

UI/UX designers and software developers work together a lot. And a big part of good software development is making sure they do it right. To new designers, it might not be easy to do this: how can they know what the developers need from them? Can they only find out the hard way? Well, we’re here to give you some tips from our experience.

So where does it go wrong? A lot of times, potential issues start at the beginning of the designing process. Designers make certain style choices that no framework or plugin can recreate, or which look good in concept but might be difficult to code and/or use.

Or, let’s say they make all the right choices in terms of design that can be coded: but when doing handover, designers might unintentionally leave out important information which will later lead to many messages from the development team.

So how can we fix this?

Set the record straight. From the beginning.

Showing developers what you’re working on from the beginning can be of great help. Let’s say you’ve made one screen that shows the main layout and some key features. Send a screenshot or link to the development team (or just the team lead, as you see fit) and ask them if it’s all do-able. This way, you won’t have to re-do multiple screens if you continue on with the same base design and structure.

And another advantage of doing this is that developers can prepare ahead of time, they can figure out which technologies and plugins they’ll need to use, and which team members are the best fit for the job. And most of all, they can point out what can’t be done and what needs to be changed.

Another thing you can do here is, when you’re designing a more abstract element that you came up with, show them to your development team to make sure they can code it. If they can’t, ask them to tell you how you can improve the design so it’s not painful for them to code. The key, in the end, is communication. And doing it properly (i.e. don’t hide things from them and give them all the info you can give).

Make your design files less of a maze.

Your design file will be the blueprint for the development team’s work. And blueprints have lots of data on them - after all, they’re used in architecture. You should treat your design files the same as an architect treats a blueprint: don’t make developers try to guess what the author meant.

How do you do this? Use headlines, subtitles, arrows, whatever seems fit, and give info about the user flows in your design. Anything that isn’t entirely obvious can come with a little note. For instance, say you have a Delete button somewhere. Ideally, users should be asked if they’re sure they want to delete the selected item. If you didn’t make a separate screen for that, it won’t be obvious for the developer. So make note of it next to said screen. Similarly, when designing in-line edit features, either show each instance of said feature or tell the developers, through a text next to the screen, how it works.

So far, we’ve written two entire articles about having organized design files (check them out here and here). This is another thing that can help you work more efficiently with developers. If they can’t manage to go through your design file, how can they properly understand what they need to code? So here are the main things you should keep in mind:

Name your design file pages accordingly: if you have an extra page containing screens that won’t go into the final app (either trial runs or older versions), signal that in the page’s title. As little as a red dot or X emoji should be enough.
Order things properly. A good way to divide app screens into design file pages is going by the app’s big menu items. But what you shouldn’t do is reverse that order: you might start with certain screens and end with the middle of the app. But when the design is done and ready for developer handover, put everything in a logical order. Begin with the authentication pages and continue with stuff like account management, user management, and then each menu item. Alternatively, you can ask the development team what kind of order is ideal for them.
Arrange your screens in a tidy way. Don’t put things all over the place. Arrange your screens one below the other, in one column or more, depending on how many you have. Making the document messy will make things difficult for the development team.
Sort the screens using big headlines. Think about the look of your design file pages when you’re fully zoomed out. Can you find a specific screen in less than 2 minutes? If not, use big headlines to sort the screens. Let’s say you have a series of user management screens and some user profile screens. Arrange them in separate horizontal rows, next to each other, and put big headlines above them to show what the screens contain. This way, when you’re zoomed out, you can see which screens are the user management ones and which are the user profile ones.

Help them navigate design software.

Picture this: you spend extra time making a shadow for a certain design element. Weeks later, said page gets implemented and you get to see it. But the shadow looks completely different. So where did it go wrong? It’s simple. If you’re using Figma (though this probably applies to other programs too) you sometimes have several nested elements. To you it makes sense, and you know you have to click on something multiple times to get to the base layer or background, a.k.a the element with the custom shadow. But developers who don’t know much about Figma probably don’t know that. And they’ll try to eyeball it - but they’re not designers, and it won’t look the same.

Here are 2 different ways you can approach this:

Setup color, typography and shadow styles (or presets) throughout the design process. Once you’ve done that, when someone selects a design element, even if it’s a group with several nested elements (let’s say, a pop-up with a headline, inputs and buttons), they’ll be able to see all the styles used.
Show the developers, in a meeting (so it’s all clear), how they can see all of these style elements. Most of all, show them how they can view their CSS version too (in Figma, it’s the Inspect tab on the right side panel).

But these are very specific elements. It would be useful, especially for new team members, to give them a walkthrough of the design software you use, so they know their way around. While you’re at it, you can also show them how you sorted screens so they won’t have troubles figuring that out.

It’s all talk - and action.

This is less of a tip you can apply right away, but it’s always good to keep this in mind. Being transparent and open with your development team can help make sure your designs come to life the way you envisioned them. Even if you follow everything we’ve just said in this article, questions might still come up, and it’s essential that you’re available to answer them.

Make group chats with the whole team, make sure no details get left out or can be accessed only by some team members, and participate as much as possible in any team meetings. And most of all, make sure that if you decide something with one or two team members that affects the entire project, don’t keep it amongst yourselves only - share it to the group chat so everyone knows.

If you also happen to test the app that is being built (and which you designed), be careful with the way you give the development team feedback. Don’t berate them, insult them, or tell them they’re not good enough. Sometimes they make honest mistakes. And if anything doesn’t look the way it should, simply point it out and tell them how it should actually look. Make sure to understand the limitations of code, and that not anything will look 100% the way you want it to. Maybe 99%.

And there you have it, now you know a few more things about how to work efficiently with developers, as a UI/UX designer. Overall, we’re all people, and aside from a few technical things you can improve, the most important thing is interacting like peers, being nice to each other and not being afraid to communicate.

Build your apps in record time with Backpack and the Backpack Figma Template

UPDIVISION — Fri, 14 Jan 2022 15:34:41 +0000

A couple of months ago we began a new internal project: an IT dictionary, where non-technical people can find witty, well-explained definitions for tech terms. We called it Get IT Dictionary, and it recently came to life.

Starting with the basis: the backend

Development projects always start with a setup. Here, we began by installing the frameworks and packages we were going to use: Laravel, Livewire, Backpack for Laravel, Tailwind, Choices.js, Fingerprint.js.

Afterwards, we worked on the logic behind the functionalities to understand what our database and models should contain (attributes, foreign keys, relation type). We started off the backend portion by identifying the entities we’ll work with - such as words, definitions, categories or letters. We referred to the design to identify these elements, which made the process easier.

After that, based on the functionalities, we added specific attributes or relations between them. For example, a word could have one or more definitions, or one or more categories. And of course, each word belonged to a letter.

Then, we dove deeper into the backend portion - starting with coding the types of operations admins can take to manage the website, like adding, editing and deleting words, definitions or categories.

A Backpack with just the right tools

A big part of this project was Backpack for Laravel. Backpack gives the chance of customizing or adding buttons or features. Backpack’s main feature is that it helps in creating, editing, deleting and displaying your item. Besides that, we were able to add custom buttons for different operations like approving or disapproving submissions, or for making big imports work.

The Backpack Figma Template helped guide us in terms of design and functionalities. Plus, having everything laid out with all the details really helped us understand the app’s logic. As for Backpack itself, it helped a lot with the CRUD operations - which, in turn, made the coding process easier

Making it all click together

The backend was done, which meant we were ready for the next stage - the frontend. This was coded using a CSS framework, Tailwind CSS. We started by applying Tailwind CSS classes to our page - and if we needed something more peculiar, we’d create custom responsive CSS classes for those tricky elements. This way, we managed to follow the design without sacrificing functionality.

Once this portion was complete, we used Livewire to make sure the frontend and backend match up. Livewire makes it pretty easy to create a connection between the two - and the testing round proved its efficiency.

Bug fixing and trouble solving.

As much as we wanted to celebrate the end of the coding portion, a big chunk of work was still ahead of us: bug fixing. This was the part that took the most time. Finding bugs was easy for the most part, since there were more people testing the staging branch. Fixing them was straightforward as well - we would identify the issue, discuss what caused it, and we’d figure out how to fix it.

Overall, we learned a lot from this project. Backpack and its Figma Template made the process so much smoother - the design was done in no time, the devs didn’t need extra design help, and planning the project took way less. Our website was up and running in no time.

Ready-to-code design: build your apps in record time with the Backpack Figma Template

UPDIVISION — Mon, 10 Jan 2022 09:35:47 +0000

We’re a software development company. And oftentimes, we use complex tech words with our clients. But some of them aren’t technical people. What does this lead to? Lots of confusion.

So we had an idea: a dictionary that lets non-technical people understand even the most complex dev terms. The real question was: how do we make it happen?

We called it the “Get IT Dictionary”. Get it? We gathered a series of dev terms - think programming languages, computer terms, dev processes - and created witty, detailed yet accessible definitions for them. Think Urban Dictionary, but for tech.

And we knew from the start what would be the fastest way to build it: using Backpack for Laravel. This way, our devs didn’t have to spend weeks building CRUDs and adjacent features from scratch - and they could freely customize everything. Luckily, using the Backpack Figma Template, devs don’t need to get creative: designers can use it to quickly build ready-to-code admin panels.

Putting the frontend pieces together - the custom design part

This was a user-centered app, so we chose to make our own design, from scratch. No templates, no nothing. So we began by building the homepage: we created a big headline and a search box right at the top of the page, and then brought a tetris-like pattern around them, to add some color. Next, we made a section that would feature 2 words - a word of the day and a random word - so that users can get a preview of what they can learn from this website. Below that, we made the ‘Browse by category’ and ‘Browse by letter’ sections, to show users the ways they can browse definitions on the website.

All of these sections let us know what the main pages should be (aside from the homepage):

A search results page,
A browse by letter (for a specific one) page,
A category page, and
A word definition page (for one or more definitions)

Plus, we added a few things into the header and footer - the header contained dropdowns to all the letters and categories, a Submit button and a newsletter button. Meanwhile, the footer contained legal things like a Privacy Policy and DMCA.

When it came to the logo, we wanted to make something fun. We already had some color on our homepage, so why not use it? We went for a highlighter concept and gave each portion of the logo its own background color: “get IT” got a shade of yellow and “dictionary” got a white-based mint. We also added a “?!” on the front, for the fun of it. This one got a pastel coral background. To keep with the tech concept, we used Source Code Pro for the font.

Tackling the nuts and bolts of the backend - the Backpack Figma Template

People often think about an app’s frontend side first, leaving the backend as an afterthought. But for apps or web platforms that need content management, having an admin panel is a given. And we knew the Get IT Dictionary needed one too - and we wanted to build it as quickly as possible.

The solution? Backpack for Laravel, plus its Figma template - a project we’d recently finished and which provided all the pages we needed to design CRUDs.

What is Backpack for Laravel, you might ask? Backpack is a collection of admin panel packages. It uses Laravel, Bootstrap & jQuery and it comes with HTML building blocks, through which pages, dashboards or widgets can be built. In short, it’s a much faster way to build Laravel admin panels.

The Figma template that we made for it helps both devs and designers: every page was recreated in Figma so designers can freely reuse them and edit them to match their projects. With this, the developers’ job is much easier: all these items are building blocks that are code-ready and easy to implement. Most of all, they’re fully responsive. In other words, designers can use it to quickly build screens, which can then be easily coded by the devs.

So how did we use the Backpack Figma Template for the dictionary? Here’s the step-by-step process.

1. Figure out what you need CRUDs for

We’d already built the frontend to our dictionary website. So it was clear what we needed to include in the admin panel: words, categories, letters and ads. All of these needed their own CRUDs, which meant creating a list, create, and edit page for each of them. The delete option only prompts a pop-up, so we didn’t need multiples of it.

2. Make the list page/table view of the elements you need to manage

This one is a bit tougher - a lot of thinking goes into it. You have to know exactly what kind of info you need to see for each item. But once you’ve figured that out, the other pages (create and edit) will be done much quicker.

So here’s what we did: we went onto the Example - Manage Articles page within the Backpack Figma Template. We grabbed the first page, which is the Articles list-type page, and copy-pasted it into our document.

We then grouped every column (to make it easier to move them around) and got to renaming things. Since we began with the Word List page, we had a series of columns, such as definition, part of speech or category.

3.Make the create and update pages

The hardest part is done: once you know what goes into the list page, you know what goes into the create and update pages.

We grabbed the Add Article screen from the Example - Manage Articles page and added it to our document. Then, we adapted the inputs to what we needed (basically, the columns on the list page). This one, technically, can get a bit more challenging. But to make your work easier, here are some tips:

Group the inputs and everything they include (the title, required asterisk, any dropdown arrows). This will make moving them around easier
Lock the background of the inputs so you don’t accidentally move it around
If you need other types of inputs that this page doesn’t already come with, go to Backpack Components, head to Fields - Normal Container and look for the type of input you need. Alternatively, use the Assets tab and just search for what you need. Make sure to grab the ones with ‘XL’ in their name, so it fits the container perfectly.

What we did here wasn’t too complicated: the important part was knowing what kind of input each item was, and we either edited the existing ones, or added new ones from the Fields - Normal Container page within the template.

The Update page is pretty much the same thing, except all the inputs are filed: so while you’re on the Backpack Components page, slide over to Field States (zoom out as far as possible if you can’t find it) and grab the filled-out versions of the inputs you used.

Alternatively, head back to Example - Manage Articles and use Edit Articles as a reference for text styles and positions.

What about the last step of a CRUD, the delete action? This will go through the actions section on the list page - which is already included in Articles (so feel free to take it as it is). And the only visual thing it needs is a pop-up, which you can freely take from, you guessed it, Example - Manage Articles.

4.Refine and add instructions

Your design is ready for the developer handover. So how can you make their work less difficult? Add notes where necessary - if you have dropdowns, tell them what goes into them. If you have some special features on the frontend side, let them know how they happen in the backend.

For instance, in the Get IT Dictionary, we have a “word of the day” feature. Since Create Article already had a checkbox for “Featured item” we decided to leave that in and use it for the word of the day. Since the code for this feature already exists in Backpack, the devs can simply take it and add it into their code.

There you have it: this is how we designed the backend portion of the Get IT Dictionary. Overall, using the Backpack Figma Template sped things up a lot, not just for the design but also for the code part. Our devs built it quick and easy - in fact, the frontend custom design took much longer to code.

Curious about the Backpack Figma Template? Check it out here.

Book Review: Refactoring UI by Adam Wathan & Steve Schoger

UPDIVISION — Mon, 03 Jan 2022 10:26:45 +0000

Written by “a fullstack developer who used to suck at design” and a UI/UX Designer, “Refactoring UI” could have just as easily been called “Cheating at design”. And that's the great part about it. It gets talent out of the picture and focuses instead on practical, time-tested advice for making UIs look good.

“Refactoring UI” is a great confidence booster for beginner designers or developers who are tired of Bootstrap, but fear experimenting with design. And, because it answers the whys in addition to the hows, you quickly get a sense of why an interface looks like a disaster and what you can do about it.

So, does your app look, feel and behave more like a “user inyourface” than a “user interface” ? Next time, ask yourself if the problem might be one or even all of the following:

Workflows
Visual Hierarchy
Layout & Spacing
Typeface
Color
Depth
Images
The Small Touches

Workflows

There are things which can doom a project faster than you can say “sprint”. The first chapter summarizes some of the most common mistakes when starting out on a project. Unsurprisingly, most have to do with how you organize your work.

1. Starting with the layout, instead of a feature. Focusing too much on the layout is a sure way to get stuck. Instead of asking yourself “Should it have a top nav or a sidebar?”, “Should this item be on the left or right?” start with what the UI should do and let that guide you. If your users need to search for a flight, you already know you need a datepicker for departure and return date, an input field for departure and destination city and a search button. That`s 80% of work right there.

2. Going too in-depth straight away. This could mean worrying over the color palette before even getting the features down, or adding in features which take forever to code and don`t bring much initial value. At the end of the day, a comment system without the possibility to attach documents is still a working comment system. In a similar manner, the authors suggest designing your first screens in grayscale and adding color later. This eliminates any distractions and the need to make color choices early on.

3. Working without a system. Design systems prevent decision fatigue by limiting your choices. It's like a gift for your indecisive/forgetful future self. And they also keep everything looking consistent throughout your screens. At a minimum, try to define in advance:

font sizes and weight
text color (primary, secondary, tertiary content)
icon sizes
button sizes and padding
box shadows
border radius

4. Choosing the wrong personality for your design. There are a lot of things which go into how a page looks and feels, but the following are some of the most important. Getting these wrong will most likely make your design feel inadequate.

font choice. A serif typeface spells “classic” and “elegant”, while rounded sans serif feels more playful. Choose wisely.
color. Imagine a pink corporate banking app.
border radius. Might seem like a small detail but it can have a cumulative effect, especially when you work with cards. A small border radius is pretty neutral, while an increasingly larger border radius starts to feel more playful.

Visual Hierarchy

Do your users have a hard time finding important information fast? Does identifying the “Add” button feel more like finding Waldo? Or reading content off a card more like being met with a block of text straight in the face? Then your interface might be missing visual hierarchy cues.

As the book points out, not all elements of an interface are created equal (sorry, hundreds of years of democracy). To help users figure out how to navigate an app, UI designers emphasize or de-emphasize elements using one or more of the following. Ultimately, this is what gives your app a “designed” look & feel, instead of it just being a random accumulation of elements.

1. Size: this is an obvious one. You signal the importance of an element by increasing or decreasing its size. But, as the authors repeatedly mention, don't overdo it. Not even for section titles. Just because it makes sense semantically for something to be a h1, it doesn't mean you have to fall in the trap of making titles bigger than they need to be. The content, not the title, should be the focus of the page.

2. Weight: be it fonts or icons, weight is a great alternative to size for making things stand out or be barely noticeable. If increasing the size looks weird or creates too big of a difference between primary and secondary content, keep it the same size and make it bold. Just like bold text, solid icons cover a lot more surface area and hence look heavier on the eye. However, unlike text, there's no way to decrease the “weight” of an icon (unless you choose a different icon style). Which leads us to the third point.

3. Color & contrast: when weight doesn't do the trick, you can adjust visual balance through color and contrast. For example, when you put an icon next to some text, the icon tends to automatically feel emphasized. A simple way to create balance is to lower the contrast of the icon by giving it a softer color. Reducing contrast makes heavy elements feel lighter, even though the weight hasn't changed.

You can also apply this to text. Greys work great for secondary text on a white background. For a colored background, instead of greys, choose a text color close to the background color and adjust the saturation and lightness. This will de-emphasize secondary text without making it look washed out.

Color is a great way to create hierarchy for text because you don't need to sacrifice readability by making the font smaller:

A dark color for primary content (like the headline of an article)
A grey for secondary content (like the date an article was published)
A lighter grey for tertiary content (maybe the copyright notice in a footer)

4. Placement: is secondary content competing for attention with your primary content? Simply place the secondary content directly on the page background. Sometimes, all you need in order to emphasize an element is to de-emphasize the surrounding ones.

Ultimately, what visual hierarchy does is to:

Make interfaces less noisy and chaotic
Improve navigability by allowing you to signal what the main content or action on the page is. Most pages only have one true primary action, a couple secondary actions and few seldom used tertiary actions. This should be made clear through button design.

(Pro tip from the authors: if a destructive action isn't the primary action on the page, don't emphasize it. You can use a confirmation modal and let the destructive action be the primary action there).

Improve readability by relying less on labels. Emphasizing identifying information through font weight, color or size allows you to present data without labels, especially when the data format is intuitive (e.g. phone number, email address). This also makes it easier for humans to read your content, as opposed to robots (or developers) who are much more accustomed to the label: value format :)

Layout & Spacing

Similar to visual hierarchy, this is another important factor in making something look “designed”. Chapter two highlights several guiding principles for working with layout and spacing.

1. Leave space for your design to breathe. One of the fastest ways to clean up a design is to give it more room to breathe. However, rather than adding padding to a design which feels crammed, the authors suggest starting the other way around. Leave a bit more white space than needed when you design and then adjust accordingly. To make something look great, you will often need more whitespace than you initially thought.

2. Establish a spacing and sizing system. However, keep in mind that size is relative rather than absolute. At the small end of the scale (like the size of an icon, or the padding inside a button), a couple of pixels can make a big difference. Whereas, at the large end of the scale (like the width of a card) a couple of pixels make virtually no difference. So, when defining a sizing and spacing system, the authors suggest starting with a base value and then building a scale using factors and multiples of that value. Here is how a scale using 16 (the default font size in every major web browser) as a base value looks like:

3. Don't force it. Not every decision you make needs to be based on a system. Sometimes, trying to force everything to follow the same rules leads to monotonous or downright bad design. For example, making something full-width just because you have the space for it might make your design harder to follow (like the cart in the screenshot below). Or making something full width (e.g. login card) just because another element on the page is full-width (e.g. navbar).

In a similar manner, not all elements should be fluid. Outsourcing all layout decisions to a grid can do more harm than good. There are situations where it makes more sense for an element to have a fixed width instead of a relative, grid-based width. For example, if the sidebar menu of an admin dashboard scales, it will get increasingly wider, taking up space that could’ve been put to better use by the main content area.

Avoid ambiguous spacing between elements. When groups of elements are not separated by a border or through background color, things can get confusing. Users might even end up accidentally filling in data in the wrong field. In these cases, the UI should make it very clear which element belongs to which group by properly spacing labels and inputs.

Look at the screenshot below and pretend it's Black Friday. You have 5.5 seconds to place your order or some fast-fingered little punk will end up with the latest Nintendo Switch at half the price (and he's not even paying for that! he's still in middle-school). Where would you fill in the City?

Typeface

We've already seen font choice plays a big part in a design's overall personality. So, before you even consider using Comic Sans, make sure you browse chapter four, dedicated entirely to working with text.

1. Once again, define a system. Most interfaces use too many font sizes. A font scale needs to have enough options to cover anything from large headlines to copyright notices, but not so many that it defies the purpose of a system. The authors recommend a scale of 11 font sizes, with smaller jumps between sizes at the bottom of the scale (2px) and increasingly larger jumps between sizes as you go up (up to 12px). Again, size is relative. At a larger scale, a one-pixel increase or decrease will likely go unnoticed, as opposed to a smaller scale.

So, the scale would look something like this:

12px (teeny-tiny disclaimer “By agreeing to these terms & conditions you are hereby renouncing your soul”)

14px

16px

18px

20px

24px

30px

36px

48px

60px

72px (really large headline)

2. This might seem obvious, but...use good fonts. This means both fonts vetted by time and use and fonts adequate for the job. Typefaces that come in a lot of different weights tend to be crafted with more care and attention to detail than typefaces with fewer weights. The authors recommend not using typefaces with less than five weights. Also, font families are usually designed for a specific purpose. Sometimes using a good font means using the best font for the job. Fonts which work great for headlines have tighter letter-spacing and shorter lowercase letters (e.g. Futura PT). Fonts meant for smaller sizes have a wider letter-spacing and taller lowercase letters (e.g. Proxima Nova).

3. Figure out the proper alignment. Aligning text can be tricky, especially when images are involved or multiple font sizes (something you often find on cards). The best way to align multiple font sizes is by their baseline - the imaginary line letters sit on. This takes advantage of a point of reference that your eyes already unconsciously perceive.

Also, what works for headlines and short text, usually doesn't work for long paragraphs. Headlines and short text look good center aligned, while anything longer than two or three lines will always look better left-aligned. Sometimes, the only way to fix alignment issues is by rewriting content to make it shorter, so don't be afraid to put your editor cap on.

When it comes to numbers and tables, right-aligning numbers makes them easier to compare at a glance, because the decimal will always be in the same place.

4. Keep readability in mind. Line length, line height and font size play a big role in how easy it is to read text.

Line length - lines that are too long make text harder to read. This usually happens when you try to fit text to the layout, instead of focusing on the reading experience. The book's recommendation is to keep paragraphs around 45 and 75 characters per line. You should limit paragraph width even when the overall content area is larger, like in the example below.

Line height - determines how easy it is for the reader to find the next line when the text wraps. If there isn't enough space between lines of text, you'll most likely end up reading the same thing twice. Things get even worse when the lines of text are long, because your eyes need to make a bigger jump to get to the next line. This means, line length and line height need to be proportional. Narrow content manages with a shorter line height, while longer lines of text need a taller line height.

Font size - On the other hand, font size and line height are inversely proportional. Small text needs additional line spacing to help readers find the next line. Larger text needs less space between lines, a line height of 1 usually being perfectly fine.

(Pro tip from the authors: for busy UIs where almost everything is a link, like a news portal, you can improve readability by tweaking the link design. Emphasize links in a more subtle manner, like using a heavier font weight or a darker color. Alternatively, consider adding an underline or changing the color only on hover).

Color

If you've ever wondered how you're supposed to use one of those online color palette generators, the short answer is you're not. Or at least, not like this:

The fifth chapter explores tips & tricks for people who can't do color, like myself.

1. You need more colors than a color palette generator leads you to believe. You can't build anything using only five hex codes or only solid, high contrast colors. What you really need for a color palette is:

one, maximum two primary colors with 5-10 shades for each [used in pure form for primary actions, active navigation elements etc. This primary color is usually the brand color
8-10 shades of grey [used for text, backgrounds, panels, forms etc.]
around three, four accent colors with several shades for each [used for various semantic states like new items, destructive actions, warnings, positive trends]

Defining each palette:

start with the color in the middle that your lighter and darker shades are based on. In the case of primary and accent colors, pick as the base color something that would work well as a button background.
pick your darkest shade and your lightest shade. Start with a color that matches the hue of your base color and adjust saturation and lightness to make it darker, respectively lighter. To see the colors at work, maybe create a component like an alert using your darkest color as text and your lightest as background.
fill in the gaps between the base color and the extremes. For most projects, six additional shades will pretty much do it.

(Pro tip from the authors: greys don't have to be grey. Give your greys a cool feel by saturating them with a bit of blue. To give your greys a warmer feel, saturate them with a bit of yellow or orange. To maintain a consistent temperature, don’t forget to increase the saturation for the lighter and darker shades.)

2. Accessible doesn't have to mean ugly. To meet the recommended accessibility contrast ratio, the background color needs to be quite dark, especially when working with white text. This can create a hierarchy problem if that element isn't the focus of the page, as dark colored backgrounds tend to grab the user's attention. And it doesn't look great either. You can solve this problem by flipping the contrast and having dark colored text on a light colored background. In a similar manner, when working with white text on a colored background, you don't want your primary and secondary content to look the same. Instead of a washed out, unreadable grey for your secondary content, you can rotate the hue towards a brighter color and use that. This way you'll still be keeping the recommended contrast ratio.

3. Don't rely on color alone. Always use color to support something that your design is already saying, never use it as the only means of communication. Make sure to add + and - signs for trends, instead of relying on color alone. Or use contrast between different shades of the same color for charts instead of using completely different colors. In both cases this makes it much easier for color-blind people to read your design.

Depth

Part of what makes Material Design such a popular design language is the way it handles depth. In fact, the entire Material Design philosophy is inspired by the physical world and its textures (hence “material”), including how it reflects light and casts shadows. This is also the focus of the sixth chapter which deals with simulating light sources in user interfaces and how that can boost a plain-looking design.

1. Use shadows to convey depth and interactivity cues. As in real life, the smaller and less blurry the shadow is, the closer to the background that element appears to be. Larger and blurrier shadows make elements feel more elevated and closer to the user. Small shadows are used for buttons, while large shadows work great for modals, where you want the user's full focus.

Besides creating a sense of depth, shadows can also be used to indicate an interactive element. For example, adding a shadow to a row item when a user clicks it makes that row pop out and it also makes it clear to the user that she can drag that element. Similarly, you can make a button feel “pressed” by switching to a smaller shadow or even removing the shadow altogether.

2. Use two shadows for better control. Using two shadows for an element gives you a lot more control than a single shadow. The first shadow is larger and softer and accounts for the light cast behind an object by a direct light source. The second shadow is smaller and darker and accounts for the area underneath an object, barely touched by light. This second shadow is most distinct when elements are very close to the background and grows increasingly invisible as elements become elevated.

3. Flat design can have depth too. By definition, flat design is scarce on shadows. However, this doesn't mean it can't convey depth. It just does it in a different way. Flat design can convey depth through color and solid shadows. Especially with shades of the same color, lighter objects tend to feel more elevated, while darker objects feel closer to the background. The second method is to use short, vertically offset shadows with no blur at all. This allows you to use shadows without sacrificing the flat design look.

4. Overlap elements to create layers. One of the easiest ways to create depth is to overlap different elements to make it feel like a design has multiple layers. The most common example is a card which crosses between two different backgrounds. You can also overlap images by giving them an invisible border, so there's a small gap between them.

Images

An image speaks a thousand words, but only if used properly. Otherwise, it can ruin a perfectly good design, as shown in chapter seven.

1. Text needs consistent contrast in order to be readable. Nine times out of ten, adding text over an image renders the text unreadable. This is because text needs consistent contrast, while images usually have varying dark and light areas. Dark text looks great in light areas, but becomes unreadable in light areas and the other way around. To make images better backgrounds for text you can:

add a semi-transparent overlay
lower the image contrast (and maybe combine this with some text shadow)
colorize the image with a single color

2. Everything has an intended size. Even if they don't lose in quality, scaling icons meant for a different size can end up looking unprofessional. Icons that were drawn at 16–24px are never going to look very good when you double or triple their size, because they lack detail and they will always feel disproportionately “chunky”. Alternatively, downsizing a detailed icon to favicon size will turn it into a mess as the browser tries to render that level of detail in a tiny square.

If you want to include full-size screenshots of the app in your design (for a presentation page), don't shrink the screenshot to make it fit. It will look like you`re trying to fit everything but the kitchen sink in a single image and visitors will end up squinting. Instead, consider using a partial screenshot, which highlights a certain feature. If you really need to fit a whole-app screenshot, use a simplified version of the UI with details removed and small text replaced with simple lines.

4. Beware of user-uploaded content. That is content which you can`t control in terms of styling. However, there are some things you can do to make sure uploaded content doesn't completely ruin the design. You can control the shape and size of uploaded content through fixed containers or prevent background bleed (when someone uploads something with a similar color to your UI's background) by using a subtle inner box shadow.

The Small Touches

Sometimes an app doesn't need a full-blown redesign to really shine. Small adjustments and tweaks can make a big difference, as the last chapter demonstrates.

1. Add a more visual twist to what's already there. This can mean either replacing bullets in a list with icons or turning quotation marks into visual elements by increasing their size and changing their color. You can also style links by giving them a different color than the boring blue associated with hyperlinks or a different weight. If you're working on a form, using custom checkboxes and radio buttons in the brand color is an easy way to liven the page up.

2. Add some personality with accent borders. A simple trick to add flair to a design is including colorful accent borders to parts of your interface (such as the top of a card, along the side of an alert message or even across the top of your entire layout).

3. Don't be afraid to decorate backgrounds. Sometimes, no matter what you do, a design will still look plain. Add some excitement by changing the background color, using a slight gradient or even a subtle repeatable pattern or a background shape. It doesn't have to be across the entire background, often repeating a pattern alongside a single edge can look awesome.

4. Use fewer borders. Resist the temptation of separating elements by using borders. What you can do instead is use box shadows, use different background colors or add extra spacing. Shadows, color and spacing are the best ways to create a distinction between elements without making the interface look busy or cluttered.

Conclusion

From relying only on size to create hierarchy to using borders for everything, “Refactoring UI” has seen it all. But it doesn't judge. And, for something which has often been compared to a joke (if you have to explain an interface, the UI is probably not that good), the book does a really good job explaining UI.

How to keep track of all your design project edits

UPDIVISION — Tue, 14 Dec 2021 12:47:04 +0000

Designing an app is not easy. And sometimes we focus so much on what we’re creating, that design files become very disorganized. After all, you're getting the job done, right? Why would we need to put time into getting the design organized? Well, as you might have discovered (the hard way), having a messy design file makes it very difficult to find things when you really need them.

We’ve previously talked about being organized in Figma, and the best workflows in terms of design file tidiness. In this article, we wanted to address a more specific issue in UI/UX design: what happens when you make several different versions to a design, whilst keeping every single screen? Chaos. But that’s what we’re trying to avoid.

A lot of times, we make minor changes to a design that need to be applied to multiple screens. The original screens are kept in case the clients change their minds and want to go back to the original design. But oftentimes we end up having 5 slightly different versions of the same screens.

So how do we navigate that?

It’s all in the naming.

The easiest and most basic thing to do is giving each page iteration a different name. It can be as simple as a “V1, V2” -type thing. This, of course, means keeping all the different iterations of your screens in separate pages. And make sure everything in one iteration’s page actually belongs there - if it’s centered around a specific design modification, make sure all the screens in said page have that element.

Now, just adding a V1 or V2 to a page name might not be enough. So here comes another suggestion: add big headlines in your design document to explain what sets that page apart from others. It doesn’t have to be complicated: just a paragraph of text should be enough. Think of it as a post-it you’re putting next to a specific item as a reminder - “These pages contain a different color scheme than Ver. 2” or “An alternate version of the header across all screens”.

This doesn’t only apply to document page names. It’s also good practice to name your screens accordingly: if you used a different color scheme on some screens, put them next to the original ones (for comparison sake) and include “alternate colors” (or anything that makes sense to you) in the screen’s title. Don’t leave the same title on multiple screens, and definitely don’t just call them “v2”, “v3” and so on - it’s too unspecific and is bound to create confusion when you return to these screens.

Keep a separate page for non-final designs

Let’s first discuss a more basic part of UI/UX design file organization: what’s the best way to sort screens into design document pages? We’ve come to discover that it’s best to keep all the screens in one page - that is, unless the app you’re designing has A LOT of screens (in which case it’s best to divide them by subject or menu items). And when you do this, you get a lot of room to sort “non-final” designs, or “trial runs”, if you may.

What we do is keep a separate page called ‘Archive’ for old screens that won’t go into the final app but which we decided to keep, just in case. We also create another page called “Trial and error”, where we keep screens that we’re making new versions of - and which aren’t final or “good enough” to go into the main design file page. By doing this, there’s no confusion about which screens can head into development and which ones are just ideas.

A simple way to divide these pages visually is by using emojis: a checkmark for approved screens and a hand holding a pen for pages in progress can go a long way.

Photo source: Smashing Magazine

In short, make sure you divide screens that are final or approved from screens that are still in progress. And we know what you’re thinking - the word “final” has lost its meaning in design. Nothing is ever final. But what we mean is: separate the designs that have been approved from the ones that haven’t.

It’s about the small things

You don’t have to switch up your entire design framework in order to keep better track of project edits. There are a couple of small things you can do to avoid getting lost in your own design files:

Don’t make a different file for each design iteration. Keep everything under the same file, but on separate pages.
When making a new version of an existing screen, or editing a thing or two about it, don’t do it on the same one frame - make copies of said screen and don’t be shy to make as many as you need. You never know when you might want to return to the old version.
When screens have been approved, make sure to keep pages like “Archive” or “Trial and error” at the bottom of the list. This way, when your development team or your client uses the design document, they won’t accidentally go on those pages.
When making an alternate version of multiple screens, keep them on a separate page and add an emoji to the title. Our suggestion is to use number emojis - 1️⃣ for the original version and 2️⃣ for the additional one.
Use colored circle emojis (examples: 🔴 🟠 🟡 🟢 🔵) in page titles to show what state they’re in. For instance, if the screens in a given page are still in progress but close to being done, use the yellow circle emoji. Since these colors are pretty suggestive on their own, it’ll be easy for your clients as well - they (hopefully) won’t get lost in your design document.

There you have it - now you know how to keep better track of design project edits. Naming, dividing screens, instructions from you to you: they’re small things, but they go a long way. After all, making a well organized design file is not only helpful to you, but also to your clients and development team.

Best Practices for Code Review and Pull Requests. Insights from Developers

UPDIVISION — Wed, 08 Dec 2021 10:29:24 +0000

One of our clients asked how we do the code review at UPDIVISION and if we can provide some examples of best practices. This looked like an awesome opportunity to discuss with developers and collect some fresh insights.

If I had to sum up all the remarks received in only one phrase, I would say that code review is about teamwork. And it somehow defines team health as much as code health. Sometimes we forget that it involves two parties: the coder and the reviewer. So in order to make it work, we need a set of principles to guide both. Most of the teams have their unique tacit consent (gained with the previous experience) upon their standards, so this article is an effort to put them in writing.

Code reviews improve throughout a project’s sprints, as team members get to know each other. If it gives an opportunity for growing, self-improvement and solving conflicts, it’s a sign that it’s working.

But what are some examples of best practices and standards to be followed?

Let’s see what the UPDIVISION developers say:

For Coders:

“The pull request should bring all updates/improvements that were specified in the task, not partially. In case there is a blocking issue, it should be discussed at that moment.” (Ovidiu)
“Double-check and mark all subtasks within the task.” (Mada)
“In general, for a pull request, it would be great to make sure its final version is testable and stable.” (Ovidiu) Always test your code, take pride in not leaving bugs for the testers to find
“Coder must make sure there are enough explanatory comments in long functions/files.” (Marian)
"Explanatory comments are great. They’re not necessary for long functions, but for complex functions that need more clarification. I think developers must try to choose self-explanatory function names if possible, if not, write a comment!" (Ahmad)
“I always make sure to compare differences before sending a pull request, double-check if all aspects are taken into account and if there is nothing that is not needed anymore in the code.” (Ovidiu)
“When a new feature or bug fixes are ready, it would be great to make sure this is the best code version by doing some refactoring at the end.” (Ovidiu)
“The commits in the PR should describe exactly what happened (fix, feat, refactor etc).” (Ovidiu)
“Coders need to make sure they merge the develop branch before submitting the PR, so we can avoid conflicts.” (Marian)
“I think we all agree that using check boxes is useful.” (we use these when submitting pull requests too). This is nothing too fancy, but increases efficiency a lot. There can be a very simple template that works for your team and it may sound like this: 1. Tested links 2. Double checked X 3. Ran automated tests etc.
“To find the context easier, PR names should have the same name as the task names in the project management tool we use (comma separated) associated with the name and follow the agreed naming convention: CU-{task_id} followed by a short description of the PR.” (Marian)
“Coders should double-check the target branch.”
“Deprecated/Unused code must be removed.” (Marian)
“Make sure no console.logs are deployed to staging/production, unless there's a debugging session on that environment.” (Marian)
“Fixes regarding other parts of the code can go in the same PR, but this is something that should be discussed within the team.” (Ovidiu)

For Reviewers:

“From my point of view and what I have experienced: If a PR is kind of blocking and the coder's next tasks depend on it, the reviewer should try to prioritize it if possible. Maybe it is better to create a PR based on features, not based on tasks, even when it makes the PR very big. Feature-based PRs are less dependent on other tasks, so less blocking. On the other hand, they can be fully tested as a feature and understandable by the reviewer as a whole, thus saving some time.” (Ahmad)
“Reviewers should look if there are ways to simplify/improve code for easier reusability/maintenance. It may increase the time of the code review, but in the long-term, you may actually save a lot of time.” (Marian)
“If we have multiple reviewers assigned to a PR, I think that PR should be merged only once all reviewers have approved the code.” (Ahmad)
“Reviewers should keep a review diary or keep some notes for later conclusions.“
“Reviewers should make sure the naming of variables/files is intuitive and easy to read, should some new developer ever need to edit/maintain the code.” (Marian)
“When I do or I get a code review, I like to receive detailed notes/insights, not only “not ok”, “why did you do this?” without any recommendations. An ideal scenario is when the reviewer is explaining during a call or a quick chat how I can improve the logic or the code formatting. It is great, if the reviewer has enough time to spend some on identifying the weaknesses of the code.” (Ovidiu)
“Everybody learns from it, including the reviewer. Both the coder and the reviewer should show responsibility when coding/reviewing code so we can avoid mistakes or pushing undesirable code to production. When solving a task, there are more solutions and all of them are reliable. The reviewer should not push this solution subjectively, if the coder has chosen another option.” (Ovidiu)
“It's a good practice to run automated tests in front and back once developers make changes or fix bugs on features that have automatic tests implemented. And if any of the tests fail because of the changes, update them or fix related bugs if any. Briefly, PRs should not be merged when there are failing tests.” (Ahmad)

For Both:

“Both coders and reviewers should run the automated tests.”
“Both coders and reviewers should make sure they tested project links before submitting a PR.”
“If you have a PR that is for the frontend, for example, and that can't be tested functionality-wise - it shouldn’t be merged even though the error is not frontend related.” (Marian)
“On complex/large pages or functionalities, coders and reviewers should also try to optimize for performance and to minimize the UI/UX impact.” (Marian)

Questions I ask myself as a developer or reviewer, when doing code review:

Is it easy to follow a reviewer? (as developer)
Is there any additional information I can share with the developer, to help improve the process? (as reviewer)
Do I understand what the code does? (for both of us)
Does the code function as expected by the user? (for both of us)
Is this following the definition of Done? (for both of us)
Can this be simplified? (for both of us)

General mindset:

Share feedback and discuss repetitive situations.
Improve our process continuously.
Always look for ways to automate.
Help and understand each other.
It’s the team work leading to excellence and high-end products that really matter.

What NOT to do:

Never self-approve a PR. We need team power.
If there are timeline or budget constraints, don’t waste more than half an hour on solving UI/UX problems. Ask for help from designers.
This happens very rarely, but do not overtest if not needed. Leave some work to do for the tester.
Don’t forget the global context (timeline, budget constraints, end-user, final goals, business logic behind it).

[STRESS TESTING SERIES] Break it before you make it. 3 ways to test your UI design before coding it

UPDIVISION — Fri, 03 Dec 2021 11:16:17 +0000

This article is part of the “s” from UFOs, the framework component that talks about how to ask for and get useful feedback on your designs from stakeholders, including your end users.

People usually think of testing as something which happens after the app is coded. But testing your UI design before implementing it can save a lot of development time. And we're not talking just about getting the look & feel right.

In fact, it can cost you 10 times more to fix something later in development than early in the design phase. Below are the three key elements you'll want to get feedback on once you have your first design drafts. And the three key people to ask.

Stakeholders. Testing design alignment with business objectives

Stakeholder feedback interviews are often overlooked as a testing method, but they're a great way to get feedback from people who really know the business. Stakeholders are your design and development partners and reaching consensus is essential for the success of the project.

Getting feedback from your stakeholders can help answer questions such as:

How could the current design potentially impact business results?
Are there any requirements left unaddressed by the current design?
Are there any limitations or restrictions we were unaware of when designing the screens?
If it's an MVP, have we reached an agreement on the first iteration - number of features and their extent

In order to get healthy feedback from your stakeholders, make sure to:

Set the context for your designs - where are you at with the project, what features are you presenting and user types.
Clearly state the type of feedback you are looking for. This prevents stakeholders from giving you feedback which is not appropriate to the current stage the project is in, i.e. focusing on the fine touches when you are still defining core features.
Ask stakeholders questions as you are presenting and walk them through your thought-process. This will encourage them to think about the design as well.

End users. Testing design usability

Think of prototyping as usability testing before end users can actually test your app. The goal is for users to interact with the design (literally) before a single line of code is written.

Most design tools such as Sketch, Figma or Adobe XD allow you to turn static pages into interactive prototypes by specifying triggers (on click, on hover etc.) and relations between screens. This way, users can select things from dropdowns, navigate through menus, click buttons and load new screens. Because it mimics the real thing, you can get early feedback and identify any key issues in navigation and functionality before committing to the final solution.

However, running tests on interactive prototypes requires a slightly different approach than testing coded software. These are some of the things to keep in mind when testing interactive prototypes:

prototypes, no matter how high the fidelity, are never going to be as comprehensive as the coded app. That's why the presence of a moderator is crucial to answer users' questions about what you want them to do or how.
don't forget to account for relevant limitations. A “lorem ipsum” placeholder text or a rough colour scheme may make some elements less intuitive or interfere with some users' navigation abilities. Take that into consideration when evaluating the overall success of your designs.

Developers. Testing design ease of implementation

You don't have to wait for the handoff in order to show your design to developers. Developer feedback meetings can help identify those parts that are trickier to code, if there are any good alternatives and if your screens follow the required design patterns (e.g. when using a certain UI library life Vuetify).

In fact, gathering feedback from developers on your design before it gets implemented can:

uncover more straightforward solutions to technically challenging designs
give you a good sense of the timeline and development effort needed to code the designs
close any existing gaps between teams and make the handoff easier when the time comes
leverage any unexpected issues that could be more time-consuming than anticipated

Testing your designs and getting feedback early is crucial in making sure you`re building the right thing at the right time. And it can save a lot of development time and costs. Getting feedback early in the design process from key people such as stakeholders, end users and developers can drive the project forward with fewer hurdles down the line.

[Foundation Series] The anatomy of a UI Kit. What it is and how to use it in Figma

UPDIVISION — Mon, 22 Nov 2021 13:51:13 +0000

This article is part of the Foundation series of our UFOs UI/UX Framework. The framework is a tool we created based on our 10+ years of experience in building complex software and thousands of hours of design meetings and feedback. Developers, designers and entrepreneurs can use this framework to gain a better grasp of the UI/UX process and build awesome apps as a result. To learn more about the UOFs UI/UX Framework and each framework component, please go here.

This article is part of the “F” from UFOs, the framework component that talks about the backbone of UI/UX design, the elements almost every design relies on.

If you`ve heard of UI kits, you probably know they're great for speeding the design process and for helping developers implement designs easier. However, UI kits are also a great tool for understanding the UI/UX design process. By reverse-engineering UI kits created by professional designers, you can get a fairly good idea of what UI/UX is literally made of.

The anatomy of a UI Kit

At its most basic, a UI Kit is a collection of frequently used UI components and some fundamental design style guides. Good UI Kits usually follow a design system. Here are a few examples of several free to use UI Kits:

Material Kit

Now UI Kit

Soft UI Kit

In general, if you download a UI Kit, there's a big chance it will come with some of the elements listed below.

UI components

Depending on the kit, it can include anywhere from dozens to hundreds of UI components. These can vary in complexity, from the most basic building blocks such as buttons and input fields to more advanced elements like tables.UI components may come in different:

sizes: most UI Kits define standard sizes (small, normal, large) at least for basic elements such as buttons, input fields or dropdowns.
styles: again, most UI Kits come with at least two or three styles of buttons: rounded buttons, square buttons, outline buttons, buttons with icons etc.
states: this is a big time-saver since you can have various states of the same element already designed (enabled, disabled, on hover, clicked etc.)

Example pages

Even the most imaginative people would have a hard time picturing how all these UI components fit together. This is what example pages are for. Most UI Kits include example pages as a way to demonstrate what you can build with the kit and how it might look. Some of the most frequent example pages include:

Dashboards: since they are generally complex and include a lot of elements, dashboards are a good way to see what the UI Kit can do.
Tables: most admin panels include a lot of tables, so example pages usually feature a table page with CRUD operations.
Login and register pages: one of the first things users will see, so most UI Kits include these as example pages
User profile: another feature commonly found in most apps and in most example pages

Typography

UI Kits usually come with typography rules which are meant to:

define text sizes: headlines (usually h1 through h6) and body
define text styles: primary text, muted text, success text, warning text, captions etc.

Colours

UI Kits usually include a color scheme which is applied throughout and can be broken down into various categories, depending on how the kit is organized:

Primary colors (one or two) - used in pure form for primary actions, active navigation elements etc. The primary color is usually the theme colour, what you think of when you think of that UI Kit. Of course, you can have various shades for each primary color.
Background colors - usually neutral, a lot of gray tones
Accent colors - all the yellows and greens and reds for signaling various states. Can also include other colors.

Icons

Some UI Kits also include the icon packs that were used throughout the designs or a link to the icon pack plug-in. In Figma, for example, you can install the plug-in and import the icons directly.

Elevation###

Some UI Kits define elevation rules for the components. Essentially, these are shadow styles, so that, based on how big the drop shadow is, you can have elements which appear closer or further away from the background.

Grids###

Sometimes UI Kits also come with grids for various container sizes, from small to wide. Usually, these follow 12 column Bootstrap grid options.

Using a UI Kit in Figma

As comprehensive as a UI Kit can be, there's a big chance you`ll need some basic tailoring to make it your own. And to design an app that stands out. The following section deals both with how to use an UI Kit in Figma and how to customize some basic presets.

If you want to see a UI Kit at work, check out our case study on how we used the Backpack Figma Template to design the administration for a tech dictionary.

Getting started

If your UI Kit comes as a .fig file, upload it in Figma either by dragging and dropping it or by clicking the New > Import button and selecting the file.

Alternatively, you can go to the Community section in Figma and search for a UI Kit. By duplicating a file from the Community (click on Duplicate), the file becomes editable in your own Figma account and you can use it as you like.

Select the frame size you`ll be working with - Figma comes with predefined sizes for phone, tablet, desktop, which you can see on the right-hand side when you create a frame. If your UI Kit comes with predefined grids, you can activate the grid option from the Layout Grid menu.

Copying components

Copy the ready-made UI components and start using them in your design. You can do this in several ways:

select an element and use the regular CTRL-C CTRL-V commands
select an element, hold ALT and drag. This will create a copy of that element.
use the Assets menu to identify the needed component and then simply drag it in your workspace

The copies you create are children of the parent component. This means that whatever changes you do to the parent, they will also be applied to the child components. Parent components are represented through a diamond symbol, while the children are symbolized through an outline.

Overriding presets

Most of the things mentioned in the UI Kit Anatomy section, such as colors, typography, elevation and grids come as predefined styles in Figma with your UI Kit. You can see them under Text Styles, Color Styles, Effect Styles and Grid Styles. You can edit them by clicking the Edit Style button.

When you edit a style, all components which have that style applied to them will be edited.

Of course, you can also detach a component from its predefined style. This will allow you, for example, to edit the colour of that component only and maybe define a new color style based on that. To do that, select the new color and click the + button in the Color Styles widget and give the new color style a name.

In a similar manner to styles, you can detach child components from their parent components. Child components can be edited separately from their parent component, but that's available only for stylistic changes (like changing the colour). If you want to resize a child component, you need to detach it from its parent first, resize it and recreate it as a parent component itself.

To detach a child component, simply right click it and select “Detach instance”. To create a parent component, click the diamond symbol in the upper menu.

Finding things easier###

UI Kits can feel huge and overwhelming. To find things easier you can search directly in the Assets menu for the component you need. This will show you thumbnails of the existing components for that keyword.

Some UI Kits even have Variants put in place, so you can find versions of the same component easier. In Figma, Variants are used to quickly switch between different styles or states (active, inactive, pressed, on hover) of the same component. If your UI Kit comes with Variants, select a component and you will see in the right-hand panel dropdowns and toggles allowing you to change between various options for that component.

Now imagine doing all this from scratch. Sounds kind of time-consuming and a hassle to organize. That's why UI Kits are a great starting point for design and development projects. And also a great way to gain a more structured understanding of the UI/UX fundamentals.

It's no tall tale. Automate your entire setup process with this TALL Stack package

UPDIVISION — Wed, 17 Nov 2021 09:15:42 +0000

What if we told you setting up your TALL Stack development project could take less than cleaning your desk? Bet you won't procrastinate starting that project now.

Setting up your dev environment can be pretty tedious, especially if you've been doing it for a while. So, one of our developers, Andrei Decuseara, came up with a solution to automate all the setup steps for our TALL Stack (Tailwind, Alpine.js, Laravel, Livewire) development projects. Including file structure and optimizations.

We've been working with TALL Stack a lot for the past year. Based on our estimations, this package helped us save around 30 hours of setup time for each project. To put it differently, that's 30 hours spent actually doing development. Our developers and our clients were both very happy. Each for their own reasons :)

You can check out the package on Github and tell us what you think. You can even give it a star if it helped you in your own work.

Who's the package for?

Busy developers (aren't they all?!) who need to start writing code as fast as possible
Technical Team Leads who need to onboard new members on TALL Stack projects
Developers new to TALL Stack who need to set up their first project and get started with these technologies

What does the package do?

Setup and create new project
Install TALL Stack and jQuery
Create optimizations and install webmix; run all npm commands
Create optimized file structure ready to be used in a new TALL Stack app
Create Livewire example, instead of Laravel
Create new TALL Stack start page with all required resources
Use your latest Node version, changed automatically from script
Automatically create everything you need for auth (login, reset, register)
Auto-open browser on your new TALL Stack project when setup is complete

Running it on Linux is as simple as “tallstack.sh”

You can easily run it as a script on your Linux distribution. Just type in “tallstack.sh” and go grab a coffee while it's installing and configuring everything for you. The script also allows you to choose whether you want to install Backpack for Laravel, one of the most popular admin panel builders in the Laravel community. You can also choose whether you want out of the box auth.

Set your project up for success. Literally

A good setup will always reflect on the project`s overall performance. That's why it's important to get it right from the get-go. Below is the performance score of one of our projects which we set up using the TALL Stack package. We ran a Lighthouse audit on key metrics related to page load speed:

First contentful paint (FCP) - marks the time at which the first text or image is rendered
Speed index - how quickly the contents of a page are visibly populated
Largest contentful paint - the time at which the largest text or image is rendered
Time to interactive - the amount of time it takes for the page to become fully interactive
Total blocking time - sum of all time periods between FCP and Time to interactive, when task length exceeds 50ms.
Cumulative layout shift - measures the movement of visible elements within the viewport.

The project returned a perfect score.

What's next?

As we continue to use the package in our projects, new ideas keep coming up. Going further, we plan to add more granularity to what you can install through the package. We plan to make it possible to choose a template on install and select various ready-made components. We are currently working on a script for Windows, similar to the one for Linux. As for the Linux script, we are planning to get it reviewed and officially accepted into the Linux distribution as an installable package. So, stay tuned!

Check out the package on Github and let us know your thoughts. Maybe even give it a star if it helped you save some precious development time.

[Understanding Series] How to talk the walk. Understand the app you need to build through preliminary interviews

UPDIVISION — Wed, 10 Nov 2021 10:13:13 +0000

This article is part of the Understanding series of our UFOs UI/UX Framework. The framework is a tool we created based on our 10+ years of experience in building complex software and thousands of hours of design meetings and feedback. Developers, designers and entrepreneurs can use this framework to gain a better grasp of the UI/UX process and build awesome apps as a result. To learn more about the UOFs UI/UX Framework and each framework component, please go here.

This article is part of the “U” from UFOs, the framework component that strives to help you understand the business needs of your clients and an app's main stakeholders.

Imagine your team just landed a software development project for an app you know nothing about. At the moment you are reading this, there are no written specifications, no user flow diagrams and no project board with pending tasks. Soon you`ll need to start working on the first draft screens. Where do you actually start?

UI/UX design is all about problem solving. To succeed, an app needs to serve a business goal for a stakeholder, solve a problem for a user and bring something to the industry. Understanding these three aspects is the first step in understanding the app you are designing and ultimately building.

Before we can even talk about specifications, technical requirements, user journeys or personas, there is important groundwork to be done. And this consists of preliminary interviews with people directly involved in building the app and people who will be using the app. Interviews shouldn't just happen as part of prototype testing or after-launch monitoring. They should be a primary tool in product discovery and the initial stages of UI/UX design.

With this in mind, preliminary interviews are aimed at answering two questions: “Who?” and “What?”. These two questions form the basis of all future iterations and can be revisited throughout the design and development lifecycle. They are also a fast and easy way of getting to know the industry, in addition to any additional research you might conduct (e.g. reading white papers and reports on the industry, watching demos of similar apps).

WHO?

The people you interview in these initial stages will help you get an idea of the full spectrum of your stakeholders. This can also serve as a basis for future user persona profiling.

WHO are the makers? - in addition to the actual team developing the app (UI/UX designers, developers, testers), you can also have client-side makers. These are primary stakeholders, like co-founders or investors, who are directly involved in the design and development process and have the most decision-power. They are the ones who often invested money in building the app or who are the most interested in the business success of the app.

Mandatory makers to interview:

Product owners - for start-ups they might be the co-founders themselves, while for bigger companies you might have a dedicated person acting as a product owner. They're in charge of the vision and direction of the app and understand the requirements in detail.

Client-side product owners (as opposed to internal product owners) have the advantage of understanding the product AND having an already established relationship with the wider stakeholders. This allows you to also interview the CEO, CTO, board members or marketing team members who can give you a multifaceted perspective on what they want to build.

WHO are the users? - unlike makers, users have less decision-power regarding app design or features, but they're the ones most impacted by these. This sometimes leads to a contradiction, where people who won't actually be using the app build it for people who will. Needless to say, the makers' vision for the app doesn't always go with what the users actually need or want.

That's why it's important to not restrict requirements to a list of features handed down by the product owner. Preliminary interviews with users are also a big part of this understanding phase. This works best for internal apps, where the user base more or less coincides with the company's employees (you can be put in contact with them through the product owner or other stakeholders). However, even when the end user is exclusively “out there”, you can still work with the stakeholders to identify potential candidates.

At a minimum, users can be divided into admins and regular users. Further segmentations may include:

Company employees:

managers: from team leads to division managers, they can offer you the bigger picture in terms of workflows and processes.
power users: these are people with a lot of work and industry experience. They can help you identify edge cases and features they would very much like to use in their daily job, but failed to find in similar apps.
regular users: they are the people whose job the app needs to make easier. At a minimum, the app should allow regular users to perform their daily tasks.

Company clients:

end users: these are the users whose activity is supported through the app and who are served by the employees using the app.
other businesses: final recipients of B2B software partners - this includes suppliers or any third-party vendors.

WHAT?

What people want from the app very much depends on who they are. If the app was a pie, makers and users would all want a piece of it, but of various flavors. Below are some examples:

product owners - their goal is to create products that stand out. They're the ones most interested in the app's look & feel.
managers - their goal is mostly instrumental: optimize processes, reduce cost etc. They're less interested in what makes the app stand out. They use dashboards a lot and need ways to analyze data and assess performance.
power users - they want to be able to do things previous software they used didn`t allow them to. This might imply highly customized design and features.
regular users - their goal is to do less manual work. This might mean automating tasks or integrating in the app data previously tracked offline manually.
clients - need to have easy access to important information (business accounts, stats & reports) and ways to communicate easily with a support team.

To complicate things even further, one person can have multiple roles and therefore conflicting wants or needs depending on the role they put forward. In sociology this is known as “role conflict”, an example being when a parent coaches a team that includes that parent's son. The role of the parent can conflict with the role of the coach which requires a higher degree of objectivity.

Similarly, exploratory roles (like that of a product owner) might conflict with more instrumental roles (like that of a board member). A person might want to build the most advanced fleet management software on the market. All the while admitting that, as a board member, if they were responsible for the financial decision of buying such software, they would choose the cheapest or the medium-priced option.

Preparing for the interview

Whether in person or remote, preparing ahead for these preliminary interviews can save you a lot of time down the road. Below are some tips & tricks for a smoother experience on both ends.

Make sure you have a way to record the meeting - taking notes might sometimes distract you from the actual interview. Try recording the meeting instead, so you can review it later if needed.

Identify patterns early on - if you do decide to take notes, write them down as statements directly in an Excel spreadsheet (you can also include supporting quotes). You can then identify patterns by coloring in the participants who adhere to that statement. Works great especially for redesign projects, where you can easily identify recurring pain points users have with the existing app.

Source: https://www.userinterviews.com/blog/tools-for-remote-user-interviews

Ask open-ended questions - might sound trivial, but it encourages users to tell a story rather than confirm or rule out your own assumptions.

Keep the “what ifs” for the makers, not the users - ask users only factual questions. Interviews should stick to concrete examination of what users do and how they feel. They should not try to get the user to create their ideal product.

Start building a list of contacts - this is particularly useful when working on an app for a bigger company. During interviews people tend to reference other colleagues who they feel might have a better grasp on certain aspects. Write those contacts down and start building a list of team members, departments and responsibilities.

Group questions into topic categories and subcategories - you probably won't be able to think of all the questions straight away, but having some broad categories to map them to really helps. Below is a concrete example of organizing your questions.

35 example questions to kick start a productive discussion about complex software

You have been contacted by a relatively large company to design and build an app which covers the seed-to-sale life cycle of bonsai trees. This includes tending to and growing the trees, but it should also provide supporting features for the sales team, the inventory management team and the company's clients (flower shops distributing the bonsai trees, other growers) and partners (e.g. fertilizer and pesticide suppliers).

Questions for the makers:

App structure and architecture

1.) Will this be a single app or a suite of apps, given the number of features?

2.) If this is a suite of apps, how will the onboarding and sign in happen? (e.g. single sign-on through a portal allowing users to sign in with the same email address across apps)

3.) Will this app/suite be used only internally or will it be sold as a seed-to-sale software solution for other growers?

4.) If this is a SaaS, how many users do you expect to have?

5.) What is the overall entity hierarchy and what are the restrictions that come with this? For example, the company is the highest-level entity. Each company needs a bonsai grower license in order to sign up for the app. Can a company have more than one license and if so, how do they switch between licenses? How many levels down does the hierarchy go? For each company you might have several brands (luxury bonsai trees, pocket-sized bonsai trees etc.). Each brand may have their own teams with various roles within the team.

Industry and competitors

6.) Who are your biggest competitors and what is your main differentiator? A huge value proposition might be the fact that you offer an integrated suite. Alternatively, there might be multiple CRM solutions out there, but none tailored for the bonsai industry specifically.

7.) What are some industry trends which you have identified and could directly impact the design and development of the app? For example, more and more clients move towards a vendor managed inventory model. Instead of simply selling bonsai trees to flower shops, you could monitor their inventory thresholds to make sure they never run out of bonsai trees. Or you could even order bonsai trees for them and offer inventory management as a service through your app.

8.) What are the most common billing models in the industry and how do you plan to approach billing (one-time payment versus subscription, payment plan per number of API calls, per number of team members etc.)

9.) What are the main business goals you set for your app and what is the estimated time span to reach these thresholds?

Clients

10.) What type of clients do you have? For a bonsai grower, this might range from flower shops where they sell their ready-made products to other growers to whom they sell seeds and other growing materials.

11.) What is the average size of your clients` business?

12.) What type of services do you offer to your clients? For example, this might range from retail selling through an e-commerce to vendor managed inventory services.

App look & feel

13.) Could you please give us some examples of app designs you like?

14.) Do you plan on using a UI kit or an entirely custom design?

15.) Are there any industry rules regarding look & feel, color scheme etc.? For example, in the bonsai growing industry one would expect to see earth tones and a lot of green.

Questions for the users

Getting to know the user

16.) [For employees] What is your role and how long have you been with the company?

17.) [For managers] How many people do you have on your team?

18.) What apps do you use in your daily work? Which ones do you use the most?

19.) If you would describe your job with one adjective, what would it be?

Daily workflow

20.) Could you please walk me through what a typical work day looks like for you?

21.) What task takes up the most time out of your day? For example, the Growing team might spend a lot of time manually tracking bonsai trees based on their plant tag. A significant time-saver for them might be the ability to scan the tree tags and automatically get the code.

22.) What is the easiest task to accomplish? What is the hardest task to accomplish?

23.) Do you use any hardware in your daily work? (e.g. thermal printers, scanners etc.)

24.) How many other departments do you interact with on a daily basis?

25.) How is your work evaluated and what are the metrics, if any? (e.g. planted trees per hour, number of correct versus incorrect orders etc.)

‍Pain points

26.) What are the blockers you most often encounter in your daily work? For example, several members of the Fulfilment team might pull from the same bonsai inventory lot to fulfil orders. Slow loading time might lead to inaccurate inventory. When the system refreshes, the user might realize that, in fact, there is nothing left to pull from.

27.) What options do you currently have to address the blockers?

28.) What are your main issues with the software you are currently using for your work?

29.) Who are the people/departments most affected by this pain point?

30.) What has stood in the way of addressing this pain point so far?

Client-related questions

31.) Are you in direct contact with your clients? If yes, how do you keep in contact with them?

32.) What is good customer service as related to your job?

33.) What are the most frequent complaints you receive from clients?

34.) I want to do a certain action as a client (e.g. place an order). Can you walk me through the steps of accomplishing this?

35.) An issue has been raised by a client (e.g. incomplete order). Could you please walk me through the steps of raising an issue and resolving it within your department.

You can hold preliminary interviews with makers and users before you even have a design to inform any future personas, journey maps or requirements for the app you are building. These preliminary interviews will help you understand the app a lot better and the business needs it answers. It's like an onboarding process before you even start mapping an onboarding flow.