Start with a Company Persona
To guide you through your design process you should get a vivid impression of whom you are designing for. That is why we build personas for our services. I don’t want to go deeper into why persona’s are crafted, as that is well documented.
For B2B Services modeling a company persona first helps you create more vivid, realistic and on-point people personas afterwards. To do so, we define a likely early-adopter organization and then research facts, pictures and stories about our likely future customers.
Depending on the service you are designing, find out about the company size, employee structure and age and staff size. For one company we even printed a fitting balance sheet and PL statement we found on the internet. Come up with some charts if you like. Find some pics from likely office interior and the company building. Print out a map of where the company is located. What does it’s website look like and what are they offering. Is there a regular schedule your company is running by, like a team lunch or all-hands meeting? Make everything nice and visual.
Try to imagine the situation of your company persona: Is it a fast-growing startup? Or is it a family owned production company struggling with digitization? Companies have feelings, too, you know. And each one has different needs, gains and pains just like people personas.
Lastly, try to create a story around your target company and write it down. Let me tell you the story of the fictional SAAS as a Service GmbH pictured above, that we used in one recent project at Service Innovation Labs:
SAAS as a Service GmbH is 6 years old and two years into Product-Market Fit. Now it’s transitioning into a growth phase. The company is about to open a second office and struggles to keep up the startup culture and speed. The growing employee base requires the formalization of processes. And communication between teams is becoming harder, while it’s still essential for success. The growing demands for an organizational redesign has resulted in a range of senior hirings and investor’s need for returns-on-investment puts additional pressure on the company culture, a lot of early day employees are very worried about.
With a solid company persona you are ready to derive your people personas as a foundation for your service design.
Create Vivid People Personas for Your User-Types
In B2C Service Design you are commonly dealing with one user, who is simultaneously your customer. In the case of a B2B Service, you will however create not one but several personas.
As for Company Personas we do not use a fixed template to craft our People Personas. Rather it is dependent on your project, which characteristics you want to highlight. There are however certain elements that are reoccurring frequently. Nail your Persona’s demographics, enrich it with a picture, figure out the Jobs-to-be-Done, pain and love points, wants and needs, the persona’s background and relationship with the company and the other personas. A neat framework of persona elements can be found in Ben Ralph’s article “A Guide to Personas”.
As you already know what company your People Personas are working at, you should be able to make a fairly good estimate about a lot of these elements. If you are aiming to serve startups, you will probably deal with a younger crowd, the founder may also be the CEO and the decider on top of that, the user may be a UX designer and so forth.
Again, try to come up with a persona story and write it down to make it even more vivid.
So, consider again our Company Persona SAAS as a Service GmbH.
It’s easy to imagine the founder and CEO Jennifer as a decider. She is now very busy, rushing back and forth between the old and the new office. All the while she manages her companies re-structuring process, which she finds less and less time for. Her investors are starting to push harder for operational profitability. So she decided on poaching high-level talent from other startups to ease the burden. At the same time, Jennifer feels she is losing touch with her employees, as more and more meetings and formal communication leave no room for heart-to-heart’s with her dear employees.
One of those employees is Mats, who is our end-user. Coming from product design, Mats was given the opportunity to reinvent his career as a UX designer by Jennifer, who hired him. However, now he hasn’t seen Jennifer around the office for a while. The fast growth of the company has had him taking on more and more responsibility for newly hires, leaving him in a senior position after only one year. Recently though, he is worried about the senior hirings and he is wondering if his career can keep up with the pace. In fact, he had first thoughts about whether or not SAASAAS is still the best employer for him.
Jonas is the newly-hired system administrator of SAASAAS. He comes with 12 years of experience to the company and set out on a mission to set up the company with the latest technology and integrated systems. He is in awe about the condition and fragmentation of the IT-systems and he likes to joke about “startup-mistakes” and tech debt at lunchtime. Mats and Jonas get into arguments sometimes, when Jonas decides to replace old and battle tested software-tools without asking the UX designers.
Putting It All Together in a Persona Network
You now have a vivid image of your target company and the relevant user-types that will make or break the success of your future service. One last step remains, however. As established previously, your people personas are closely interrelated. Together with your company persona they form a Persona Network.
You can use the Persona Network as a framework to keep track of the relationships between the user types and how they influence each other in adopting your service. Similarly, you can highlight the relationships of your People Personas with the Company Persona.
This way you end up with a comprehensive picture of who you are designing for. With this in mind, you are well-equipped for prototyping.
Find the Right Way to Prototype for Your Persona
Your Persona Network will give you a great framework to come up with striking service ideas, that get your user-type’s jobs done. Now it’s time to test, if your design assumptions were right.
When it comes to early validation of your service idea, you have to find the right way to test with your different user groups. As each of them has different jobs, gains and pains to cater up to, it is hard — or even ill-advised — to craft all these different elements into one single prototype.
Instead, you should find the right prototypes for your respective end-users. Key here is to figure out prototypes that best transmit the value proposition you have in mind.
But which user-type should you build you prototype for first? The answer to that question is pretty much dependent on the service you are designing. But in order to not remain too vague, our approach is to prototype for the most critical user group first. Since you are depending on all user groups to make your service work, we try to identify the group with the highest uncertainty. That’s often enough well established by your gut-feeling.
The prototype formats you put into use should relate closely to the jobs-to-be-done of your user-types:
End-users need to evaluate, whether or not your service is going to help them in their everyday life with their routine workflows. So you need to touch their pain points and show them, how you are planning to relieve them from those. Since your end-users have more touch points with your service than deciders or administrators, you have to make the experience tangible. Visualization is key here. Your end-users probably want to see screens, processes or screen flows. Fun mediums to play with are videos — explaining how your service going to solve problems like the infamous Dropbox and Mailbox examples — paper prototypes or click dummies.
Don’t fall in the trap of eagerly designing a shiny click dummy version of your darling service for the end user too early, though. Click dummies are just so much fun to make, that many designers want to sink their teeth into them right away. However, more often than not you have other critical assumptions to test first, before you direct your attention to the screen flow of your final product. While click dummies are a great way to test the workings of your solution, you should first fully understand and validate the value you are creating and how you capture it.
As a rule of thumb consider this:
The higher the resolution of your prototype, the more granular will be your feedback.
If you are in an early stage of the design process and you are trying to understand the value proposition of your future service, a shiny UI design might distract your test users from the actual value the service is meant to create. You’ll end up getting feedback on all kinds of design elements, like color schemes and buttons, and you might get confused whether you are actually solving a problem or whether your implementation of the solution just is not to the taste of your users. You are also more likely to get false-positives as results as test users tend to cheer nicely designed UI or just don’t dare criticising truly because they don’t want to upset you having spent so much time and effort already to make them happy. If you instead opt for a paper prototype, it is abundantly clear that you are not presenting the work of several weeks or months. Your test users have a way higher likelihood of being honest in their opinions and you can approach them with naivety.
That said, you must not neglect the importance of the deciders who are going to pay you after all. To make an investment decision, they need a clear at-a-glimpse offering from you. So be sure to really nail your value proposition and put a price tag on it. Your medium of choice might be a (fake) landing page or a (fake) newspaper article to kick off a problem- or solution-interview as proposed by Ash Maurya. The best form of validation you can get from deciders is of course a clear indication that they are willing to let money change hands. So give them some form of call-to-action whether it is a pre-sell of your (non-existing) service, a permission to follow up on them once the service launches to beta testers or have them sign a letter of intent.
Lastly, give your administrator testers a way to determine, how your service is different from any solution they are hiring right now to get the job done. Work with a a landing page section dedicated to explaining the features and steer your test administrators attention to it.
Figure out, what admins love about their current solution and show them, what other solutions you offer to improve on their workflow. You might want to go into detail here: Does a single sign-on option trigger something with admins? How about two-factor authentication, integration with other tools or priority support? This way you can also find out about your pricing and premium option for your service.
This article explored a Persona Framework for B2B Service Design. It explained how crafting a Company Persona first can help you to create more vivid People Personas for your user-types. The Persona Framework allows you to map the interrelations of your People Personas and their relationship with their Company Persona. Finally, it touched the right prototyping methods for your respective People Persona’s to match with their jobs-to-be-done.