6 steps to build great user experience with a small team
Written by Powerplay’s user experience team: Yash Khandelwal, Iesh Dixit and Tanmay Joshi
A compilation of personal experiences from continuous weekly product iterations and sprints at Powerplay that helped define our path to create better user experiences.
Powerplay is a Software-As-A-Service platform for stakeholders to manage construction projects. We design & develop software that makes the construction process faster and within budget.
We are bringing design thinking in an industry which is not at all relatable by software creators.
We are luckily in a sweet spot to learn this craft because-
- In B2B SaaS, a customer expects a decent minimum product experiences which enables them to trust the company. Therefore, we had to focus on good UI/UX since initial days.
- Being a startup, we have a small team and we keep a high development speed so that we fail fast, learn and fix things quickly burning less money as a result.
So, Let’s get to it.
👷 1. Be User-Focused, Live the user!
Be a part of your user’s life and you will already be much better than most of the products out there.
It’s tough to design for an unknown user. Do whatever you can to learn about them- spend time with them in their office, have tea with them, and just listen. Empathise!
Our team goes to construction sites and management offices or connects on video calls with stakeholders everyday. We learn something new about our users’ motivations and expectations every time!
For example, doing this helped us understand the gamut of applications they use - TikTok, Facebook, Youtube, WhatsApp, and MS Excel. This helped us understand familiar UI for them and that became our benchmark.
💁 2. Make user interviews and demos a source of truth
Interviews & demos are the gateway to enhance user experience.
We never ship the product in one go.
- We take minimum viable pieces of it and take evaluative user feedback on mockups and initially developed versions.
- These daily user interviews and feature demos surface the unaddressed pain points and steer us in the right direction. In product meetings, the recordings of the interviews and demos become the source of truth for decisions.
- During the interviews or demos:
A. We look for hard facts rather than user’s opinions. For example, instead of asking “What do you think about this?”, we ask “When was the last time you faced the problem that this product can solve?”
B. We draft parameters to understand their mental model. For example, we keenly observe their navigation patterns on the screen which gives us an idea about how good or flawed the experience is. We have parameters like — how the time devoted to a particular feature is inversely proportional to the feature’s affordance and understanding.
Insights collected from product demos help us identify the possible user scenarios where the product is supposed to fail. For design, these insights become a gateway to enhance the user experience while for the developers it becomes a coding endeavour.
There are times where besides all of this, we’re stuck! None of us is able to take a call on what to do? How should we do it? At such moments we always let the user decide.
👨💻 3. Design for every stakeholder
Software developers are the ones who ultimately ship.
It is the designer’s duty to improve collaboration by designing not only for the users but also for the developers, who ship the end product.
Therefore, to have a smooth transition from designed mockups to the final product, we learned the craft of atomic design.
We created a library of all components and style guidelines based on company core and brand values. This increased the product development speed as most components were re-used and developers can just access the master components and replicate. Even the new recruits need not stress in understanding what design goes where.
For example, designing tables is an easy task, but designing tables that can accommodate 10 types of data along with 5 extra columns at any point in the future becomes a challenge for the product team.
💻 4. Don’t just design screen mockups!
Design a working prototype so that the user can interact!
We create interactive prototypes for easy understanding of flows and extreme case scenarios.
A. Interactive prototypes get user’s questions like, “How should I do this?”, “How do I go there?”, etc. This gives us direction for our brainstorming sessions.
For example, while designing Gantt Charts users asked, “How can I go to the next month?” or when clicking on a link, “Where will I go from here?”. In such cases, interactive prototypes play a crucial role as in them the transitional experiences from one screen to another are visible clearly.
B. Interactive prototypes also check responsiveness. We generally design screens on high-resolution laptops like MacBook or XPS. We cannot expect the user to have the same hardware.
Responsive design not only accommodates a design in different screen widths but also identifies the right type of color scheme and content hierarchy. The scroll patterns you use in a MacBook is not the same on a low-end budget windows laptop. For example, a horizontal scroll on MacBook is done through two-fingers but you cannot scroll horizontally on windows using a mouse. Similar challenges occur with the color you see on the retina display and other displays.
We designed our components library that consists of different sizes of every component that would fit on the screen occupying the right amount of space. We chose interactions that favour the tech environment to which our users are habitual.
📌 5. Brainstorm for better User Experience
One rule while designing a product — Spec it down
Everyone knows that one should involve all stakeholders in the brainstorming sessions of a product, but very few know how? From our experiences, we learned it is essential that we should define a limitation on what we are going to discuss. For this, we divided our brainstorming sessions into 2 stages:
- Jamming —
1. We mention the problem statement and then ask everyone to bring all ideas for a possible solution.
2. Rank the ideas on easiness to build and value provided to users.
3. Using above ranking, we conclude on what we prioritize on what’s next.
This usually happens on Google Jamboard.
- Product Meetups —
1. The solutions from the above sessions are converted into clickable mockups, which by now are iterated through a series of user interviews.
2. We discuss the final designs’ implementation in development. All discussions like “how are we going to do it?”, “are we missing anything?”, “where will it add value to the user?”, etc are closed here.
3. Alongside this, we freeze the Product Specifications. Product specs are like subtitles given to the mockups. It carries information about the goals, data models, various states of an element, like click, hovers, scrolls, required, possible user interactions, and reasons why we chose such a type of design style.
Possibly the best part of the whole process is the product Meetups. So far now, product Meetups have been the best way to fill in the design-development communication gaps.
👀 6. Everbody tests
When the development sprint finishes, every member of the team sits and patiently tests the developed version to look for any design bug or a broken flow. Increasing the testing eyes helps designers understand the interaction problems faced by users.
Making the testing process more and more effective has been our primary goal. To do that, we generally divide the testing process into two stages.
- Stage 1 — Here, we test if there’s any functional problem like a broken link, a missing page or not being responsive. Just making it functional.
- Stage 2 — We then take a step forward and start digging into minor design issues. Removing these make it a delight to use our product. These issues are like button interactions, placeholders, font sizing issues, empty states of different components, etc.
We are always happy to discuss and debate the best techniques for fast-paced design and development. Drop-in a comment! 😉
Also, Powerplay is hiring interns for various profiles.
Be a part of the mission of bringing the speed of software development in infrastructure development.
