And how to practice functional UI
🗓 15th October, 2019
The rise of design portfolio platforms has made it easy for designers of all sorts to showcase their work. We showcase work to build profiles, inspire communities, receive feedback and to gain recognition for our skills.
The benefits of showcasing our work are countless and clear, as a result, we may sometimes think about what we may add to our profile in order to get an edge. When these thoughts kick in, it’s tempting to assume that if our presentation is stunning, then we’d roll some eyeballs and get more of what we want; namely recognition and interest.
Some designers pursue this objective by working on daily UIs and Dribbble shots for fun where constraints don’t exist and the sky is the limit. The thinking I assume is that if the sky is the limit then the outcome may potentially be more impressive; and who wouldn’t want a portfolio of impressive pieces?
The issue with this line of thought however is that there can be no design without a customer, a problem and some constraints. Therefore engaging heavily in the visual aspect alone leads to unrealistic outcomes which also misrepresent product design as a practice. Another real issue with practicing design without customers, problems and constraints is that it will lead to bad practice which could make you a worse designer.
With this being said, I believe there are ways to practice UI deliberately and build a stunning portfolio which is both realistic and also more likely to interest people who know product well.
How to practice UI deliberately and become a better designer
Practicing UI is not a bad thing, however it’s worth remembering that UI is one part of a much larger process and by going through the full design process, you’ll reach the UI stage with more context and can make better decisions as a result.
When I practice UI, I typically mimic the full design process in a short period of time in order to get context and direction, however I’d spend the bulk of my time in the UI stage to ensure that I’m getting the practice I set out to get. After all a UI exercise is a UI exercise. This way I can make better decisions but also draw the line a lot sooner with unnecessary explorations that don’t contribute towards the main goal.
When I feel that I’ve got a promising solution to a problem, I typically prefer to stop there and set up a new UI project for myself instead of come up with another hundred iterations. This keeps me disciplined as I learn to iterate responsibly and try to get to a sensible solution in a fair amount of time. This discipline is valuable because no amount of iteration will ensure that a project will be successful so you may as well learn to get your design to be great enough then ship it to see how it performs.
To be more specific on how I quickly, and loosely mimic the full design process, here are the four stages that I cover when working on UI exercises:
- I pick a product I already use and list some of my pain points.
- I ideate for solutions that address the pain points.
- I prototype my ideas.
- I put my prototypes in people’s hands.
So without further ado, let’s take a good look at each step.
1. Pick a product you use and list some pain points
A good starting point is to pick a product you already use and think about your personal pain points with that product. Alternatively, you may think about things you wish the product offered you.
Taking this approach will help you begin with three things in mind:
- A real customer — yourself.
- Of a real product — the product you’ve chosen.
- With a real problem — the thing that frustrates you about that product.
With the list above you’re already putting yourself on the fast track as far as gaining context of the problem to be solved and who you’re designing for.
Although your pain points may not reflect those of the broader audience, starting here is still better than jumping straight to the pixels as it reinforces the process of thinking about people and problems as a first step. This is what designers do at work especially as they grow to more senior positions. By deliberately practicing this phase you’ll be further acknowledging it’s relevance and make a habit of starting at the right place.
With this context in mind, and some real pain points, you’re ready to jot down one or a few problems that you think are worth solving. To keep the exercise lean and focused I’d recommend listing very little problems around a single area of the experience. I typically aim for one to three related problems at the very most.
Now because this exercise is all about practicing UI, I don’t recommend that you spend days or weeks in choosing a product and listing problems. In fact I’d recommend that you carry out this initial step relatively quickly. If you’re familiar with the product you’ve selected, you may be able to jot some problems down in a single sitting of less than an hour.
2. Ideate solutions to the pain points
To get the most out of this part of the exercise you’re better off separating it into two parts:
Part 1 — Learn from other products
The first part is about finding products which have solved similar problems to those you’re about to solve. This will help you discover what solutions already exist but more importantly, how they compare to one another and how they actually work.
Doing this will also make you knowledgable about more products and expand your reference base. As time goes by, you’ll have a better understanding on how UI works and will be able to make better decisions sooner.
Part 2 — Iterate and iterate some more
The second part is about iterating to solve the problems you’d like to solve. It’s perfectly fine to incorporate ideas from other products you’ve tried out if you’ve found solutions that can solve the problem you’re addressing.
With this being said, always make sure to borrow for the right reasons. If you’re borrowing a solution because it addresses your problem and feels familiar and intuitive then that’s a thumbs up. If you’re borrowing a solution because of a nifty interaction then ask yourself how that helps solve the problems you’ve listed earlier.
Remember that great UI should help people abstract value from a product and has nothing to do with self indulgence or artistry.
During the iteration phase, I like to force myself through a few rounds of iteration in order to challenge myself to rapidly come up with the best solutions possible.
Here’s how I do it more or less:
- Create low fidelity flows — critique them.
- Improve low fidelity flows — cement them.
- Apply medium fidelity UI to flows — critique UI.
- Explore high fidelity UI improvements round 1 — critique UI.
- Explore high fidelity UI improvements round 2 — critique UI.
- Explore high fidelity UI improvements round 3 — draw line.
As you may have noticed, the process is about covering the broader picture first to get that cemented. After that, the rest is about multiple rounds of refinement based on feedback, each round brings the solution closer to the final product.
It’s good practice to draw the line at the right time; UI can certainly keep you busy for long and eventually provide diminishing returns compared to the number of iterations being produced.
After solving the problem and pushing yourself through a healthy number of rounds of iteration, you’re better off moving into prototyping. This is because even though you may have countless ideas on how to solve a problem, you’ll only know the value of your work after putting it in people’s hands.
3. Prototype your design
This phase is about turning your static designs into a convincing product, ready for people to use. No UI is truly complete unless it factors in all of the interactions that come along with it. As people navigate through screens, each interaction serves to communicate what’s happening and makes the experience more learnable and seamless.
Great interaction is subtle and additive to the experience, it is not about making objects move around for the sake of it.
Imagine a story with a beginning and an ending but nothing gluing the two together; that’s what UI without interaction feels like.
When working with interaction, it’s worth keeping to standard interaction models related to the UI pattern’s you’ve chosen. You may see how these interactions work by observing the products you researched. This is because people come to products with learnt expectations they’ve developed from other products; we call these expectations ‘mental models’. Deviating from these models for no valid reason may frustrate users as things will feel very unfamiliar to them.
Unless you’re working on a specific case which begs a new interaction model, playing it safe usually guarantees higher levels of understandability for users.
In some cases, you’ll notice that some designs are awkward to design great interactions around and this may force you back to wire framing. This isn’t a bad thing. With practice you’ll get used to thinking about interactions whilst putting wireframes together. This is another benefit of adding a prototyping phase to your daily UIs. You’ll start to become more mindful of the finished product and how people will navigate it.
With each new project, you’ll find that the prototyping stage will take less time to complete. This will indicate that you’re getting more and more skilled at the craft.
4. Put your prototype in peoples’ hands
By the time you reach this stage you should have a prototype which addresses some issues with a real product that you, and perhaps others have used too. Now's the moment of truth, the most exciting part. This is where you can put your prototype into the hands of people who've used the product you designed for and get their thoughts on your prototype.
Instead of going for a formal round of user testing, you may find people who are happy to try your prototype and share their thoughts with you. Remember that this exercise is about mimicking the design process merely to help practice better UI, the main focus therefore should be the UI and not design thinking in it's entirety.
Even though this doesn't mimic how user testing really happens, the idea here is to reinforce 'ending' with feedback from users as this is how things work at product companies.
In many cases after gathering feedback, you'll notice that your work has further room for improvement and you may be tempted to go back and continue working on your prototype. This is fine and if you see value in doing so then go for it! I personally prefer to gather my learnings and draw the line here to avoid turning a rapid UI exercise into a massive project.
The reason I draw the line at this point is because that allows me to begin a new project afresh and improve my entire process from start to finish. The reason for this is that each project will teach you a few lessons; by going through many projects you'll learn a variety of lessons which will make you a more rounded designer with many experiences to draw from.
Final thoughts
Practicing UI is not a bad thing at all, designing without customers, problems and constraints of any kind is what makes bad practice.
Deliberate practice is definitely a valid way to improve one’s skills and provided that there’s a good setup (even loosely), something will be gained from each exercise.
Be careful what you admire as not all inspiration is created equal and the wrong type of inspiration can quickly divert your attention to where it shouldn’t be. Whenever you feel like you may be stirring in the wrong direction, go back to people and problems and you’ll regain perspective and produce meaningful UIs.
