Table of contents
- Product Designers' need for dev team support
- Why the waterfall approach doesn’t work in the Product Design process?
- How to organize the work of Product Designers and the dev team?
- UX-driven development
- Case #1 - BrandSync
- Case #2 - Up Your eGame
- Why do you need more engagement of Product Designer into the project?
Hi there Reader! I’ll allow myself to assume the following: if you’ve found your way to Merixstudio’s Product Design section of the blog, you know what User Experience entails. But in case you haven’t, you can check the answers to most frequently asked questions about UX Designer’s job. What I’d like to do with this piece is lay out a few points that I think are worth discussing, or at the very least could serve as food for thought before diving into digital product design & development.
Product Designers need for dev team support
Regardless of whether you’re working with a team of your own, or partnering up with a software house to create a new digital product, what is important to note is that in both scenarios you will be tasked with much more than just developing the thing. Before you get to the stage in which all is more or less set in stone and there are just final cycles of development and testing, you’ll get to enjoy prototyping and designing your product. It’s a lengthy, work-heavy process that includes devising a UX strategy based on user and market research and is crucial to your product’s success. Usually, though, this is how it goes.
Within a limited timeframe and without the dev team to support them, a Product Designer is tasked with:
- getting to know the project,
- analyzing project scope,
- understanding product fundamentals,
- starting an ongoing discussion with the Product Owner and/or any other decision makers,
- understanding the end user,
- getting the prototype done.
That’s a lot to do. Product Designers are often given limited resources to do their job and rarely the chance to ask for technical expertise from the team that will work with the prototype. In the cases they do, the assisting development team hasn’t worked on the project nor thought through all the details of the scope. Therefore despite the opportunity, the project expertise is simply not yet there. As soon as the UX Designers complete their task, they check-out for the rest of the project, leaving the prototype without further attention or adjustments post technical feedback. You could probably see where I’m going with this.
Why the waterfall approach doesn’t work in the Product Design process?
We are slowly realizing the importance of Product Desing in digital projects. The estimated number of UX Designers on the market grew from about 1 000 in 1983 to ca. 1 000 000 in 2017. Yet there are still cases in which Product Designers responsible for putting forth the very basis of development work are given limited opportunity to get the job done properly. The popular reason is budget control and cutting cost. If it sounds counterproductive to you, it’s because, from a professional standpoint, it is. I’ll elaborate on why.
Users’ judgment about the credibility of a site is nowadays mostly based on their aesthetic quality, as found out by a study done by Farah Alsudani and Matthew Casey from the University of Surrey. According to them, credibility attributed to a particular company largely influences a user’s interest in their website. When shown a sample website, one with a graphic banner at the top, one without, but otherwise the same, 97% of users concluded that the former is the most credible-looking - simply because of the image. We would never know that if Product Designers weren’t given the time to study users’ behavioral patterns and A/B architecture structures against them. This is way beyond what basic prototyping in a digital project usually entails but is crucial to product success. Modern behavioral trends aside, every product has its target audience. Understanding that group and creating something that is suited to their needs is the goal of every UX Designer. We’re convinced it should be shared by the product owner too since a lot of it translates to how much money the product will make once live. With the limited approach to Product Design, this part is rarely explored though. Definitely a missed opportunity.
How to organize the work of Product Designers and the dev team?
Another problem with this workflow is the imminent disconnection between the Design and Development team. It is often the case that the designers start their work before the development team is composed. That forces them to consult architecture assumptions with any and all available specialists who likely won’t work with the prototype. This setting does not lend itself to a motivated, responsible consulting on the technical part. What one specialist is comfortable with proposing might not be what the actual team will be happy with implementing later on. Lastly, as mentioned before, a team that hasn’t started working on a particular scope yet offers limited expertise on possible solutions to implement. There’s another thing though, most designers were guilty of it at least once in their career
Paper loves all ideas and paper does not judge one's creativity. Neither does Axure, however, the development team and an estimate-fearing client absolutely do. Especially if what’s been put forth in the prototype performs a barbaric, sacrificial ritual on the clients budget in the name of unchecked creative liberty. Consulting any prototype’s feasibility with the actual team that will be implementing its assumptions is crucial in proposing solutions that are within reach. For a number of reasons:
- There might be a project plan the development team wants to follow in order to best handle the key aspects of the product. Key functionalities should be then given priority by both designers and developers, but they won’t if consulting the plan is not possible. What you get could be a mismatch of priority and emphasis put on the wrong interface structures.
- There might be inherent limitations to the technology that the development team intends to use. This means that certain solutions may be easier, faster (thus more cost-effective) to use and some may pose significant difficulties. It is important to prototype the product in-line with what the developers feel comfortable using.
- There might be misunderstanding around the designer’s intent and thought process that they followed creating the prototype. If the development does not tap into that exact logic, the final product might turn out to be a variation of what was accepted in the prototype and be inconsistent with the UX strategy the designer devised for the product.
Bottom line is, lack of a communications bridge between your designers and developers is plain unhealthy for your product. There are ways to remedy that in the popular, waterfall approach to Product Design, what I would like to discuss though is a different approach, one that is characterized by the development team getting UX support at a constant.
UX-driven development for the most effective process
UX-driven development is not a term that’s part of a specific methodology. Though it could be used to define an approach in which the UX Designer leads the development focus through cycles of analysis, consultation and educated prototyping for the team. The premise of this model is to have the UX Designer work at a crossroads where Project Managers, Developers, and the client meet all throughout the duration of the project. Their engagement is not limited to a discovery & prototyping period before the development team is composed and prior to any coding work.
There are aspects of product design work that should be handled early in the process which, regardless of the approach, require prototyping before code-writing can begin. Examples of those are the architecture at a high level, key flows within the platform that should be planned early for clarity of focus. It would also be ill-advised to go into development without any knowledge base whatsoever - a non-specific sketch of basic product screens can often provide enough. Those may also be revisited at a later time and tailored to its precise spec once it’s been carefully laid out.
However, instead of completing a detailed prototype, which for a lot of projects essentially means setting in stone all specs to implement, UX Designers are engaged for the full duration of the project. They work out the details of the architecture, screens and overall experience collectively with the client and the team in accordance with the current sprint focus and the strategic project plan.
This approach has been immensely helpful in some of the projects we’ve done. When gathering knowledge and insights for this article, I had a chance to discuss with two of Merixstudio’s Product Owners who have led their teams using a constant UX support model. Here’s how they made it work:
Case #1 - BrandSync
BrandSync, one of the biggest, if not the biggest project in Merixstudio (that lasted over 2 years) started out with just a couple of user stories and a Product Discovery workshop. There was little set in stone when development started. Similarly to what’s been described above, the team and the client agreed on the basics and kept the rest of the scope fluid.
How very Agile is it to just agree that the scope will clarify itself in time? Very - and that’s exactly how it went. The base architecture was taken care of at the start. During the first months of development, the team engaged in an intense, repeated process of brainstorming, research, prototyping, refining and developing.
Maciej, who took up the role of a proxy Product Owner for BrandSync during its development, has timelogs showing that during the early months the Product Designer spent up to 30 hours per week working on the scope. That time went to discussions and consulting, research and constant refinements, working almost as an all-round consultant for the team and the client. A lot of the time was invested in studying competitor’s products.
Key elements went through the thorough product design process and once confidence was reached, they were prototyped and forwarded to the team. The cycle was reiterated across sprints until the critical parts of the platform were implemented. After a few months, the UX Designer’s engagement was decreased to ad hoc consultations and support.
The benefits earned via this approach are without doubt:
- Product designer becoming a consultant for both the client and the team by having the opportunity of time and budget to thoroughly study the direct competition
- Achieving confidence on the implemented scope through closely intertwining the perspectives of technology, business, and user experience
- Reducing risk connected with long-term planning by employing a sprint-by-sprint approach and planning for the nearest future.
You could say that the biggest benefit of the ones mentioned above was ultimately the fact that we could start working on the project with barely any entry planning and come out successful - I think it speaks for itself.
What is most interesting is how similar this approach has worked in the second project I’d like to mention - despite the subject being a completely different product.
Case #2 - Up Your eGame
The goal in the Up Your eGame project was to create a social platform for a serious type of gamer. It started with a Product Discovery workshop, during which through analyzing potential direct competition we quickly realized how rich in well-financed products is the target market.
A lot of prototyping work has been done right from the start so one could say the waterfall-like element of Product Design was undeniably present. The scope was big but manageable. It targeted a specific brand of a gamer that was well invested into grinding ranking ladders to the top 1% of the most skilled players. There were certain doubts around whether the scope will be efficient in attracting enough audience to sustain itself given the end user group was not that numerous.
With that in mind, Kamil, the proxy Product Owner of the Up Your eGame platform then, decided to propose the constant UX support model. The goal was to help the client enter a demanding, rich market and launch something that will be there to stay.
One of the primary tasks of the Product Designer was to get to know the market. Quickly it became clear that although there was a variety of well funded products and ideas, a lot of them were unrefined, or lacked focus. We concentrated on being effective in testing ideas against the end user, gathering their feedback and building a feasible roadmap based on the data we got. Ultimately, this was to perform a successful launch of the platform.
The UX Designer was given their own weekly pool of hours to spend on both prototyping and analyzing the market. A cycle was worked out, in which research and analysis were base for consultation, brainstorming, refinement, and prototyping. All in all, a very Agile approach to handling improvements to the scope.
There were a lot of day to day activities to perform:
- constant UX updates based on the work cycle,
- marketing communication and copy suggestions based on user feedback,
- heatmap analysis using HotJar,
- benchmarking solutions against the competitors,
- auditing completed milestones to verify their alignment with the latest focus
- consulting for the developers in regard to implementation,
- guerilla testing with our own Merixstudio gamers as subjects
In time, the Product Designer became a consultant for both the team and the client.
With constant updates to the roadmap based on feedback gathering and working out new information, the platform changed its nature. It turned from a product dedicated to the most invested of players to a community platform for all types of gamers. Solo players to find competitive teams online, or existing amateur teams to brand themselves, set-up a schedule and organize matches against other formations. A scope that undeniably most gamers can relate to and that is inviting to an incomparably wider audience.
The biggest benefits that spun from a UX-driven approach would be:
- in-depth market analysis, testing which ideas take root and are worth implementing to attract audience;
- working with the client to use their wide knowledge of the gaming industry to scope a product that is competitive;
- making sure that only the tested and refined ideas make it to the platform to not overinvest in unrefined concepts.
The most crucial aspect of this approach: it provides the Product Designers with the time to think their work through and discuss all of what they would propose to gain necessary feedback. Constant refinements and benchmarking allow to gain confidence in implemented solutions.
Why do you need more engagement of Product Designer into the project?
Every project has its inherent requirements that force the development team to adapt. The Agile approach to Product Design benefits projects in demanding, saturated markets, as well as those with complicated roadmaps. While controlling the project’s budget is a must-have, it’s worth remembering that investing in a Product Designer’s engagement may decrease the spending in the long run. With large projects, it’s often easy to get sidetracked by functionality pieces that are not crucial to your target group, which an active Designer likely prevents. UX is also less and less an extra to a digital product and increasingly a necessity, given how rich different markets are in various platforms.
Most of all though, the team and the client are able to build a knowledge base on the users and the project, working out best practices and gravitating towards the most optimal solutions. It’s exactly what lays the foundation for a successful product launch.