Five Details for UX/UI Designer to Tackle Multidisciplines
As a designer learning to keep my feet to the ground, I consistently reflect on the way of working as UX/UI designer. I have concluded my learnings from working in multidisciplinary teams into five concrete details that every UX/UI designer could benefit from.
Working at Mirabeau, a digital business under Cognizant, one of the challenges is to work in teams with various stakeholders from one project to another. Dealing with different mindsets and the ways of working is never an easy task. Miscommunication and delay in deliverables happen a lot, which influence project efficiency and furthermore, relationship with your colleagues and clients. It is even worse in an agile framework like Scrum because there is no time for ice breaking or run-in period.
As diving deep into the process, decisions or activities especially those tiny bit details, can cause tremendous effect on the collaboration or even on a bigger picture of project management and final result.
Here are my five suggestions for those tiny big details.
1. Get rid of perfectionism, always keep in mind “what are the essential deliveries of this stage?”
I believe you are reading this article because you are a passionate designer and you expect to be better or even perfect in your deliveries!
Perfectionism makes designers feel great as well as feel bad.
In the fast track of digital product development, perfectionism may kill your productivity. Read the article by Tobias van Schneider, former art director & lead product designer at Spotify to get deeper understanding regarding this.
One of the crucial skills of an experienced designer is to prioritise tasks and to define what details to be left out at each stage of the product development process.
At Mirabeau, we defined our own approach of content-driven product development. Other than diving into wireframes, we take one step back to evaluate essential deliveries to achieve our goal at each stage. For content-driven solution, the first step is defining the right contents for responsive design. Wireframes plays a role in this, but it is not necessary to spend time on designing screen layout at an initial stage. Thus, we have developed our replacement of wireframes, content priority guide (see an example below). It focuses on contents and content attributes in initial user tests. Determined by real needs, the priority guide can be filled with content attributes or real content examples to establish empathy with users and engineers.
This is definitely not perfect. It looks more like a crappy wireframe without fully considering layout. However, it is essential to serve our needs at an early stage to concentrate on contents and to get rid of layout distractions.
Another example is when I was working on a styleguide with three other designers. The styleguide is bilingual. As a native Chinese and fluent English speaker, apart from defining components, I was in charge of reviewing typography, description and information designs. It enables me to oversee work-in-progress from others. As confessed, I still have perfectionism problem. A Chinese font is used falsely on IOS platform, a button has to be changed to align with the rest on Android platform… endless corrections. Here is how it turned out. I had to update every team member whenever I made changes, and equally hoped they would understand and keep updating their work. By the end when we finished everything in the styleguide, I was deliberately reviewing and changing most of the problems that remained not being fixed.
Details are inevitably lost in transitions. This happens in every team work. The solutions is to evaluate the most important delivery at each stage and stick to the plan. In my case, a final check and alignment with the rest of the team was the best.
2. Handing over neat design documentations saves tons of time
Commanding a designer who supposed to be creative to be structured is challenging but a must-do in digital product development.
It feels so good to just open a blank sketch file and start drawing flows, mapping contents, wireframing or exploring visual styles. I used to only care about the exports of my delivery cause that’s what client require. The drawback is obvious. I spent tons of time to locate the document. It was hard to have an overview of the working documents. Gradually the whole drive/dropbox was devoured by source documents which I had no idea how to sort out at a later stage.
The solution is quite simple. Make a plan before start.
The exports for client and documentation are equally important.
For instance, if you work in a Scrum team, a straightforward way is to construct your export and source files according to Epics. Within each Epic folder, add Sprint folders so the whole team are able to search and refer to them. Another way is naming Sketch files with Sprint and consistently updating it in each Sprint.
The same applies to designs in Sketch. With reference number or name for each screen, it helps stakeholders especially those who don’t linger around the project to point out the right screen immediately.
3. Working on styleguide/components in parallel with the design
It goes naturally to share a Zeplin link with the rest of the team. We assume they possess same knowledge about design as we do. If we create a raised button (from Material design) with label paddings of certain DPs, they should be able to conclude and evaluate the label paddings of all the other raised buttons with similar actions. Unfortunately, the truth is, most of them only care about making things work.
If we work alongside the team, we have the privilege to supervise everything that goes wrong. If we leave the team for a couple of days, or even move on to another project after delivering certain amount of design, there is a large chance the next time we see our work through a released version or a soft launch is going to be a mess.
Never make assumptions about your team. As designers we take fully charge of our deliverables and make sure they are understood across the team as we do.
We take it for granted that Sketch and Zeplin measures screen elements for us, from width to radius to color to opacity and more. However, the team is still missing a general styleguide to assist decision making and components for repeat use in implementation.
When the design of several leading screens have been largely defined, it is appropriate time to work on styleguide simultaneously. To make a rule of how colors should apply, to specify components you expect to use across screens, to state how elements are arranged from minimum width to paddings, etc.
Once a component is considered in assistant to the design, or is expected to apply repeatedly, specifying its use cases, relevant values together with the design support the whole team to gradually establish a common knowledge of the design.
4. Try to fill in realistic (not necessarily real) data
Our working title leads us to focus on UX flow, component usability and information architecture. Most of the time, we are busy with usability tests and fast iterations. We prefer not to spend time on details. If an app is about rating travel destinations, we use the same destination with ratings to represent anywhere in the app that shares the common attribute.
There are tools gradually in use to improve content details for us. One example is Craft from InVision, which automatically generates content items.
Another popular tool came to sight is Subform. It features on the reality details of prototyping, such as a dynamic collection of real data and content for airlines. This greatly enhances productivity to a certain level of details to establish empathy with the user.
Besides software assistance, I suggest manually filling in realistic data.
The data here refer to measurable values such as price, distance, hours, etc. Realistic distinguishes from Real. I am not suggesting to dig real data. Realistic means the data of content items is able to associate the user with their daily experience. When the user or team members review your mockup, they will not be confused by the fake data or make avoidable mistakes to influence the final result.
The screen designs below showcase examples of displaying flight options. One screen (126–3) presents return flights based on selected dates, while another screen (126–2d) presents single flights. For fast iterations, data are put unintentionally to present flight duration, depart/arrival time and price.
User got confused by seeing the design at first time. By using the same destinations, duration for one flight in a return trip is 6 hours 15 mins. While duration for one flight in a single trip increases to 11 hours 15 mins. User started wondering if the flight options in both screens represented return trips. Same for the price. The price for a return trip is almost equal to the price for a single trip. It was not a surprise that user started clicking on the single flight cards to see if there are any hidden return flight. Only after receiving instruction from the designer, to exclude the influence of those data, user cloud finally reach a consensus to continue upon.
5. If possible, think in the shoes of engineers
Sounds familiar? That’s when designers are told to learn coding in the “whether designers should learn code” debate. The cliché has been repeated thousand times. If you feel it’s still not convincing enough, have a look at the example below.
Again an example taken from the styleguide I worked on. Based on city names, the headline (in this example, “To Amsterdam” and “Guangzhou to Amsterdam”) in the header varies from single to double lines, which means the headline changes position within the header. To define the headline position in the header, an initial reaction is to mark out all paddings around the headline. Unfortunately, paddings depend on the length, lines and position of headlines, which varies on city names. When reviewing your design in the simulator, there is a large chance that the headlines are all different sizes because engineer only selects one set of paddings from your styleguide and assign it to all situations. If the engineer is smart enough to categorise all different headlines, it still takes them tremendous amount of time.
As shown in the image above, there are two ways to define the headline position. A left margin of 16dp is applied to the whole screen. Under the app bar, we define the box of header with a height of 184dp. The solution on left defines the top padding of the headline, which results in a fixed position of first line. In case there are more than two lines, the headline carries on to the second line. The solution on right defines the bottom padding of the headline, which results in a fixed position of bottom line. In case there are more than two lines, the headline carries upwards to make sure the last line drops on the same bottom line.
Based upon this knowledge, it’s meaningless to mark out all paddings of the headline. We chosen to go with the left solution. Only relevant paddings are provided for development. Engineer types down the padding we provide, the result in the simulator works as we expect this time. One of the examples of how basic knowledge of code accelerates product development.
To claim designers standing in the shoes of engineers doesn’t necessarily mean hand coding ourselves. By grasping the basics of CSS box model is more than enough to set out the baseline.
The five suggestions consist of concrete examples and personal experience. I hope they can provide guidance for designers especially those just entered the battlefield. You’re welcome to share your thoughts and insights with me. Please click the ❤️ if you like the post. :)
