UX Design with Remote Team — 10 Lessons learned from an Agile Product Development Case
This article is based on a startup project of building a remote collaboration tool, which background information can be found in this article ;) .
As the old saying goes, “Rome wasn’t built in a day”. There are also some cases that we didn’t foresee fully at the beginning during the design process. But eventually, We’ve learned something and here I want to share with you the lessons I learned during our design and collaboration process :)
Lesson 1: Text Proposal First
When initiating a design proposal for comprehensive functions, better to clarify it in Text base and get confirmed by PM before working on actual design.
This saves us time because typing in words to explain the idea costs less than working on actual designs. Moreover, there may be back and forth discussion between designers and PM/Stakeholders. Always keep them involved at the beginning till the full proposal is confirmed. (•‿•)
Lesson 2: Don’t Panic, Think Twice
Sometimes, product managers or stakeholders will come up with some feature requests that seem quite easy to implement. However, as a qualified UX designers, we cannot just blindly follow the request and start working on the design.
No matter how small the feature or scale is, we need to always think about the 3W first:
- Where is this request coming from? Is this from customer feedback? Or from frustrations in real use case? Or just the sparkle idea pop up from someone’s head?
- Why we need to implement this feature? First, would this feature help to solve a validated problem? If the problem is validated, are there any simpler solutions to resolve it?
- What priority level does the request belong to?
Assumed that this is the feature which would help to solve a validated problem, we need to then think about the 2H :
- How can this feature be achieved in the most simple way without many interaction steps?
- How can we reuse the current patterns as much as possible to achieve this?
Sometimes, your teammate or project manager will push you to follow the decision quickly 🤯. Nevertheless, try not to get panic and lose your mind, ask yourself and your team those questions.
Maybe during the process, the one who initiated the request will find out actually there’s no need to bring up this feature. Clarify the direction and any confusion at the beginning is the core to avoiding any mess at the end. ◔.̮◔✧
Lesson 3: Always Document the Original Feature Request
Depending on your team’s communication habits, we may have various ways to receive requirements.
In our team, we use Slack and Microsoft Teams to post and receive requests. In my design board, I labelled each request below the corresponding feature, just next to its UX flow.
Always include background, purpose and core requirements to help us refer to and also communicate to other designers.
If possible, also include the date and original discussion link as well so that we can have some source to reference on later if some arguments happen.
Lesson 4: Use a Different Page for Each Feature
At the beginning, I just jammed all the feature blocks inside one page 😨. I didn’t foresee that as the product features increased and become more complicated, the entire page will become a chaos:
Even I labelled them by functions at the beginning, but too many features mixing together still makes it hard to load every time when opening the page and hard to locate specific feature UX flows. ( •︠ˍ•︡ )
Therefore, later I decided to move each function inside one single page (surely, this is not perfect structure, we may need to modify and update as the project goes along):
This way, inside each page, we will have enough room to place sub-features’ UX flows :
ि०॰०ॢी
Lesson 5: Create Component Based on Feature Block On The Go.
Since we cannot foresee the entire design system at the very beginning, we can create the most commonly used components for each feature. This will save time for creating the UX flow. Additionally, we can be more efficient by updating all screens at once with relevant components when it needs any modifications.
Sometimes, by clearly labeling different states for each component, we can communicate more efficiently with developers and also shorten design time without the necessity to reproduce all the screens for each UX flow.
Lesson 6: Name the Frame Properly
We’ve seen probably a lot of times some designs structure looks like this:
To be honest, we all want to save time to focus on the design visual instead of naming the content structure. But when it comes to building comprehensive features.
But there are some merits we may forget:
1: Proper naming helps us to easily understand the functional structure,
2: If we want to modify the structure later, proper naming helps to communicate with other designers regarding how the auto layout works.
Also, after we built up the structure for some feature block, it’s easy for us to figure out if we need to create the components for reuse purpose later.
Lesson 7: Save Some Space for Error Status
At normal status, it seems no problem when we narrow down the spacing between Input Fields.
But there are cases when users input the wrong data, then we need to have the input highlight and error alerts. If we don’t leave the space at the beginning for the error cases, then the real implementation will look like this:
Even though it’s possible to push the below field further when there is error warning text from the above field, this will cause visual instability when many elements are moving on the screen.
The better solution is that we leave enough space for those error-status at the beginning of design.
Lesson 8: Fully Examine All The Possible Use Cases Before Handing Over To Developers
Complete the ideal normal UX flows doesn’t fulfil the comprehensive user experience. We always need to keep in mind that there are edge cases like :
☑️ Empty State
☑️ Loading State
☑️ Lost Connection State
☑️ Error State/Corruption
☑️ Too long Text
☑️ Too much content
☑️ Responsiveness Layout
☑️ Special Conditions
…
Try to examine if your design has considered those cases, and even better to think through those special cases before we even start working on the wireframe.
Lesson 9: Always Save A Copy of Your Work
This rule is obvious. Always has the back-up version of our work for us to reference on later. Not only for preventing server down/ power lose cases, but also, you may never know that some of the idea we created before would be the enlightenment for our future work. |•’-’•) ✧
Lesson 10: Keep Reflecting
Small or big, each project delivers values as long as we can learn something from it. Never take it for granted for every step we do during the project. Record what we have learned and prevent similar stupid things from happening again next time is always a wise move. (◍•ᴗ•◍)
Thank you for reading 🍻
