First and foremost, I am a Software developer not a user experience designer or expert. These ideas are part of a User Experience and product development course I did earlier this year and experience from my time working as a product manager, and of course developer making products.
This article will just scratch the surface of UX, and try to focus on what aspects of the process a software developer would need and want input on.
This article will only focus on the UX process and not take into account how you as a business select features for development. You should of course not only listen to your users, but you must also do development that is aligned with your own business goals. But that is for other departments to decide on, right?
Why should I care about this?
Well, that is a good question actually. You, and me, are probably a busy developer trying to keep up the tech scene, or trying to break into it. Heck, are you into JavaScript? It is a fast-paced world, we are missing out on at least one new UI-framework as we read this!
But consider this. You are faced with the challenge to, with your awesome colleagues, develop a new app. You perfect everything, making the most awesome, good looking, most performant, best-tested app. But none of that matters if your product does not solve a user or business need. Or if your users do not understand how to use your product.
Sure, if you are part of a big company you have people that are responsible for this. They do it all, and you just implement the features. But, many of us do not have this kind of luxury, we might be taking on projects as solo developers.
If you want to build products that are good for your users, you must understand your users. And products that are good for your users will succeed. After that, we should add all the sprinkles and cherries on top to really make it stand out in the competition.
And this can be applicable to developers of all types more or less. For example, if you handle database optimizations, understanding what data is important for your users is required to optimize it correctly.
For a long time I just thought that "building products and interfaces that I like" is a good idea. But that might be a terrible idea if I am not anything like my users.
What is User Experice
User experience, or UX for short, is a wast topic. Covering methods, ideas, and models to build products or experiences that your users, or the users you want to attract, actually needs and wants to use. In a way that they actually can use it, hopefully with ease and joy. Puh... that is a bit.
What we need to know is that UX-design and UI-design are not the same. UX is not about colors, spacing, fonts, or that type of detail. UX is about the greater picture. About how your product should solve some problems for your users. And how to make sure your users can understand and interact with your product.
The basic of the UX process is a three-step method, that is repeated until you are ready for development. Yes, this should proceed the development process in the beginning. And Every iteration should refine the ideas, going from something low fi, like sketches, to something more elaborate, like a prototype.
UX is applicable to all product design processes, but as you might figure out we will think in terms of software/web development from now on. And whenever I write users you could actually change that to "the users you want".
1 - Discovery
The first part of the process is the discovery step. In this step, you research what is it your users actually need? Why do they need it? In what context are they using your application? Etc.
There is a couple of ways to figure this out, but the best ones can be summarized with: talk to your users. Interview them, but do not ask them "what do you want".
Or if you have an existing feature that will be renewed or improved, watch them use the current feature and ask them to speak out their thoughts and intents. What problem are they solving by using this feature?
How many users should you talk to? No idea, but if you talk to one single user, you will at least have one insight over zero. But if you could, talk to some and when you see the same feedback return over and over again you can stop.
Us developers might never take part in this step, but we could ask the ones doing this to try to get some valuable insights. These questions might be good to have answered when building a feature or product:
- Where will they use the product. Is it on a mobile, tablet, desktop?
We all hear mobile-first, but in my opinion, it should only ever be mobile-first if our users are mobile-first!
- Are they on the run trying to do something quickly or are they focused and have time to complete.
Should forms be simple with opting into more advanced tasks, or elaborate from the beginning?
- What are they doing before or after this task.
We could help them into this feature, or on to the next step or application if we know this.
- How experienced are your user with "tech"?
Are we making something that our user actually understands, or are we making it too simple or complex?
- But maybe most important, why do they use this? What do they as a business achieve?
At the end of this process, you should summarize and present your findings to your team. This can be done in many ways, but the most important part here is to agree on some common ground for your users, or different types of users. This should be presented to all of the persons involved in product development (sales, marketing, development, management, etc.)
You could of course do research by sending out surveys or something like that. But you will probably not get the "why" into the forms only "what". So you might find some feature is bad but not understand why, and therefore not know how to solve it.
2 - Create
In this step, I believe all departments that are responsible for the development should participate if possible. But developers should definitely be represented.
Now when we have some findings, we can map the findings to the user process. We can imagine a story for our users. First, this happens, then this and after that, we solve their problem which makes them happy by solving their business need. So basically, we have defined what problem we want to solve.
The above, and below, parts are a bit more complex in real life. You should dig into user story mapping to actually have methods on how to outline the user flow on both high level and implementation details, but I will skip that for today.
So it is sketch time. Now, what I learned and tested is something quite scary. Make really rough sketches, with NO details in the beginning. Yes sketches, no Figma or XD here.
With all the participants in the room, and a defined problem to solve, give them all pen and paper. Now draw a grid with 6 frames, like a comic strip, on the paper. Now in only 5 minutes, all should individually draw a solution to the problem in the frames.
The room could of course be virtual 😊
Why 5 minutes? Well, the important thing here is not to be stuck with details. We need to iterate fast and try out several ideas. After 5 minutes, everybody presents their ideas to the group and then its critique. Scary right? Well just give some positive feedback with some points on how you would like to improve the sketch. This process most important factor is the discussions, this will guide us to the solution.
After a round of critique, another drawing round starts. Again 5 minutes, this time you should all steal the good ideas your colleagues made and add them to your existing or new ideas. This process can be repeated a number of times.
When you are done it is time to select your top sketches that should be worked more upon. Try to select some favorites as a group or just let everyone vote for their favorites.
Then one of the participants, like a UI-designer or something, takes all the selected sketches and tries to make some refined work with them. Of course, keeping everyone in the loop.
Why? Well, first of all. Sketches are fast. And the faster you make them the easier you can throw them away (this is important). Imagine having worked on some mockups for several hours, maybe days, and you present and someone says nope. That hurts. Imagine drawing for 5 minutes and someone says nope. Not so bad.
Second, if you get the people deciding on the product drawing some sketches themselves and having discussions early on you will get approval faster in the end.
It can be quite scary to do this in a group, you must be brave and try it out and by repeating this process it will be easier.
"None of us is as smart as all of us". That is the key concept here.
3 - Validate
Now, someone has made finalized sketches and we should validate them. This is done by giving a user a specific task to solve. We should try to have some kind of prototype. Now we could do something like a Figma/Balsamic/XD thing here, but paper sketches should work fine as well.
If this is the first iteration it is fine if they are rough, this is all about validating that your design ideas work: The users you show them to understand your intended flow and are able to complete the tasks you ask them to do.
From experience, I can say you will learn a lot by sitting side by side with someone and ask them to interact with your designs. It can be really hard to not just show them or something like that.
It might be a good idea that someone else validates the designs. If the user knows that you are not the one that made the designs they might just be a bit more honest, and you will not go in some kind of defense mode.
One tip is that if a user gets frustrated and asks "how do I do????" you should just say "how would you like to do?". We are not there to learn the user, we want the design to work on its own or only with the instructions given.
What is important in validating is that you, again, ask your users what they think when you show them different sketches. What are they looking at? What are they thinking? How do they feel? Observe them and take notes about everything. For example how frustrated they are trying to solve a specific task.
But when can I start to code??
Yeah, that is what we all love (me too). Yes, write that sweet code. But that is a time consuming and expensive step in product development. This process is all about that we should know what to do before getting into that details.
Sketches and prototypes are easy to throw away, they are fast to spin up and fast to throw away. But when you start adding code time can fly and changes are more time-consuming. So just be a little patient in the beginning, and you will
Summary
Well, as I said UX is wast and complex. But this is the key process I like to adapt to my projects. And I am a firm believer in just cherry-picking things from the different process and find out what works for you and your team.
If you have any thought, please share in the comments. And if you by any chance live in Sweden, you should definitely check this course out.
Cover photo by NEW DATA SERVICES on Unspash
Oldest comments (0)