Companies have different approaches to design. It is fundamental that both engineers and designers understand that we are designing for the users.
1. ENGINEER-CENTreD DESIGN
An Engineer centred design approach usually lead to very complex solution that developers love. Products became extremely powerful with a lot of features and a lot of ways to do the same/similar things. Products became full of buttons and functionalities. User is given many options and broad customisation settings.
The design implemented is usually the design that is easier to achieve with the technology that has been used.
DESIGN FOR ENGINEERS
If your final users are developers, this approach may not be a an issue. In many of other cases, this approach leads to applications that provide bad experiences for not tech savvy users.
WHAT DO ENGINEERS THINK ABOUT USER INTERFACE?
It depends from their role, their sensitivity to design and ofter their experience. What I wish they would think is below.
"As far as the customer is concerned, the interface is the product."
- Jeff Ruskin
We all agree that the product must work. We should also agree on the fact that the majority of users thinks that the UI is the product and they don't want to know what is under water. Complexity has to be hidden to reveal what makes value for users.
2. DESIGNER-CENTRED DESIGN
WITHOUT UNDERSTANDING OF USERS
A design-centred design that is not backed up by an understanding of users, leads to the "Make it pretty culture" or as I use to call it "Lipstick on pigs". You can take any interface and make it look more attractive. We all agree on the power of seductive design but if the seductive design is covering up a poor usability experience, users will get sick of it quite quickly.
WITHOUT UNDERSTANDING OF TECH CONSTRAINS
When designers are given briefs for complex projects, if they design without being aware of technical constrains, what they will end up with won't be fully implemented. This will cause some small or even big changes on the fly that may negatively impact the overall design.
DESIGN FOR (VISUAL) DESIGNERS
Those designs look awesome. It may be love at first sight ... the question is will it last? Those designs may decrease usability and be incomplete for implementation.
3. DESIGN FOR USERS
User centered design, user experience, are buzz words. From the moment you decide to design for users you need to put yourself in the condition of understanding your users through qualitative and quantitive analysis.
TEAM & TOOLS
THE DESIGN TEAM
Everyone has his own area of expertise but enough knowledge about the other areas creates an overlapping area incredibly useful for collaboration.
The Design team was composed by a
- user researcher - conducts research about user needs and behaviours
- visual designer - design the visual layer of an application product
- information architect/interaction designer - design how a user moves through a complex information system
- engineer/ ux prototyper - brings design to life by building functional prototypes and provides technical expertise to the team
- content strategist - thinks strategically about the role of content across the entire product
- data analyst - provide metrics and quantitive data to inform, drive and measure design choices.
- I consider a few member of the support team as honorary member because they actively provide information about customers behaviours and common problems
THE GROWTH TEAM
The Design team was part of a bigger team: the Growth team.
- Jira - organisation and management Agile
- Confluence - documentation
- Slack - communication
- Google drive - sharing + assets
- Adobe Creative Cloud - hi fi mockups and icons
- InVision - sharing - free version
- UX pin - low fi
- Omnigraffle - information architecture, flows
Qualitative & Quantitative analysis
- Usertesting.com - usability testing
- Optimal Workshop - treejack, optimalsort, chalkmark - free version
- Test-flight - sharing iOS prototypes
- Hotjar - playback and heatmaps
- Optimizely - A/B testing
- Campain Monitor - email optimisation
- Google analytics
- Intercom - communicate through targeted, behavior-driven email and in-app messages.
- Amplitude - event tracking
- App flyer - mobile tracking, installation and conversion tracking
- Asknicely - net promoter score
The design team is also part of a bigger team, the growth team. In order to provide world class experience and to grow users and revenues we select priorities from two different pools: the ux pool and the growth pool.
All about helping users derive value from the product
- identify the happy moments and the aha moments in order to lead new users to them quickly.
- reduce friction
- hide complexity
- increase motivation
Build product features that accelerate the key drivers of growth
- identify opportunity for growth
- new features
The design team at SafetyCulture worked with 2 weeks sprint in a SCRUM/Agile environment. Before every sprint there is a planning where the priority are chosen within the UX backlog in Jira. Generally we focus on one or two big projects per sprint, plus several quick wins. We manage to go from idea generation to full prototype in 10 days and we communicate research and results to the all company to build empathy towards the users and collect useful feedback.
Every big project gets kicked off with a collaborative design meeting. Before the meeting, I took the time to conduct some researches in order to put together all the information the team needs in order to make informed choices: reels of usability testing, metrics, quotes, previous designs, support tickets and everything that can help us to paint the right picture.
2. COLLABORATIVE DESIGN MEETING
The meeting usually lasts one hour and the goal is to end up with a paper prototype that will be the starting point for the iterations during the sprint. All the members of the design team (user researcher, designers and UX engineers) participate and we invite also members of the marketing team, support team and the data analyst. In order to facilitate the meeting I spend some time collecting all the informations every participant needs in order to understand the problem and I explain the brief.
Since I have introduced those meetings, the benefits have been clear for everyone: what is designed can be implemented the way it has been designed and the results includes support, marketing and developers insights. After the kick off, the iterations are shared via email or slack with the participant to collect feedback.
UX Room requirement
- walls to hang stuff
- a screen to help pitching ideas
- goPro set up
- a big transparent box to store stationary
- Fome-Cor boards
- access to printers - being able to print big sometimes
- post -it in many different colors
- butcher paper
- markers (black, green, red)
- highlighters (different colours)
- sticky dots
- big plastic box where to store all these goodies
- paper folders to archive the material at the end of a project
PRINTABLE ASSETS FOR WORKSHOPS
- Experience Map
- iPad frame
- iPad keyboards
- iPhone 6 frame
- Metrics Heart Framework
- Brainstorming rules
- Gamification principles
3. design and prototypes
After the collaborative design meeting the team build mockups, interactive prototypes or coded prototypes. Generally, for big project we built coded prototype. People outside the team are asked for feedback. Usually from the initial prototype the design goes through a couple of iterations before it is ready for usability testing.
4. USABILITY TESTING
The prototype get tested from segmented users. We use usertesting.com as platform and we conduct the majority of our usability testing from remote. The number of the testers vary based on the project but it is usually from 3 to 6. We make sure, before we test a new iteration of a big project that we have videos of users interacting with the old versions. Usability testing is an incredible tool to reveal design improvement or if the new design is causing troubles.
Usually a beta release of the prototype is shared within the company in order to facilitate feedback.
Based on the result of the usability testing the next step can be a further iteration or the finalisation of the documentation for the developers.
5. DESIGN SPEC
We manage our documentation in Confluence. We create accurate documentation that is used to create the Jira issue for development.
Thank you for reading