Offence versus Defence
How you approach design largely depends on whether the problem you are solving is a reaction to feedback you are receiving from users (defence) which usually relieves pain or an action to solve a problem the user has not yet anticipated (offence) which usually delights the user.
Defensive design should be prioritized before offensive design, but not at the cost of it. Eventually if enough time has passed, all offensive design will become defensive.
Before getting down to creating mockups, it is critical to understand the problem you are trying to solve, whose needs you are addressing and why it is important to solve the problem.
Interview all the stakeholders involved in the product to scope the potential of your design and orient yourself to their needs.
If you iterating on an existing design, determine how important it is by evaluating the value it will create, and ranking it as per the following:
1 = Very important
2 = Important
3 = Not important
Similarly, speak with the development team to determine how long it could take to implement and rank it as per the following scale:
1 = Less than 2 hours
2 = A day
3 = A week
Anything longer than a week would be considered a feature. The product of the two ranks determines the order in which it should be implemented.
In case you are implementing a completely new feature, make sure to determine which functionalities we must have versus which functionalities would be simply nice to have.
The functionalities that we must have determine what our minimum viable product (MVP) should look like. Always communicate and cross confirm this prioritisation with all the stakeholders of the design including users.
- Make sure you over communicate with each stakeholder. It makes it easier to explain design decisions later.
- Present yourself as blank. That way you ask more questions, reducing the scope of your design.
Build all your mockups and prototypes considering the following:
We stick to using Figma for creating both high-fidelity mockups as well as prototypes for visualising our interactions.
- Always consider which device your user base uses and start from there. For eg, #AndoirdFirst for Shoppers and #iOSFirst for Customers.
- Do not delete any of your mockups, even if you have a million horrible iterations.
- Cross check your designs with Figma Mirror before testing and handoff.
Create a segment of users based on engagement, sample size, demographics, device type, new or existing users. Use the testing platform, User Testing to conduct anyone of the following test types:
- Remote unmoderated usability studies
- Remote moderated usability studies
- Prototype testing
- Competitor studies
- Benchmark studies
- Longitudinal studies
- Diary studies
- Card sorting
- Tree testing
- Preference testing
- A/B and multivariate testing
- Multichannel studies
- Omnichannel studies
- Focus groups
- 1:1 user interviews
For internal testing, use Mr. Party to develop a step-by-step instructional test. This is particularly useful for the Shopper apps.
At least one designer must attend every party.
Physical User Tests
For systems that are more infrastructure based, travelling to observe its use case might be more appropriate. This is particularly useful for apps related to the Stores branch.
- Test at each stage of development
- Not every iteration needs to tested, use your judgement.
Our workflow is not linear, it is circular and cross-referencing. We must not simply ship our designs off. Instead we must collaborate at each stage of the development to check if the design is feasible and if not, make iterations. Keep shipping!
While presenting your design, keep your art boards clean and organized. Use consistent components and name layers using camelCase.
Communicate each design decision but also remember that done is often better than perfect.
- Keep a handy list of your design decisions to help you communicate them and to keep track of the design implementation.