When I start a new design (a full project or a feature) I turn off my computer.
I make sure to delay the launch of a design software as much as I can. I need to make sure that I get the big picture of what I am working on. To not be distracted with the details and lose my mind on visual aspects while the major concept has not been defined yet.
"When I start a new design (a full project or a feature) I turn off my computer."
In my very early days as a designer, I used to rush to Photoshop, work that gradient. Usually leading to beautiful screens with huge mistakes.
The problem here, is that if you work with non-designers, the beautiful screens will work for them. You will be able to deliver something âWowâ to your client, while weâd prefer to create something âOf courseâ.
As I grow as a designer, I am learning new plays that I add to my process. The following are my favourite.
1 . Why Why Why Why Why
(Or the 5Â Whys)
One of the principles of our Design guidelines at Atlassian is to always understand the deep root of what we are designing.
"Building a valuable project nowadays is considered as solving a problem for humans."
Building a valuable project nowadays is considered as solving a problem for humans. Given the amount of details to solve in a project, it is easy to miss the big picture at some point.
Remembering to ask âwhyâ is to be sure that we donât lose track of what we are doing and for whom.
Doing it five times in a row allows to find the hidden answer, the real problem. To discover the causes that bring the original problem and what we need to focus on in order to solve it.
Nevertheless, this technique has often been discussed. It is pretty common to see two (or more) persons start with the same problem and end up with a totally different cause to it.
Personally, I donât feel this as a weakness rather an opportunity to discover different causes to a problem. The ones I would not have thought of otherwise. It could actually lead to tackling the original problem on a completely new and innovative angle.
"Given the amount of details to solve in a project, it is easy to miss the big picture at some point."
Example
Problem: User does not allow notification.
- Why? They press «donât allow»
- Why? The user does not want to receive notifications
- Why? They did not see the value of it
- Why? They have not experienced a good one yet
- Why? It is the user's first launch of the app
This is a pretty easy one, I agree, but moving from that, a lot of solution can be imagined:
- Wait for second launch to ask for notification permission
- Explain the value of your notifications during onboarding
- Explain the value on your landing page
- Etc.
Pro tip
This technique can be used to solve your daily life problems as well.
2. The timeline
(Before During After)
The first thing I had learned when I started studying UX design, is:
An experience goes beyond the screen. It is not only what the user does with your product, but also what happens before and after it.
Since then, I have always applied this concept of timeline in my projects. The aim behind it is to design a full experience from start to finish.
To think the Before & After part is to make sure your user experience is complete.
An experience goes beyond the screen.
Here are some of the questions I ask myself:
Before
- How will the user access my app?
An appStore, a website, an ad, a QR code somewhereâŠÂ ? - Do they already have an account? Do they need one to perform every action?
- In which context will they launch my app? Are we talking cosy couch browsing or crowded underground subway ride?
- Then what is the user's stress-level?
- Does the user have a lot of time?
- How fast is the user's connection?
After
- How to follow-up on the experience the user just had?
- Does the user need any kind of information easily accessible from anywhere?
- How to reassure them if they're now waiting for something from the product?
- If my product is cross device, how to operate the transition from one to another?
- How to find out what happened a month ago?
Each one of this question will assure that we are not forgetting any opportunity to delight the user*.
It is not only what the user does with your product, but also what happens before and after it.
*Disclaimer
Delighting the user is not having every piece of an interface animated, popping around with spring easing or easter egg. It is the little big details that make your life a lil easier such as a good follow-up email, an offline mode, pre-filled forms, an error message, etc.
Pro tip
To better visualise the experience, you can draw it on an actual timeline, a BluePrint, or do the next play!
3. The Comic Strip
As designers, we use images to deliver an idea, that is why sketching the experience is very useful to me to better visualise all the steps the users are going through.
To perform that, a designer once advised me to divide an A4 paper into six squares, then draw each action like a comic strip.
To me, it is a way of dissecting the user life, visualising his flow and understanding his habits. Out of my comic strip, I then identify the pain points the user is going through and figure out the best way technology can enter his life to simplify it.
"I donât sketch this out of my imagination, but from user interview results."
Also, whenever I have the possibility, I donât sketch this out of my imagination, but from user interview results.
Once I have figured how the product would work, I start again and draw the experience one more time to be sure my service is covering every aspects.
When I think I have come to a good experience (and if the project allow it) I try to actually live the comic strip. This is in fact pretty useful to check if your interactions are working according to a certain context.
Bonus point: no need for a product to be fully built. A very very low-cost prototype is more than enough to perform this play.
"When I think I have come to a good experience I try to actually live the comic strip."
It often helped me realised that some simple interactions turned out not to be so easy after all:
- in the streets, during winter, wearing gloves.
- in a grocery store with a bag in one hand
- in a sunny place, that dark UI was in fact not a great idea.
Pro tip
Divide a page once into six sections with the marker, then photo-copy it for future use.
4. The conversation
Conversational UI is all over the place these days. Even though I believe that this UI concept does not suit every product, there is surely something very interesting in it.
Indeed, the Designer goal is to transform technology into something which feels natural. So it, makes sense to use a natural interaction like talking through a chat to trigger an action. SMS is one of the oldest feature of our mobile phone after all.
"The Designer goal is to transform technology into something which feels natural."
When I design a complex piece of an interface, I start to imagine that the machine is somebody that I hired to do one job.
Somebody I can talk to.
I think of the questions I would need to ask the user to get some information, the orders I would give to get something done, the answers I would like to receive.
And I write the whole conversation out, following an order that makes more sense.
This helps me to identify and organise the best flow.
Find out how much information we need on a page.
Which information needs to be grouped together and why they belong together.
What will be the actions available and how to define the main one.
But also which information the machine would need, to answer my needs.
Pro tip
I donât recommend to do this play out loud in a quiet open space.
5. The list
When I receive a new brief, there is usually a ton of things going through my head at the same time. Inspiration, visual, interaction, good UX principles, copywriting, competitors, etc. I know that I should not be focusing on the little details right now, but I also donât want to forget something in the process. To be sure that I wonât lose those ideas, I start writing everything on sticky notes.
"To be sure that I wonât lose those ideas, I start writing everything on sticky notes."
I write what pops up into my head about this specific project, but also every other things which could (in some way) relate to it.
For example, when starting on a mobile project, I will write down every components of a smartphone:
- geolocation
- push notification
- gyroscope
- cameras
- Touch ID
- etc.
I do it also for UI concepts:
- Tinder cards
- chat UI
- Snapchat ghost
- Yo
- etc.
Or context:
- At home
- while jogging
- at the gym
- in a car
- in a bus
- etc.
Then I categorise those words.
Doing this list enable me two things:
- Getting everything out of my head, while knowing where to find it again. (Starting a project can be overwhelming and an overloading mind make you lose track.)
- Make sure that I am not missing a key point or a good opportunity somewhere.
Anecdote time
I met the startup Birdly last year.
At this time, the team was building a mobile app to remove the friction of expensing your work receipts.
At this time, they were working on their UX, sustaining 2 applications (Android + iOS), launching a startup, with a team of 3 people (including only one developer).
No need to mention that they probably encountered many pain points.
Then, the team did a very interesting technical pivot. Instead of continuing with their mobile app, they decided to just focus on building a Slack bot. This decision brings a lot of benefits such as taking advantage of a new platform, easier integration to usersâ life, probably less technical work to get to the same/better result as what they tried to do with 2 apps, and many more.
Listing all the things that directly/indirectly relates to a project and having it in front of your eyes, is a good way to take advantage of new opportunities and be innovative.
"Starting a project can be overwhelming and an overloading mind make you lose track."
Pro tip
Even though I like to manipulate sticky notes, you can use mind-mapping softwares to do the job and regularly feed your list with your last findings for the next project.
Thanks for reading!
Like those plays, hate those plays, want to share yours, want to react?
Please get in touch or send me a tweet!
References:
Atlassian Design Guidelines
Birdly story
This post was originally published on Benjamin's Medium profile.
