The basic one that most of us do is to have a notebook where we take note of what we have to do but I found this quite generic and tried more sophisticated things.

One of those things was Getting Things Done (GTD) by David Allen. I bought the book and used the method for a while but realised that in my case it was becoming too intrusive and in certain situations was slowing me down instead of making me faster. Don't get me wrong, I think this is a great tool but I am a big advocate for simplicity and balance and I felt I needed something a bit more lightweight. So I decided to design my own process which has ended up being something like this:

I simply use a notebook and follow a basic structure. I like the A5 Moleskine as is the size that seems to work better for me. The way it works it's basically every morning before opening my work laptop, I spend a few minutes (5 max) to note down the key things that I need to achieve that day and I identify which one is the highest priority. I have found 3 or 4 to be ideal as having many will possibly distract me. If I really need to get more done, I pick the top ones for the morning and reevaluate in the afternoon. As I'm working throughout the day, I strikethrough the ones that I have completed.

But obviously shit happens and if during the day something urgent that really needs to be done comes up, I just reevaluate my list at that point and identify where it sits in my priority for the day.

For me the key is something that I took from the GTD method: you should never leave lots of things in your head or they will end up using your mental energy and will start making you less productive. So every time there's anything important I think I will need to remember in the future, I jot it down in my notebook and evaluate it the next day.

A key aspect of this which seems trivial but makes a difference is that forcing you to pick just a few things helps you prioritise and give you a good feeling of accomplishment as is quite likely to achieve them.

Very recently I heard of the Ivy Lee method which is surprisingly similar, even though in that case the list of priorities is made at the end of each day.

In my case I find better doing this in the morning because that is the time when I can think more clearly and am full of energy.

I was quite pleased to see that may people use it too and it really seems to work well due to the low effort required to implement it.

Do you follow any method to keep you organised? Please feel free to share!

The post Simple process for getting things done appeared first on Jose Viso.

In my current role there already was a fair amount of remote work as the rest of our design team is in Oslo so I have been getting used progressively to it in the last year without even realising.

And since a couple of months ago we all have been forced to work from home so this has been a perfect opportunity for the company to streamline our processes and be efficient working from home.

I have found this change quite interesting and would like to share how I have adjusted, which things have worked well and which ones I'm still trying to improve:

For me the key thing has been to maintain a routine. This helps me to have a structure throughout the day and to be mentally sharp. So now a normal working day for me goes more or less like this:

• 6.30 am - Wake up: Now that I don't have to worry about the commute, I take it a bit easier and lay in bed for a few minutes without having to rush.

• 7 am - Breakfast: Since I am working from home I tend to prepare more elaborate things to eat. It depends on the day though.

• 7.30 am - Get ready: I have a shower and get dressed with something I normally wouldn't use to sit around at home. This switches me into "work mode".

• 8 am - Start work: The big kitchen table is my ideal desk at home as there is plenty of room and a nice view of the garden and the sky so I don't feel like I'm all day isolated in a small room.

• 9:45-10:15 am - Standups time: I normally go to a different room for my 2 standups of the day.

• 10:30 am - Daily cup of coffee and main work of the day. I normally go to a separate room where I have a whiteboard and music and where I can go into some deep focus.

• 12 pm - Lunch: I try to have a hard stop every day for lunch at this time to make sure I don't get distracted and end up eating late.

• 1 pm - Back to work. Normally I have a couple of regular meetings each afternoon so try to get some things done in between.

• 5 pm - Finish work for the day: I try to stop working whenever possible at the same time and go for a walk to clear my mind and stop thinking about work.

During the day, I try to share information asynchronously and progress so we are all on the same page.

One of the tools I have started really liking during this full remote working time is Invision Freehand for brainstorming. It helps a lot having discussions about design work.

I have found this routine to work really well for me and I think overall I'm being more productive than when I was working at the office. It looks like we are going to be working from home for a good while so it will be interesting to see if my routine and productivity will evolve or stay the same.

Stay safe!

The post How I work from home appeared first on Jose Viso.

The title of this article might be a bit misleading as I wasn't technically the only UX designer in the company, but our Aberdeen division is a "mini company" itself specialised in Asset Integrity Management software. As you can imagine this presents most of the challenges of introducing UX in a company.

I joined a team that had been evolving a piece of software for the last 30 years and they had never worked with a UX designer before. Design wasn't in any important discussion until that point and nobody had heard of things such user testing, prototyping, user research, Sketch, Figma or similar.

This situation represented an interesting anomaly (no pun intended working on such industry) for a Scandinavian company where design has a big site in the table.

This has been a really interesting time, full of challenges but extremely rewarding. I wanted to take this opportunity to highlight some of the key things I have learned:

Pick your battles

It's important to identify high value low hanging fruit or things that can easily be done and will create a lot of value for the final users or will solve some of the important issues identified.

For example, in our case one of the most cumbersome and painful parts of our software was the way in which the users would filter information. This presented many issues but the main one was that there wasn't a good visibility of what filters had been selected.

Some minor tweaks to this area made a massive impact for final users, avoiding them having to click multiple times to see what was actually selected.

Bring value

One of the first things I started doing early on was to prototype things to help the team understand and visualise requirements. Until that point I really had wanted to start using Figma but never had a chance and I realised that was the the perfect moment and it became my main tool.

Reading and hearing so much in the community about Figma I had really high expectations but after start using it full time it absolutely met them going even beyond. Everyone started really liking working with this tool as they felt it provides an excellent way of sharing and communicating designs. And personally, I found it extremely appropriate for quickly mocking-up, sharing and validating ideas.

Later on as we established a common Design Team I had to move to Sketch but I still think Figma is an ideal tool for a solo designer as it simplifies a lot your workflow.

Be pragmatic

When you are part of a design team and there are plenty of designers you have the luxury of addressing most of the things you want to address but when it's just you for many developers you have to be smart about where to put your efforts and when to let go certain things.

In my case this has been one of the hardest things to do as it's not nice not addressing something you know that can easily be improved, but you have to focus on the high value issues. In any case, it's important to create a "design backlog" where to register and track all these things that can be improved later on. What I do is having this always at sight and try to bring the relevant identified issues whenever the development team works in a part of the product and there is a higher chance that the issue will get addressed.

Identify UX advocates

When you are the only designer in the office you need allies and something that I have realised is that there are always plenty of people who care about the user even if they don't have the word "UX" as part of their job title.

For this my advice would be to have a session about design thinking. During the first few weeks in my new job that is what I did and I was pleasantly surprised to have people reaching me offering to help and wanting me to collaborate with them. That is one of the most rewarding things and that definitely will keep your motivation up.

There are Misconceptions about UX

One of the most difficult and sometimes frustrating things about being a solo designer is that there are lots of misconceptions about what you actually do. That's another reason to have the session from the previous point.

You will surely find people (probably the ones who have been there for longer) who will think that you only make things look pretty or work after the development work has been done.

I think it's our job as designers to realise that that is not their fault and is our job change that vision and start "educating" the rest of the company in the design process.

Integration within the development team

Introducing new tools and skills in the team doesn't normally present a massive challenge but changing processes can be really difficult and painful when the way of working has been established for years.

In our case it has been an intense journey to get to a point where I am working at least a sprint ahead of the development teams and I work together with the different stakeholders to have a validated design before it gets into the development stage.

At the beginning I was always getting included in projects to "put lipstick on a pig" after the development had already been done, which limited tremendously the impact that any UX work could have in the final product.

The key here was to use any opportunity to get involved earlier to prove that such change would have a positive impact in the result. So I took each of those opportunities as my particular Champions League final to make this happen and I think I can now say that we have gotten to a point where this is happening most of the time.

Conclusion

Being the only UX designer in an organisation that hasn't worked with one before it's really challenging but rewarding at the same time. It's a long process that will put your true love for this field and that will make you grow enormously as a practicioner.

And remember, every time you feel frustrated or demotivated do the simple exercise of comparing how the product you are working on was before and after you joined :). I take this as a marathon instead of a 100 metres sprint. There might be days that it looks like there is no progress made but looking at the big picture, you will definitely see the impact of your work.

The post Introducing UX in a company appeared first on Jose Viso.

I think working on our own bubble for longer than we should have is one of the rookie mistakes we all have made (or at least one that I definitely have).

It's very tempting just keep polishing "just a bit more" your work before you show it to anyone, especially if that person is a senior stakeholder. But in my experience I have realised that we are our own worse critics and very often these very experienced product managers or SMEs don't really care that much about being pixel perfect and are really good at seeing the high level picture. Things like if there is any important functionality missing, or if the assumptions that you are making about the content are not realistic. Or maybe you have totally missed the point and the direction that you are taking would be a waste of time.

These type of conversations help tremendously to identify if the work that you are doing is actually going to solve the real problem or at least their understanding of what that problem is. And even more important, they help you save a ton of time as give you confidence that you are approaching the problem in the right way.

An important aspect for this to work is to frame the work that you are going to show before the person actually sees it. For example, if what you are showing is just modelling a user flow or a layout but doesn't consider copy or colour yet, you should make that clear before you show it or otherwise you might get feedback just focused on visual design. The other part of the coin here is that you should explicitly say what type of feedback that you are actually looking for.

I must admit this was something I struggled quite a bit at first until I realised of how important it's this initial framing. After I started applying this approach, the quality of the feedback I started to get was so much more useful!

The post The importance of early feedback appeared first on Jose Viso.