Digital Product Design: 5 Frequent Problems You’ll Encounter

UI/UX Design

Web Development

App Development

A client workshop in the Komodo studio. People are stood talking in front of a whiteboard covered in notes
A client workshop in the Komodo studio. People are stood talking in front of a whiteboard covered in notes
A client workshop in the Komodo studio. People are stood talking in front of a whiteboard covered in notes

Everyone calls themselves “problem solvers” nowadays, but here at KOMODO, we really do dig ourselves (and our clients) out of some real holes. More often than not, we inherit existing digital products that can no longer support the client’s needs, are built without scalability in mind and are patched together by so many cooks that the broth is well and truly spoiled.

As a digital agency, we love to work on blank canvases but that’s not always the case, as companies come to us when their existing digital infrastructure isn’t delivering what they need.

Consequently, we’ve become pretty good at identifying and coping with problems in the lifecycle of developing and scaling a digital project.

Here’s some insight that might just save you from them…

1. The ever-changing brief

We’ve all been there.

The brief is established, all of the stakeholders are happy and the green light is given. But, as you go along the development journey, new issues and opportunities arise and, as a result, the brief evolves.

While it would be impossible to avoid any changes to a brief once the work starts, there is still plenty you can do to limit the impact of a changing brief.

Measure twice, cut once

Attributing time and working hours to a digital project is difficult without the right structure in place. Measurement should be a key part of the early stage, from understanding the amount of time something should realistically take through to assessing the labour and review period required to meet the deadline.

By measuring these factors as accurately as possible, we can work efficient - and limit time spent backtracking later on.

Avoid assumptions

When you’re an expert in your niche, it’s easy to fall into the habit of making assumptions about your customers. Of course, you know your audience better than anyone - but technology influences our behaviour and it’s paramount to account for these changes in the early stages of a project.

Discovery workshops are a fantastic way of gaining insight into consumer behaviour and preferences. We take an interrogative approach to user research and critically examine every assumption, even the most simple aspects of a project can be massively improved by conducting thorough discovery workshops.



2. Unrealistic expectations

In any client-supplier relationship, there are expectations to be managed. Even within the client organisation, there will be various stakeholders with different expectations. It’s unavoidable, so you should aim to tackle these expectations head-on.

It may be easier to be ‘yes men’ at the start, but those problems will always rear their ugly heads eventually - it’s better to face them from the outset than deal with them later.

Prototyping

One way of managing client expectations on a digital project is by developing a rapid prototype  - a fast-and-loose interpretation of the final product that the client can understand far better than a bunch of roadmaps.

Once a client has a tangible example of their website or app, even if it is a skin with limited functionality, they can see and feel the product and can easily identify any changes to the brief when they can still be easily implemented.

MoSCoW Prioritisation

MoSCoW prioritisation is a planning methodology that is applied to plan digital product design roadmaps. The MoSCoW method is a tool that has now been widely adopted by Agile practitioners to assign how vital each task is to deliver a successful product release.

The benefit of the MoSCoW prioritisation is it helps to contextualise the value of a task or feature. MoSCoW avoids a vague approach to prioritisation techniques such as numerical prioritisation (1-4) or low, medium and high priority rankings.



3. Unprecedented circumstances

If 2020 has taught us anything, it’s that even the most comprehensive briefs can fall to pieces when the shit hits the fan. Ah, to go back to the innocence and optimism of January 2020, before so many organisations had to halt development on key projects.

The way we see it is that there will always be blockers, you just have to prepare for the worst, even in the most unprecedented of circumstances.

You can do this by working in an agile environment, where tasks are assessed weekly and allocated in sprints depending on current requirements.

4. Inherited technical debt

This one is a biggie and affects every inherited digital product. Technical debt is not just a risk - it’s an expectation of working on any digital product that is developed by several different teams.

Technical debt is the time and skills is take to re-develop a product that was built as a limited solution. When a development team cuts corners to deliver something quickly and with a limited budget, there will always be technical debt along the road.

This is a biggie, so we’ve written a whole article on the topic of technical debt, including how to identify it and what to do to minimise it.

5. Poor communication

Another hugely common problem that so many organisations face when trying to take a digital product to market is poor communication. So often, you will find that design, development, marketing and sales teams work in silos - they don’t share news of delays or issues until it’s too late and the impact of certain decisions is often felt by so many more angles than you expect.

We know that it’s not just as simple as saying “communicate better” so we have a few tips for you to improve cross-team communication and improve efficiency as a result:

Choose a collaborative workspace and stick to it

When companies don’t establish a protocol for project management and collaborative working, you’ll find that employees take it upon themselves to organise their work as best they can.

Rolling out a tool like Asana, Trello or Notion requires mass adoption for your team to feel the full benefits. Keep everyone accountable and ensure issues are communicated as soon as possible, in one place, so the project can continue to run smoothly even when blockers do arise.

Take your head out of the sand

One of the biggest causes of poor communication is a lack of foresight.

When faced with issues such as technical hold-ups, lack of team resources or a changing brief, we find it’s easier to pull our fingers out and face the music. If we spot something now that will likely cause a car crash later on then we’ll point it out.

Stop nodding and smiling when you can ruffle some feathers and solve a problem before it transforms into an unmanageable beast.

Speak their language

Not everyone involved in your project will be digitally-minded, and as a result, you may find that some stakeholders struggle to understand the importance of certain stages of the journey and put pressure on you to skip steps and cut corners.

Perhaps one of the most debated issues in this realm is the act of testing. No one likes the testing phase (except maybe our QA team), but you simply can’t deny the benefits of a comprehensive testing strategy when building a website or app.

When a non-technical stakeholder questions the time and resource involved in testing, take the time to explain the reasoning behind the testing phase - and highlight the risks of cutting that short.

By putting this into the context of time, money and resource, you’re speaking the language of the senior management and they will gain a better insight into why you do what you do.

Got an idea? Let us know.

Discover how Komodo Digital can turn your concept into reality. Contact us today to explore the possibilities and unleash the potential of your idea.

Sign up to our newsletter

Be the first to hear about our events, industry insights and what’s going on at Komodo. We promise we’ll respect your inbox and only send you stuff we’d actually read ourselves.