Open source brand — LeanJS, ‘Iteration’ 2… Research
Welcome back to our series on the continuing exercise that we’re calling ‘Open Source Branding’!
Last time, we covered the initial steps we’ve taken to create LeanJS as a lasting, principled and future-facing company.
It was all about discovery — finding out how the current LeanJSers saw the company, what services we can/do offer as well as what they wanted from the company itself moving forward. To summarise we:
- Gathered all the existing assets
- Conducted stakeholder interviews
- Ran a survey with my other colleagues
- Affinity mapped findings, found patterns
- Created the company’s cheat sheet (basically who, what, why, where, when and how of LeanJS)
- Formed the company principles and mission statement
The forward plan
Remember the original mission Alex gave me?
“Paul, I’d like you to redesign the LeanJS website”
Well, it was time to revisit that original request and work as Lean as possible… Afterall, we are called LeanJS! So, the way we’re approaching it is a LeanUX project but much more out in the open. Our plan for the first phase of the website is:
- User research (of course, and what we’re covering in this blog)
- Create a low/mid fidelity prototype for the new website
- Test that with target users
- Iterate and improve
- Build and ship that low/mid fidelity prototype
So no fancy visual branding just yet. Sorry if you thought this was a branding/graphic design/visual identity series of blogs but we’re creating a new thing here!
The fact is, we need a new website as soon as possible and we saw it as an opportunity to show the world how LeanJS works — incrementally and iteratively.
Not only that, as this blog will show, I wanted to try out different processes that I’d not necessarily combined together before — to go back to our three of our company principles — be unafraid, keep searching keep learning and people centred products.
Competitor research
As any UXer will tell you, it’s good to spend time familiarising yourself with the market and your competitors. Considering LeanJS’s process of working only in Lean/Agile Methodologies on projects, we like to think ourselves a bit of a unique proposition compared to our competition.
So why bother looking if you’re ‘unique’? Well, this competitor research had a large remit. We were looking at:
- What the company did
- Their clients
- Tone of voice / messaging
- Social and IRL activity
- Their website
- Visual branding
I assessed a variety of different companies that offer the same sort of services we do and take all the information I’ve discovered and pit LeanJS against them. This is to determine where we aim to position ourselves on the market — one of the key goals for this whole project. No biggie then…
So what parameters do I use? For this, I go back to our new mission statement:
Be brave. Produce and radiate truly innovative, iterative and quality tech. Spread knowledge throughout our community, inspire fulfilling work and elevate quality of life for all.
…and then create a 2x2 matrices for whatever’s in that statement. For example, for ‘Be brave’, it was something like this…
Where LeanJS wants to be is in the top right hand corner, with the circly-swirly-company and photo-badge-company. These are the competitors that we’re looking up to and trying stand out from (sounds like a contradiction but hey, who said this was going to be easy!).
I know, this sounds like a lot? Well it is — it took a while and I did it whilst undertaking other tasks. Competitor research is a good thing to do in-between other discovery as that research will uncover new competitors.
It’s also a good example of qualitative and quantitative research as a fair chunk of the analysis will be coming from me. Not cos I’ve got a massive ego or something (well, I hope not anyway!), but because I’ve got to look at what the business aims are and try to find what’s good, bad, ugly and incredible in those competitors. Bias is always going to be a problem which is why we did…
User research
That’s right, the foundation of every UX process — user research.
There were a few different hurdles to jump for this step. LeanJS is a relatively young company — only 2 years old, and in that time has developed into a company that provides two distinct services: product build and training. The age and services of LeanJS meant that the target audience could be niche or separated into two distinct groups. Nightmare.
To combat this, I decided on a blend of different techniques as to not focus on the idea of personas and their grouping of individuals. Here’s what I did…
User stories
The fact is, the LeanJS team has a wealth of knowledge of our users that it would be silly to ignore. Don’t get me wrong, there’s always going to a lot of assumptions and biases going on but drawing on the business’s experience is a good starting block.
To draw that information out of my willing/unwilling (lol) colleagues, I asked them to create user stories. I’ve used user stories a lot in the past — they’re good for giving direction on a design or research project and helps get the people writing them in the frame of mind of why the user is doing something.
User stories can be confused with use cases — the key difference is that user stories adds the user’s context/goals to the use case. For example, here’s one of our user stories related to our training offerings:
As an engineer, I want to update my skill-set so that I can remain employable in the changing job market
The why is because the engineer wants to remain employable in an ever-changing job market. This helps designers create products that goes beyond the original ‘use case’ — in this case we could create a feature that calculates how much tuition fees will be and how much she needs to save every month to get to that goal. Or, it could guide the marketing team to create blogs based around saving for university.
In our case, I was looking for the patterns in how our target audience would interact with us. After much analysing of the dozens and dozens of stories, I grouped all the stories into 14 specific need states that the LeanJS website could try to accommodate — the most relevant being:
- Build and launch a product for us
- Change company products and/or processes
- Improve our company’s skills
- Learn and progress my career
- Attract and hire new talent
As you can see, the need states straddles both the ‘building’ and ‘training’ parts of LeanJS. This is a key point as it demonstrates the challenge of creating a website for such a unique company — one that builds products for clients, and also trains people to create products (this will crop up again later on down the line).
So we had our need-states, but what to do with them next?
Jobs to be done (JTBD)
Most UX designers — especially if they’re external client facing — would start by creating personas (or proto-personas at this stage) when analysing user research. I’ve created plenty in my time and don’t get me wrong, they can be a very powerful and persuasive thing.
However, I can find them constraining. I think this is because they were born from the idea of marketing personas — demographically based deliverables that clients could easily understand and quantify.
So in UX, where you are always aiming on working in need states, behaviours, intent etc, you’re forever caught in the push and pull of human-centred and demographic based information. In previous projects, I’ve tried to bridge that gap by creating two ‘versions’ of the persona… Nothing ever really felt right.
For LeanJS, being an innovative and forward-thinking outfit that lives the Lean/Agile life, it’s all about being outcomes driven — looking from a high level and iterating down to the details from there. Which is why, when my mate Charlotte Gauthier told me about the the jobs-to-be-done framework a while back, I realised because it’s more “outcome-driven“ than personas, it seemed only fitting!
What do they look like?
It takes it that one step further from user stories but takes the demographics out completely. Perfect.
So, this blog wouldn’t be open source if I didn’t share our JTBD now would it!? Here’s all our proto-JTBD:
Product creation
When I see that my team don’t have the time or skills to efficiently create an digital solution, I want a contractor to build the product and hand it over to us so we successfully develop it into the future.Product improvement
When a I’m charge of a product that has been ruined and needs an overhaul, I want contractors to efficiently identify, communicate and solve the key issues so the product improves and becomes a success.Discovering LeanJS
When I see an external contractor who can build the products I need, I want reassurance that their process works and I can trust them — immersing themselves in the project to fully understand context so I create a product roadmap efficiently.Long Term Partner
When I need to fully utilise my funding, I want to work with friendly but professional people that help guide the product strategy so I am reassured that there’s always a clear direction of travel.Upskiller
When I see that our team is not skilled enough to build/manage digital products and see staff moving to competitors, I want to find a quality and flexible training courses so my company is at the forefront of creating innovative tech — which both attracts and retains staff.Client attracter
When I see clients hiring competitors with more knowledgeable people, I want to put up-to-date training into place to expand the technical possibilities of the team so I can attract new clients to the company.Discover LeanJS
When I know that I need to improve my career prospects, I want to discover what courses are best for me to learn the latest tech and methodologies so I can move on to any job I desire or progress in my current role.Proposer
When I want to learn more and know that my company will support me in this, I want to be able to create a proposal/business case so I can convince my boss to give me funding to take the course I need to increase my knowledge.
Doesn’t exactly narrow things down for an MVP does it? Well, never fear, there was plan. Remember, these are all based on assumptions we had within LeanJS and, as such, we had an assumption that there were two key JTBD in there. So, as part of my user interviews coming up, validation of what was the key proto-JTBDs was vital. We would then have primary jobs for the MVP. Don’t you just acronyms?
Just quickly, you maybe thinking: “Paul, why didn’t you ask the LeanJS team to come up with JTBD instead of user stories”… Well, yes, I could’ve done but there’s two reason why I didn’t. Firstly, in my experience, people find it easier to start these processes with a demographic (Mother, CEO, Designer etc) — thus the prevalence of personas in user research deliverables. Secondly, it’ll help me with user recruitment when I’m looking for user interview and usability testing participants later down the line.
Now I had my proto-jobs-to-be-done, it was time validate and refine them.
User interviews & the ‘Lean Problem’
As any UXer will tell you, user recruitment can be hard, expensive and time consuming. This is where I find social media to be my saviour! I trawled through my network of friends, family, acquaintances and reached out to anyone who I might know have any experience in the jobs that I’d formed.
Luckily, I found the number I needed and started interviewing in the usual way. No leading questions, starting high-level — all that jazz.
Except, I did one thing differently to what I’ve done previously. After reading ‘How To Improve Your Design Process With Data-Based Personas’ by Tim Noetzel a couple months back, I was intrigued by the idea of including the ‘Lean Problem’ into user interviews (anything with the word ‘Lean’ involved, I’m interested).
Basically, it helps you validate whether the your stories are true to life by deliberately asking a user at the end of the interview a leading question framed in a real world scenario based on something in your past. The users reaction to that leading question can tell whether you’re stories (or, JTBD in this case) are in the right ballpark. Find out more about this technique in Tim’s excellent Smashing Magazine article here.
Gratifyingly, the users validated my jobs-to-be-done. Plus, I was able to focus things down to our 2 primary JTBD — these are:
Product creation
When I see that my team don’t have the time or skills to efficiently create an digital solution, I want a contractor to build the product and hand it over to us so we successfully develop it into the future.Upskiller
When I see that our team is not skilled enough to build/manage digital products and see staff moving to competitors, I want to find a quality and flexible training courses so my company is at the forefront of creating innovative tech — which both attracts and retains staff.
HMW’s and ‘Can we…’ questions
As Alex Lobera will attest to, I’ve been loving AJ&Smart’s evolution of the GV Design Sprint. After running many different types of workshops in my UX life, I think their refinement of a smart workshop-style design process is great. Go check out their YouTube channel on Design Sprint 2.0.
Anyway, back to me. I wanted to take a step back from all the research once it was complete and, informed by the user findings, look at things from a business perspective. Taking inspiration from the Design Sprint, I’d ‘asked the experts’ — now, I wanted to, in my own little way, create and prioritise some ‘How Might We’s (HMW)’ to bolster the challenges set out in the user stories and JTBD as well as colour the prototype’s content I was just about to create.
These HMW’s are the goals of the site, however big or small. Question is, what were the key HMW’s? Behold:
- How might we quickly convey our uniqueness in how we work?
- How might we not use ‘Lean’ as a buzzword?
- How might we show ourselves as passionate?
- How might we get more valuable leads?
- How might we put across how quickly we build quality products?
There were 33 more but these were the key HMWs from a company perspective.
Next, to follow the same sort of process to a design sprint, we looked at the ‘questions’ or potential risks of the website. These are questions that start with the phrase ‘Can we…’ and come from the opposite end from HMW’s — pessimism and negativity.
Sounds counter-intuitive but, like the HMW’s, these questions helped me focus on the key user/business painpoints that we need the website to address.
The goal statement
An outcome of everything you’ve read is the goal statement. It’s the thing we’re trying to achieve in the long term yet also something can evolve as the website proceeds into the future. After all, working Lean/Agile means continuous evolution!
So, here it is:
Create a website that conveys how LeanJS works with teams to improve their products/services in an easily understood way. To create meaningful leads from clients who are already bought into our methodology, even if they work in a more traditional environment.
It may not sound as impressive as a mission statement, or look as cool as an interactive prototype but it’s an essential step to success.
The next steps…
So now in this ever expanding (or maybe ‘evolving is better!) project, we’ve:
- Interviewed key company stakeholders
- Nailed down the who, what, why, where, when and how of LeanJS in the ‘cheat sheet’
- Created guiding principles
- Written the LeanJS mission statement
- Aligned the team on all of the above
- Analysed the competitors
- Extracted assumed user stories from the LeanJS team
- Created proto-JTBD for the LeanJS website.
- Interviewed users and validated user stories and prioritised primary JTDBs
- Written HMW’s, questions and goal for the website
From here, it’s all about creating a prototype and testing it with real users — the fun bit! Join me next time for ‘Iteration’ 3!
— — — —
What do you think of our approach? We’re all about constantly evolving our processes through learning and iterating so I’d love to know what you think of how I’ve done this process. Any questions or comments please just let me know. Comment below or shout me on Twitter :)
