So you are a UX Designer and you are working on a really good digital product. You are used to run some regular user interviews, interpret your web analytics and BOOM! you know who your users are, their needs and their behaviours.

Easy, right!? But, what if your product is just an idea?
Or your company found a new business opportunity for a totally different target?

Luckily you have a list of requirements but no clue who’s going touse your new product.

Based on the briefing and on the product requirements you have tons of information to start looking for your new users without even having put a pixel on that empty artboard. Here is quick checklist on how to find your future users:

1. Assumptions!

First things first: assumptions! Nothing new on this point, even more so if you are already familiar with Jake Knapp’s Design Sprint process.

Make a list of everything your team thought about the new product. Most importantly how they suppose users will behave. I said *Everything*. What your team thought is going to be true and what your team thought is wrong. For both lists, add some why’s.

Gentle Reminder: You are not your user ;)

2. Competition

Who are your competitors? Who are their users? What channels are they using? Which tasks are they solving well? What comments can you find on social media, app stores, forums about their product? Are they missing any tasks?

See how generous your competitors are?!

3. Real World Analogies

Oh, the new product will be virtual terrain to plant carrots and lettuces?! Great! What about visiting a vegetable garden?! Take some days to observe what time people water vegetables, how they water plants, how they organize the terrain. Bring them some lemonade and ask them how is a day in their lives. It’s not the digital experience but at least your team can anticipate some similar needs and task flows.

4. Cross Innovation

What is cross-innovation?! Cross-innovation is when you find other products or services in a completely different industry presenting a solution for an analogous behaviour. Do you remember that baggage carousel in the airport? A traveller waiting for their bags once realised that same contraption could have served them some sushi on the way? That’s cross-innovation. In that case, you can learn a few useful ideas from people waiting for their luggage. See?! Users everywhere!

So, stop finding excuses to say “oh, we don’t even have an MVP how are we going to find our users?!”, get your ass moving and start looking for your future user concerns and needs.

Move!

Ah! Don’t forget to revisit your assumptions a few months after the first release and along with your team, check out what has come true and what has turned out to be completely contrary to your expectations. You’ll be surprised.

UX Research with no users was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Along these years as a trainer, I noticed that doing a styleguide is one of my students’ biggest concerns. You are laughing, right? Don’t do that!

Their doubts are quite legit. Most of them went from the university straight into a startup. Odds are there won’t be any designer peers and they’ll probably be working with a young team of developers who never worked with a designer before. Furthermore, the developers have a hard time explaining exactly what they need to do the frontend implementation and, in some cases, project managers don’t understand the design process.

There is no recipe, no magic formula for doing the best styleguide, but there are some good practices that will help you survive in the midst of the IT jungle.

Why are you doing a styleguide?

Basic. I know. Silly question, isn’t it? Ask yourself! Come on, be honest. Why? You should know the exact purpose of a styleguide. You can do a web search for styleguides and you will find hundreds of results, but most of these are not styleguides but UI Kits instead. If you doubt me, try to use them. Good luck! The styleguide must be a cookbook more than a showcase of UI pieces.

You should do a styleguide to:

a) create consistency in your product

All the UI elements of your product should be represented in every single state. So, if you need to design a button for a dialog window, you don’t need to think about the style of the buttons again, all the instructions to create buttons in your product are right here.

b) give yourself some freedom

Prove the value of the styleguide to your team. If they only need a button, they don’t have to give you a task, then wait for your layout, and 10 years later they will have everything they need to create a button. They can perfectly use the styleguide to see how to do a button. The styleguide should be easily accessible to your team. The new frontend intern doesn’t need to ask how to do something every single time.

You should start the styleguide, but your frontend developers should build it with you.

You can define all the visual aesthetics of your UI elements and they should add the CSS classes, HTML, animations, … It should be a team effort.

Who will read your styleguide?

Everybody in your team. Designers, frontend devs, project managers, marketeers… So you should use language anyone can understand.

What should be in the styleguide?

Is it made of pixels? Put it in your styleguide!

You can consider two levels of details. In the first level, you will look at your layout and break it in single atoms (check this out: http://bradfrost.com/blog/post/atomic-web-design/).

Include: buttons (normal, active, hover..), Forms (normal, focus, error messages…), Labels, Texts, Icons, Images, Links and all the UI elements…

In the second level, you can consider the necessary information for your frontend dev to build the element. Add corner radius, padding, margins, sizes for boxes, transparencies….

If you win the lottery today and you don’t show up at the office tomorrow, they should have the necessary information to build the layout.

Write

Yes, write! I know you are a designer. I know how much you like to represent things using graphics, but sometimes it’s easier to write, explaining the behaviour, animation, etc. of some element in your layout using words.

It’s hard, but do the f***ing styleguide

My students and a couple of friends working in some Portuguese IT companies made me realize that unfortunately the styleguide keeps being thrown to the background. “You do it when you have spare time, now you need to design another feature.”.

Do yourself a favor and include the styleguide in your time estimates, specially if you work with an agile methodology. Slowly but surely you will come to gather the results of this investment.

Feel free to use the comments to leave your questions!

Working for the internet is an adventure. When I went to the university (11 years ago), I could only visit WAP websites on my cell phone. Nowadays, in my smartphone I can explore AR.

The technology has changed drastically in so few years, lots of job titles have come and gone. And now, with the increased use of smartphones and tablets, many companies are solving problems with digital products.

As a chair is meant for sitting, or a spoon is meant for eating, the focus of a digital product is solving a problem. Not communicate an idea, a mission, a value, services or projects. There are plenty of buzzwords and job titles all around, making the distinction between a Web Designer (WD) and a Digital Product Designer (DPD) a tougher job for the ones trying to figure out the differences.

1. The Environment

Usually a WD works in an communication agency. A DPD works in a software house/startup. The WD’s agency is a creative environment and the second thrives amidst an IT business with lots of acronymous and hard words (agile, lean, kanban, smoke tests…) and is probably surrounded by people that don’t know design terminology or the design process. Most of the time, as digital product designer you work alone in the creative field and you have the extra challenge to bring the rest of the team to your reality and mindset.

2. The mindset

Talking about mindset, there are some disruptive differences between the two realities. While a WD is designing a web site for a company, his focus is communication. On the other hand, as a DPD you are focused on designing the best interface for your user to complete a task. It’s a never ending process, because you can always improve the product, add features, remove unnecessary features… Your team is focused on technical issues, not on the best way to convey the message.

3.Workflow

In both environments you have a common workflow. You need to discover who are your users, analyze the competitors, define the user flow, make some sketches and wireframes, design mockups, build prototypes, test with users, write the style guide… but when the product goes live, for a web site you will be analyzing if it has visitors, if they fill the contact form…

When a digital product goes live you will be analyzing which features are being used, if the user completes the tasks..

4.The audience

As a WD you are making user resource to discover who your site will be talking to. A DPD is discovering for whom he is solving problems. In both situations you could be worried with a big range of people, ages, professions… But with a site, you will be talking with the same person only a few times. With a product you want your user to use your product over and over and over again. Tone is important, but engaging your user, is the main goal when you are designing a product

5.Definition of Done

Well for perfectionists, a design project is never finished.

But the stage of done has different meanings between Web Design and Digital Product Design.

For a WD project, most of the time, the moment when the website goes live, it’s done.

In a DPD context, going live could just be a testing moment, part of the MVP process. Your product fits the product definition, but there is still a lot of features that will help your user with his task. Now you have to measure how your MVP product is being used, make adjustments to improve it and add features. It’s a never ending process. Your job will be finished the day you haven’t got any more users.

Two years ago, a good friend of mine, who is an exceptional UX Designer was starting working as a trainer. In the school where she was lecturing (www.edit.com.pt), there were some available positions, as she invited me to apply for the interview for Visual Design class.

Total Panic!

I cannot imagine myself speaking in front of a group of people. I conducted some workshops in the past, for small groups of people in a design atelier, not in a school. I started telling myself that if I did it successfully before I didn’t have reasons to be afraid and it would be a great opportunity to face my fear of speaking in public.

The interview went great and in March of 2015 I started working as trainer.

As a Visual Design trainer in a Ux-Ui Design course, I talk about typography for digital, icons, digital color, image and video usage, semiotics… in a second moment we (I have two more colleagues) guide students designing a responsive website (usually e-commerce)

So, now, 2 years and a couple of months later, I can realize I learned some important things for my life:

1. Be myself

As a student, we saw everything in a teacher. It‘s not different here. Our trainees see everything, they realize when I know the subjects and when I have few knowledge. And, of course, they know all my shoes, clothes and rings on my fingers. It’s important to feel comfortable with my knowledge. I don’t need to be Tobias Van Schneider to be a trainer.

2. Show my references

Prove students that you are not talking about subjects because you dream of it.

In all my classes I bring 2–3 important books with me that I read about the subject (when there are more then 3 i take a picture of them). At dinner time (in the middle of the class), I let them explore my books. I always give urls I visited as well. It’s an academic detail, but usually it increases students’s interest in the subject a lot.

3. I don’t know everything

And it’s ok! I am not google and I was always honest about that. There’s no shame in admitting it. When they ask a question and I am not sure about the answer, I usually return the question to the class. If someone knows the answer, it’s a big opportunity for me to learn (but always check the answer ;) Otherwise, I take note of the question and give them the answer in the following class or via slack.

4. (What I know) vs (What they need to know) vs (What I teach)

It’s the biggest challenge.

When I receive the course guidelines I realise there are lots of things I could talk about of each item.

The temptation of preparing a keynote with 1000 slides is huge.

Most of the time, they are not worried if you are an encyclopedia. What they need is the fundamentals, the precise knowledge to start working. If they are interested, they will ask for a deeper approach. They don’t expect me to know a lot but to give them what they need to get the job done (and of course, they love the tips that speed up their process)

5. Give feedback not opinion

What is your opinion? Relax, I will not explore the philosophical side of the question, but when you mentor the development of a project you make this question for yourself.

It is not important if you like it or not, if it’s your style or not, but if it solves the problem correctly. If it is consistent, follows usability guidelines and visual trends than it fits my digital taste. Sometimes students get mad with me about this. But they need to realize that, in the real world, most of the time they will not be able to choose the projects they are working on, and they will be designing digital solutions for clients or subjects they don’t identify with. But, as designers, they need to give their best to create the greatest solution. So, I am always aware in not giving my opinion, because opinions don’t solve problems.

There is a incredible book called “Discussing Design” — that talks about giving feedback of a design work — check it here (nobody is paying me to advertise) — http://shop.oreilly.com/product/0636920033561.do

6. Team work

My training sessions are not exclusively mine. I have two more colleagues with me on this course (ux and ui specialists), and I need to conduct my sessions always having in mind that, I didn’t lecture before and the following session won’t probably be with me (the sequence of our sessions respect the design process of a digital solution). Like in a design team, as a trainer, communication is the key and I need to follow their topics. Otherwise, I get lost and I can’t give my students the proper mentoring because I will be talking about subjects my colleagues mentioned before.

7. I grow faster

Lots of things changed in my routine. I try to have a big attention to main sites of the speciality, new software in use. I need to be where my students are. They use the same internet as me (I hope you are laughing, but for some people, sometimes this idea isn’t obvious), and I need to know what they are talking about. I started using new softwares (otherwise I would still be using photoshop instead of sketchapp).

All of this is important for a designer but it gains a new dimension when you are a trainer. I could not procrastinate to read it later or my students would be laughing at me.

Simultaneously, I started training in a Design Thinking course. I learned a few more things about being a trainer. But, for now, I will leave it to another article

“There are two things you’ll lose in live if you don’t share them: love and knowledge” Mário Sérgio Cortella

What matters, in most cases is not the time we spend thinking on a solution, it’s how we think about the problem

This article is a summary of 4 sessions I ran some days ago, using the Google Design Sprint methodology on msg life Iberia, a IT company focused on insurance software with a lean development approach.

As a Design Thinking trainer, I was invited to run some sessions, using problem solving methodologies on an environment focused on agile and really lean solutions and I realized that was the right moment to put in practice all I read about Google Design methodology. This was the first time that the company would use this type of approach to find innovative solutions for their problems

What is Google Design Sprint?

For those who are reading about Google Design Sprint for the first time, it is a methodology divided in 5 work days to solve and prototype a solution for a problem.

• Monday: agree with a long term goal; map the experience; define a target
• Tuesday: remix and improve ideas; sketch them
• Wednesday: make a solution storyboard
• Thursday: make a prototype
• Friday: test on the field

My challenge

Instead of the five days suggested, it was given 2 hours, for 4 days!!!

Set up the stage

Before these sessions, you need to ensure that the team has enough information about what these type of sessions are. It’s also important to be sure that they know exactly what the focused pain point is — the point that is a problem, the true challenge!

The team was composed by 7 people:

• 2 Deciders: they supervised the results of the sessions but were only present in the setup and presentation meeting
• 3 Engineers: the company has 3 coding dojos. One person from each dojo was invited to the team
• 1 Expert: the person who better knows the core problem; this guy was also part of one of the coding dojos
• Me: as a facilitator

We talked with the people in person, to explain what would be happening; Following this, some emails were sent to the team, explaining the process, giving examples,… Everyone should be at the same page the moment this process starts.

You need to do some previous research to understand the type of problem your team will be working on and choose the appropriate tools to use during the process and define a duration for the use of each tool. Otherwise, it would be impossible to keep the schedule.

The Meeting Room

The sessions wouldn’t be long, but it’s important that everybody is comfortable and focus. The available room for these sessions was small even for a group of 5 people. This fact wasn’t an excuse not to focus on details. We prepared some posters indicating that no cell phones would be allowed. Fresh water was available for everyone. As suggested in the Design Sprint book, it’s definitely a good idea to have some snacks to pick for longer meetings.

Before the team arrives, it’s important that all the logistics are prepared. We used:

• One white board
• Sheets of paper (A4 and A3)
• Lots of post-its with different colours and sizes
• Board markers: black, red, blue and green.

Day 01 — Defining the problem

During the first two hours the team dissected the problem. It took some time to put everybody in the mood and start working. But after a quick conversation and with the help of the Expert on the problem everybody started to be involved. They began to map the players and the actions that take part of the process. A very quick and summarized journey map of the problem. It was really helpful to understand the pain points and their dependencies.

The main goal of the solution was clear at this moment and it was written at the top of board. During the following sessions this goal was always visible to help keep the focus.

After this, the team wrote a group of assumptions that should be true to validate the solution.

To clarify the problem, the team made a diagram, at the center they wrote the core problem and, like a molecule, they filled in the satellite problems that cannot be ignored.

Day 02 — Defining the problem/Diverging

Lots of questions, they made lots of questions to each other during the problem definition. So, to keep these questions in mind, and trying to evaluate which would conduct to the solution, the team made a How Might We… session. During 20min, they wrote all of their questions.

They could understand that they had different points of view over the same question, and they started discussing the meaning of each question.

It was necessary to choose a group of realistic questions to answer.

They use a election to chose the questions. Each team member could vote twice. The expert could vote four times. At the end, the group had three main questions two answer.

Day 03 — Evaluating ideas

In the previous session, the team had defined the main questions to answer in this process. Now, it was time to think about solutions. Our problem was too technical to apply crazy 8 technique. Together we found out the best approach would be brain-writing.

During two periods of 20 min they write all their ideas.

In the first 20min, silently, they wrote down their ideas, not minding on what others were writing. Over this time, they stopped writing ideas and started explaining some of them to each other for 15 minutes. The new ideas started to come out automatically.

For 20min more, this time talking to each other, they had more ideas.

They discussed their ideas and organized them into clusters. They started to evalute the ideas according to the assumptions they had defined on the first session. Some of these ideas were put apart because they found out they weren’t realistic or couldn’t be answered properly.

Day 04 — Roadmapping the solutions

The team had identified 4 clusters of solutions in the previous session. They realised that the number of clusters corresponded to the satellite problems they had defined at the beginning. So, they found out that the best solution roadmap for this problem, should be divided in 4 scenarios.

They divided each scenario in 2 areas:

• main goals: what will be solved in this scenario
• actions: necessary steps, hierarchies, people, duration for the scenario

At the ending of this session, the team was enthusiastic, confident, happy and proud of their work (and they had reasons for it).

Conclusions

Google Design Sprint is a really powerful methodology to solve any kind of problem and it fits perfectly in a IT environment

• The preparatory work with the team is mandatory, specially for people who are doing these kind of sessions for the first time
• Google Design Sprint suggests specific activities for each session and it helps a lot to focus, organizing the agenda and giving the team a vision of what’s gonna happen
• It should be a very specific and clear problem, otherwise the team will lose plenty of time defining the problem
• Have everything prepared before starting the sessions: the schedule, the room, the materials; the checklists you find at the of the book are extraordinarily helpful
• Always use the same room — and leave the posters, post-its, everything there: the team feels that is their work room
• The team needs to feel that what they are doing is their work. You, as facilitator, are only there to give them tools
• Guide and don’t manipulate the results only to get things done
• Focus and always have a timer, it’s easy to start talking and lose the main goal
• At the end, talk to the team and show them how everybody can be creative and come up with great solutions

Everybody has a creative mind, most of the time they just need the right stimuli and the right tools to discover that