1. Who needs design? We already have technical specifications for our product.
Great! How did you end up with those? Did you collaborate with end users? Did you test the hypothesis with the target group? Did the process change and improve? If yes, you have done everything right, and we're just talking about the same things with different terms. But if not, we think the next question will open up the topic a bit more.
2. We know our customers – why do we need to interview them?
All companies we’ve worked with in my career have said the same. But still, every time we're involved with customer insight work, we have found some surprising and unpredictable things that will affect the service we are developing. Sometimes we can even find ways to change the process more efficiently and save costs.
People who are involved in the project are not often the end-users of the service – do you know what your end-users’ goals, needs, desires, tasks, thoughts, experiences or problems are?
Although you’ve done market studies, buyer personas, web analytics and what have you, they might not provide any insight into the problem at hand. Quantitative data describes user and customer behavior, but in order to understand the reasons for the behaviour you need to talk to people and gather qualitative data as well. Quantitative data can be used as part of the insight work, but decisions cannot be based on that alone.
End users are just one part of the service. How do your employees – those delivering the service – impact the customer experience? Have you interviewed them? They often have valuable insight into the fluidity of the everyday process and views on how to deal with problems. And in many cases your employees are end users too. How do you mine the data collected through your customer service channels e.g. calls and customer support requests? How to loop that back into service and product development?
To implement a service successfully, it's important to involve the service users early on: in the design and implementation phase.
3. How much should we invest in design?
Do you think your business will be relevant in the future, if the mode is “business as usual”? If you think your customers are willing to stand in line, while your competitors are developing new ways to implement the service, there is no need for big design investments. But if you think your business might need a boost from customer insight, new innovation, future oriented lens, or even better customer experience, we recommend investing in design. Often, a well-planned and excecuted design will pay off later, either through savings in the project or increased sales.
Every need is unique, but some easy and affordableways to get started with design are innovation workshops, design sprints or accessibility evaluation, to name a few.
4. Now the “design phase” is over and done with – why should the designer stay on the team during development?
For us that means we now know what we are building. Like building houses, architects will stay onboard throughout the construction contract. They are there to ensure the transition of the vision, to answer questions in problem situations and to help the team to make the right choices as things change. And more often than not, there will be things that need to be adjusted, as the project progresses.
So the project phase might be over, but digital product design or product development and delivery is never over, until the service is at the end of its life-cycle. Development and delivery change constantly, and the service needs to change in sync with the world.
Developers need designers’ support while implementing the UI. Not everything can be prescribed in advance and trying to do an all-out comprehensive documentation is often very time consuming and wasteful. The most efficient way to communicate for humans is face-to-face and sufficient time for developer-designer communication should be planned and resourced for.
Software development is an empirical process, e.g. new things are learned every time the solution interacts with the real world – users with their goals, needs and tasks should be observed in real-life context. This feedback can be taken at a face-value, which often translates to new features and scope. Developers are usually very appreciative, if there’s a designer to translate the feedback into a working solution. And it's even more ideal, if some of the feedback is collected on the team’s own terms, to give them direction towards the project’s goals. Thus, planned hypothesis validation, user interviews and observation, as well as usability testing will guide the team into the right direction much faster and more efficiently, than relying solely on the emerging customer feedback. Designers can help in facilitating this work. Designers and developers tend to look at the same project through different lenses, which will exponentially improve your chances to reach a successful user experience.
Designers are also the product owners' best friends, as they can help to gather and communicate requirements and elaborate them into actionable specs for development. The PO may not have the skills nor time to do all the work the developers expect her to do. Many times designers help the PO’s prioritizing tasks based on money, customer experience and business value.
5. We have the mantra “trust the process,” but are there situations or contexts where it does not deliver?
One can question the delivery in situations, where the original problems, assumptions or hypotheses that were communicated first, weren’t the right ones for the given situation or they were not validated, and the project and process could not challenge them for a reason or another.
Design and development is iterative work. While the project amplifies the understanding of the domain and problem at hand increases, it may turn out that validated goals have turned out to be wrong or they are not the best ones for the project. Sometimes project sidetracks might even become more profitable than the initially designed main track.
6. Is the purpose of design just to make things pretty? (Assumption: design only means the styling of things)
Quite the opposite. Design is not art. In design, form follows function. Design is always done for a certain purpose. Sure the purpose might be to impress users with superb aesthetics, but if the goal is that people get things done thanks to the system, or the system will drive behavioural changes – it needs to be useful and usable before pretty. E.g. if your order form is pretty, but has severe usability issues, it will affect your conversion rate and sales negatively. But one does not exclude the other – the form can be also usable and pretty in a way that supports its use.
The role of design has evolved over time. From aesthetics (in industrial design) to UI’s in software, to holistic User Experience in digital services to entire services, organisations, businesses and futures. In that sense, the purpose of design is to solve problems and create solutions of any scope by applying design thinking, processes and tools in a human and planet centric way.
7. How to pay back UX debt taken during the creation of an MVP/MMF? (ROI)
If possible, do not take the debt in the first place, because you have to pay it back with interest. E.g. your customer services might be doing more manual work due to lacking features or usability issues in the service, which has a cost. Or they might have to deal with more customer feedback and complaints due to issues in the customer facing UIs, returned products and reclamations.
If you need to cut scope and/or quality, make a quick and dirty pros & cons analysis, or risk assessment. What is the impact of this decision on the business and the humans affected? Make a plan how you pay back the debt and in which time frame. Documented but never to be fixed usability bugs are just waste in the issue tracker. Document the decision and do a follow up when the time comes.
8. Who (internals) should we include in the digitization project?
Firstly, we recommend watching digitization as a moving train, not like a project with a start and end. Instead digitization of services and processes or any other initiative under the scope of digitalization should be seen as product or service development instead. Hopefully during the digitization project, an agile experimentation culture will take root on within the customer organization, if this is not already the case. In addition to technology, digitalization projects are always about cultural change, and changes in operating methods and practices. Therefore, it is also important to invest in change management and adequate communication during the project.
About the roles: The most important part is to get a product or service owner who will be the main link between the customer organization and the supplier. Through her, the details of the process can be spared and relevant information will be communicated, for example to the dynamics of the workshops.
In addition to the product owner, it is a good idea to involve experts from various functions such as communications, IT, customer service and other relevant people into the core team. This ensures that the most important needs of the core business functions are taken into account, and that sufficient understanding is created. In addition, when planning a project, it is good to identify different user groups with special needs, as well as change agents that can be used to take information forward about the progress of the project.
If the project also has an impact on parties outside the organization, then it is ideal to involve them in the relevant areas as well. It may sound like a large number of different parties, but the process, facilitated by professionals, achieves an in-depth understanding of the needs at a sufficient level of action. The core team may be involved in the project for a few hours on a weekly basis, while it may be sufficient for the other groups to attend one workshop, interview or testing event.
9. Why are internal change agents so important in a digital project?
The previous question answered this topic partly. In our experience, the biggest challenges in adopting technology are not technical, but people-oriented. Changes are often seen as scary, disgusting and burdensome. If these negative feelings can be eliminated, even a little, during the project, the conditions for successful implementation will improve a tremendously.
This can be influenced by selecting change agents and involving them in the project. They act as a link between the project and the team they are part of. Of course, one should not think that all these messages are automatically only good and positive, but good results require listening and authenticity.
Change agents must be seen as the internal sales people, and recommenders for the new digital inventions, and have a role in putting it into practice. In many situations value for change is hard to see from the perspective of a single person and change always raises opposition. Change agents can affect suchissues before and during the launch in a more efficient way than the entire product team.
10. What could be the deliverables of a digitalization project
The list is endless. And at the same time there are many similarities between the various digitization projects. It always depends on the size of the company and the digital maturity of the company. Does an organization have a digital strategy and a roadmap with goals and KPIs? Or do you already have a vision and wireframes?
Here is a list of some possible deliverables of a project, depending on the scope and budget:
- Some overview of the corporate/enterprise architecture should probably precede any digitization effort, or at least putting the investment into context.
- Future scenarios
- Productization of the service
- Service / product vision & mission (strategy, goals, metrics etc.) as concept document / brief.
- Design drivers to guide the design decisions.
- Working and scalable design system
- Hypotheses and experiments to validate them.
- Current – future service blueprints, customer journeys, ecosystem maps etc. to bring clarity to chaos, and to communicate complex systems to different stakeholders.
- Customer / buyer / user / alien / robot personas for communicating needs and creating empathy.
- Documented content strategy or other agreements about the ways of working in the context of service delivery. Process maps anyone?
- Prototypes to test the problem, solution, customer/market fit, pricing model etc. and to find gaps in the capabilities of the organization aspiring to deliver the digital thing.
- Working software.
- ROI calculation
- Something unexpected and unconventional.
Did something really hit home for you? Would you like to grow your idea into a concept with us? Don’t hesitate to get in touch!
