Menu

Blog

disposable UI

It is all about “Disposable UI” – The Future of Front Ends

Kleeen Software is about to launch our 3rd generation Kleeen Authoring UI in Q1. And this isn’t a bad thing. We created a front-end, saw customers use it, learned from their real-world experience and feedback, then re-created it.  As we learn and revise, we still have a shipping product. And the effort to overhaul most of the supporting parts of our product (navigation, configuration, data/visual analytics, management) can be measured in days or at worst weeks – because only the unique or custom parts require manual development. 

We call this…

Disposable UI

The notion that we don’t have a deeply vested commitment to the front-ends we have built – because our value proposition is in the back-end, the systems, the services, algorithms and data. The front end is just the gateway for our customers to access our value. 

And this approach has freed our company up. Why would any company want to “keep” their existing user experience, after hearing what their customers need, when they know it is lacking? Product designs that tested well, still may not work when customer data is plugged in. A workflow that worked at launch and continued after the first N features might fail at feature N+1. But the cost (time, money, people) is just too high to rebuild your UI once, twice or even three times a year.

Some, very large, companies have adopted a “similar” approach. Apple is notorious for this. How often have they taken a software product, and released a completely new user experience? It seems fairly regular. Apple mail, photos, and a host of other applications on their phones and desktops seem to have major updates every few years. But most of us aren’t Apple. But we all wish we had their resources.

This disposable UI approach isn’t accessible to most companies. But it should be. You should iterate at a micro level, learn with prototypes, and not be afraid to reboot the UI. Your older versions should be able to be “supported” with minimal effort, and you should be able to get feature parity not long after. 

At its heart, this series is all about disposable UI. You should be able to validate your vision with a real UI, and not be afraid (time/money/resources) to throw it away. You should be able to make an MVP and take it to market in weeks, and not be afraid to change it up wholesale a quarter or two after (as your customer knowledge grows, and as your backend/data evolves). You should be able to maintain a product, and add new features in a day/week or two, and be 100% ok to make a better version a release later – so you can respond to customer feedback immediately without impacting your larger product plan.

In the coming months, Kleeen will be sharing a new way to design, build, validate, and maintain front-ends. Turning these exact 3 moments (validation, MVP, maintenance/new-features) into places where a change can happen in your organization, where a new type of solution can change the trajectory of your project.

And Kleeen Software can help you and your organization have disposable UI too.

Cover Image Photo by bady abbas on Unsplash

all-about-maintain

It is all about “Maintenance and Features”

Your first customers are using your product, and the word around the water-cooler is that you have a really cool solution. But now the first new feature request comes in, the next control someone wants access to, the first enhancement, the first custom screen. Now you have to tweak your navigation system to support another page or 10. And this doesn’t stop – it never stops. Every workflow, every page, and widget you shipped now needs to be maintained with love and attention to keep your customers happy, while at the same time your team needs to focus on building the next key feature (there is always another key feature on your roadmap). 

And what’s worse, success doesn’t just depend on what your specific project does or does not do… it also depends on the industry “bar.” For a long time having an effective UI wasn’t a requirement for a new enterprise app, but now it is standard for any B2B software solution or IT project. And not just any UI, but it is extremely important that every UI has theming, has internationalization, has UI access control – and the list goes on and on. As the industry changes and evolves, more things are expected of your solution beyond the domain-specific features you need to ship!

Maintenance is a war you cannot win. It feels like a war of attrition. And the current conventional approaches just don’t scale.

Hire More Engineers

This is only possible in the largest of the large companies. Hire (or reorganize existing staff into) teams of 50, 100, 250 full-stack/front-end engineers. Now half or ¾ of your team has to spend time on customer enhancement and feature requests – and only the remaining developers (and designers – which of course you must have more than one of) can focus on creating the next marque capabilities. But unless you are really growing your sales and ARR, this is a constant pipe dream – and your roadmap will likely slip away in favor of chasing customers. And don’t even ask if the changes your maintenance team is making are compatible with those of your new feature team.

Score

⬆ Many People | ⬆ Lots of Money  |  ⇣ Not Realistic
⬇ Removes Focus on your Roadmap |  ⬇ Minimal Risk 

Expand to offer Professional Services

The cash-cow of most modern large-scale enterprises. Have a professional services team that will (for an agreed-upon price with a customer) build any request. This ensures the cost spent on these enhancements is paid directly by customers, and your overhead is reduced; our core team can now focus on your main product and feature roadmap. This can be a great solution, and it brings in revenue. But for this model to work, you need to have enough customers to justify/cover the cost of all the services you sell. Furthermore, your customers must depend on your solution enough to want to pay to customize it. Plus your customers must also have the budget to keep paying for your services. So while this is more attainable than a 200 person design and dev team, it is outside of the scope of most IT organizations, startups, and product teams inside of enterprise — especially B2B companies whose primary business is not software. Not only will it likely be out of the scope of your teams, but the business model can also be radically different from your core business – how you bill, the terms of service and service level agreements, the ratio of staff expense to revenue, and on and on and on.

Score

 ⇡ More People |  ⇣ Less Money  |  ⇣ Not Realistic
⬆ Keeping Focus on your Roadmap |  ⇡ Somewhat Risky 

Ignore your customers

Take this approach at your own peril. If you trust your roadmap so much, you can focus on your new features and enhancements and only address bugs and incomplete functions you hear from customers. Plenty of companies have tried this – they have such a captivating product/service that customers will use it no matter what, or for many IT/HR solutions it might be the only available solution so you have a captive audience. And sometimes (like for IT teams) you already have too many other new projects to develop – you only return to existing solutions if they truly break. Here you hope you can focus more only on new projects and features – and try to ignore your existing technical debt by outrunning your shortcomings with new technologies and solutions – also known as “smoke and mirrors”. 

Score

⬇ Fewer People |  ⬇ Minimal Money  |  ⬇ Highly Un-Realistic
⬆ Keeping Focus on your Roadmap |  ⬆ High Risk

The key observation here is that products don’t just “stop” once you go live with a new release or come out with a new feature. These are living solutions that need care, attention, and upkeep. How do you maintain your moving train, which can’t “pull over,” while still adding a dining car, sleeping car, and 200 other types of cars?

  • It isn’t enough to hire more people, you won’t have the budget
  • It isn’t enough to make/sell professional services, you need a large, active and deep-pocketed customer base that is already deeply committed to your product.
  • It isn’t “smart” to ignore your customers, you need to respond to their needs, but you can’t ignore your roadmap.

A solution is needed to increase the likelihood of success, decrease time to market, decrease delays, and ensure a consistent output. You need to free up your team as much as possible while keeping customers happy and moving your company forward. This is the exact moment where a change can happen, where a new type of solution can change the trajectory of your project.

But honestly, even once your product is in motion – we may just need a new way to think about our front-ends…. 

See Our Next Article In This Series:

disposable UI

It is all about “Disposable UI” – The Future of Front Ends

Disposable UI – The notion that we don’t have a deeply vested commitment to the front-ends we have built – because our value proposition is in the back-end, the systems, the services, algorithms and data. The front end is just the gateway for our customers to access our value.

Cover Image by Drew Bae on Unsplash

all-about-mvp

It is all about the “MVP”

You believe you know what you need to build. Your customers (internal or external) are falling over their feet for your vision. All you need to do is get your MVP, your V1.0, into their hands. And once you do, you can pour fuel on the fire and take off. But how do you do this? How can you get there as quickly as possible, with as few resources (time, money, people) as possible? We all know, building a product takes a lot of work – so the more of the burden that you can take off your team’s shoulders the better.

The current approaches (at least for front-end creation) presented below just simply don’t cut it — You need a new type of solution that can change the trajectory of your project and maximize your chances of success.

You could build your entire front-end by hand

This is how most projects are built. Use a framework (React, Angular, Vue), choose a handful of libraries (D3, Highcharts, Components), and then hire a team of UI/UX designers to figure out the optimal solution. Then hire a team of engineers to build it out. You get control over architectural/design decisions, and everything can be pixel perfect.

However, this takes time – and we mean a LOT of time. Everything is a decision that must be made and likely discussed. Architectures are often custom-made, making them hard to understand and maintain by consultants and contractors. And your skilled team (and we mean a full develop/test/deploy team) must hand design and code every configuration screen, every navigation element, every detail – even the ones that aren’t going to move the needle. And of course, there is a high amount of risk because it will take months to know if you have even built the right thing.

SCORE

⬆More People | ⬆ More Time  |   ⬆ More Money  |  ⬆ More Control
⬆More Risk |  ⇡ Some Technical Debt |  ⬇ More Resources to  “Move the Needle”

You could use templates

Every new project is tempted to go online and download a “template” for a product. Usually, this will come with a pre-canned dashboard and navigation system – maybe another page or two. And these template’s cost is absolutely minimal, and the screenshots posted look super slick. Certain gaps can be covered without needing specialized engineers or designers.

But now, your team needs to convert these “stubs” into an actual product. Your engineers need to slog through all this code (which likely isn’t well organized, documented, or written) to ensure every button does the right thing and every link goes to the right place. Every widget on a dashboard and every user input now needs to be customized – and I don’t just mean changing a name. Widgets need to be completely reworked to integrate with your data, your interactions, your product. And what if this “template” doesn’t support a feature you need (e.g., internationalization, theming, UI access control). In that case, your team needs to go through the entire project and refactor all the code you got as a “template,” re-writing large chunks. And why did those screenshots look so “slick?” It is because the demos were overly-simplified – they often have tons of pictures, people’s faces, and visually pleasing UI elements that have no relationship to an enterprise product, IT solution or B2B software. And once you remove that useless eye-candy, you are left with the hollowed-out skeleton – and saddled with the technical debt of someone else’s architecture and design decisions. But you didn’t start from scratch, and you got out the door faster. But have you ever wondered why most startups, companies and IT departments don’t use templates? That should say something…

SCORE

⬆ More People |  ⇡ More  Time  |    ⇡ More  Money  |   ⬇ Limited  Control
⇡ Some  Risk |  ⬆ More Technical Debt |   ⇣ Some Resources to “Move the Needle”

The key goal here is that you need to get it as real as possible to get customers using your solution while putting forth as few resources (people, development, money, time) as possible. How do you ship a fully functional front-end while leaving you time to differentiate yourself from your competition? 

  • It isn’t practical to try to make everything perfect, you need “good enough,” and more importantly you don’t have time for perfection (even if you even knew what perfect was at this point). 
  • It isn’t enough to build from a half-complete house without a foundation, you need to know what will work out of the gate, using best-practices from day-one. 

You need a solution to increase the likelihood of success, decrease time to market, decrease delays and ensure a consistent output. You need to free up your team from the mundane aspects of product creation, to make content that sets you apart from your competition while getting it in the hand of customers ASAP. This is the exact moment where a change can happen, where a new type of solution can change the trajectory of your project.

But honestly, once you build your MVP – you still need to get to maintain and grow your product….

See Our Next Article In This Series:

all-about-maintain

It is all about “Maintenance and Features”

Your first customers are using your product, and the word around the water-cooler is that you have a really cool solution. But now the first new feature request comes in, the next control someone wants access to, the first enhancement, the first custom screen. Now you have to tweak your navigation system to support another […]

Cover Image Markus Spiske on Unsplash

all-about-product

It is all about “Idea Validation”

You know your customers’ pain points. You have a vision – a solution. It isn’t some generic vitamin — you know you have a kick-butt pain killer. Now you got funding or approval for your project. You are ready to go. The next step is to validate your solution, iterate quickly, fail fast, then iterate more. You don’t have time to spare, because you know your competition might be just right around the corner. 

The conventional approaches presented below just simply don’t cut it.  You need a new type of solution that can change the trajectory of your project and maximize your chances of success (while reducing risk).

You could take an ethnographic approach

Go interview tons of potential customers, but starting down this path is slow and hard. Without something tangible to show them, words can be misinterpreted – brilliant ideas become vague and unclear – and you can get led in the wrong direction through a simple misunderstanding, especially if your idea is really new and the users have no reference for evaluating it. 

SCORE:

⬇ Low Fidelity | ⬆ Good Feedback  | ⬇ Minimal Validation
⬆ Much Time  |  ⬇ Save Money | ⇣ Minimal Risk

You could take a design-centric approach

Go hire a designer (full time or contractor) to go make mockups (pictures). You can even use some amazing tools like InVision or Figma to make those mockup pictures be clickable to “simulate” a real product. But mockups take time.  Weeks of time. Every iteration is another week or more before the next set of designs. And while InVision and Figma are great for bridging the gap between design and engineering, let’s be honest – clickable pictures are still a far cry from having a user “interact” with a real product with real data. Not every interaction is mocked up, the data isn’t real, and the “mockups” don’t feel like (or provide feedback like) real software does.

SCORE:

⇡ Minimal Fidelity | ⇡ Minimal Feedback  | ⇡ Minimal Validation
⇡ Some Time |  ⇡ Some Money   | ⇣ Minimal Risk

You could take the build-it-first approach – Like so many startups, IT departments, and new product development teams at large companies – you could just “build it first.” And it is true, what you get on the other end is as high fidelity as possible – but it takes time. And I don’t just mean weeks… Building a functional product takes months. It isn’t just the front-end; you need the APIs, the databases, the analytics, the data. And if you find out 4, 8 or 12 months late that you built the wrong thing (or even the right thing with a totally wrong UI)… well then. You better hope your competition hasn’t figured out the right answer.

SCORE:

⬆ High Fidelity | ⬇ Delayed Feedback  | ⬆ On-Point Validation
⬆ Much Time   |  ⬆ Much Money   |  ⬆ High Risk

The key thing here is that you need to get it as real as possible to trust your solution while putting forth as few resources (people, development, money, time) as possible. How do you test potential markets to find product-market fit without committing your entire team? 

  • It isn’t enough to have conversations with customers, you need to validate exactly what you want to build
  • It isn’t enough to show mockups, you need to validate the actual interactions, real data and real use cases
  • And you don’t have the resources to blindly build first, you need to have confidence in your solution – because you can’t “get back” time and money.

A solution is needed to increase the likelihood of success, decrease time to market, decrease delays and ensure a consistent output. This is the exact moment where a change can happen, where a new type of solution can change the trajectory of your project.

But honestly, once you validate your vision – you still need to get to MVP…

See Our Next Article In This Series:

all-about-mvp

It is all about the “MVP”

You believe you know what you need to build. Your customers (internal or external) are falling over their feet for your vision. All you need to do is get your MVP, your V1.0, into their hands. And once you do, you can pour fuel on the fire and take off. But how do you do […]

Cover Image by Frank Vessia on Unsplash

iceberg

Why UI Takes So Long To Build

We all use UI. Log into Gmail – UI. Need to update Salesforce – UI again. Even using your desktop OS – one more UI. Front-ends seem so ubiquitous, so how hard can they be to make? But when you get into building and maintaining complex software – somehow the UI piece seems to take forever.

You rarely see UI projects that go completely smoothly. Some enhancements or features that seem complicated (e.g., virtual-scroll) come out fast, and others that seem straightforward or commonplace (e.g., internationalization, UI access control) take a very long time. And for sure, getting “my basic application running” always seems to take forever and a day – but it feels like a workable UI should not be such a big deal.

Whether building an internal or external facing application, people are continually asking me why the UI takes so long? Whose fault is it? Who do we hire or fire to fix this problem?

In my experience, this turns into an unproductive blame game. Some people blame the project’s management, claiming that the Engineering Manager or Product Manager isn’t on top of things and isn’t adapting quickly enough. The other main scapegoat is engineering – claiming the team uses second rate engineers/contractors (due to lack of available budget/talent). These are undoubtedly potential sources of problems (and having top-notch talent and an unlimited budget can solve many situations). More often than not, I have found that the real issue is misaligned planning and expectations due to the lack of understanding of issues involved in making a competent front-end.

Why UI Takes So Long To Build

Getting MVP/1.0

Why UI Takes So Long To Build

Maintenance/Minor-Enhancements

Why UI Takes So Long To Build

New Features 

Most people think of a front-end as the content that they can see and click on their screens. But those texts, images, buttons and other such content are only the User Interface (UI) – the visual elements you can see and interact with. This is the tip of the iceberg that comprises a front end. The majority of the front-end system that powers and makes the visible UI possible is all of the infrastructure, data, and components – to your user, the unseen part of the iceberg looming below the visible surface. And yes – the iceberg metaphor is often overused. But it is extremely apt in this situation. What you see above the water, is LITERALLY what you see in the UI.

This article details how much work front-ends really require… and how your engineering team spends their time in the 3 key phases of front-end development: MVP, Enhancements, and New Features. We conclude by discussing where automation can streamline this process and shave weeks, months, or even quarters off of your time to market.

Click to Expand Infographic

Getting to MVP or 1.0

This is the process of getting from nothing to something. It is how you start. When starting a project, the common wisdom is to get to market as quickly as possible. Realize, however, that any scaffolding, features, or integrations omitted to reduce your project size MUST be built later to scale up. So any time saved really incurs technical debt – time deferred PLUS the additional time to refactor/rebuild (fix) the original implementation.

There are three main components to getting your front-end out the door:

  • 55% Common Features – This is visible UI
  • 25% Application Scaffolding
  • 20% API Integration

As a rough guide, it takes almost the same amount of work to get the part of the UI feature you see running, as it does to get the supporting infrastructure in place to make it work.

Common UI Features (55%)

This is what you think of as a UI. These are the visual elements that you see when you log into your favorite application:

  • Navigation
  • Dashboards
  • Visualizations
  • Table views
  • UI Styling
  • UI Interactions

But remember, even these visual elements are more than just the pie chart or link you can see – the tip of the iceberg. The advent of UI libraries of buttons or visualizations makes only a small dent in the time needed to implement a common UI feature. Someone needs to get data in and out of the UI element. Someone needs to tell the system what happens when you “click” the button or wedge in the pie chart. Laying out these elements, making sure they have the right behavior, visibility, etc – that takes a huge amount of time. Every interaction, hover effect, or link must be hand-crafted. And all of those other aspects are likewise below that water line. 

Application Scaffolding (25%)

This is what makes your front-end “work.” This work is entirely “below the water” and is never directly seen by users, but you feel the effects of it every time you use a UI:

  • Defining the web application architecture
  • State Management
  • Separation of concerns
  • Layouts
  • Authentication
  • Routing

This design and infrastructure is vital. For example, let’s look at State Management. Consider a “save” button – will it be enabled or disabled? This is determined when a user changes the value in an input field (and that field is valid). Connecting these two UI elements is “state management”. You can implement this slowly or quickly — but quickly will mean you will likely need to rebuild it later on, as state management can end up becoming one of the most complex problems in user interface development because the number of components, inter-component interactions, and dependencies grows massively and exponentially.

API Integration (20%)

This is not the work to build APIs, nor is this getting data into the pie chart. API integration is the “conversation” between your front-end team and your back-end team – ensuring that the data needs of the UI (and performance needs of your customers) align with your backend or services. This effort usually includes:

  • Data schema validation
  • Making (and testing) API calls
  • Data flow integration (and debugging)

Of course, every time something changes or “evolves” the back-end or API layer, it likely causes the front-end team to be forced to update their API integration. Note that these back-end updates are rarely backwards compatible for the UI – so your UI cannot just limp along after a change, it must be fixed/updated immediately (and any test suite for the UI must be changed as well). What is worse, many UI features are often held up as the team awaits the API and back-end to catch up to the front end needs. Needless to say, this entire section also lives below the water line of visible UI.

Going into Overtime!

Oh wait – you thought your MVP/1.0 was done? Not quite yet… Of course, there is also overhead which will make projects go into overtime. Doing QA takes roughly the same amount of time as building your front-end itself (+100%). Ideally, this is done 100% in parallel with the front-end development, More likely it will be offset by 2-4 weeks, and is often started only when the project is 50-70% complete. 

Another thing that can push a project over is bug fixes. As a rough estimate, this can be an extra +10% of the original project length. Here is where skilled developers, good project development processes, and solid testing methodology/tools can help, but bugs always happen.

Lastly, DevOps (CI/CD) process cuts into project development, adding in an extra +25%. Techniques like GitOps and structure around Pull Requests can help, but simply working in modern applications imparts overhead. Otherwise, you will get to the end of your build cycle – and nothing will have been tested, deployed, or integrated. This overhead is actually an investment in future success – it helps create an application that is robust, documented, and tested – but you must pay the price for this future stability.

In a best case scenario, everything that can be done early or in parallel is done early and in parallel. This will likely only cost an additional 50% above and beyond the original scoping. But if QA is started late, and bugs+CI

Click to Expand Infographic

Maintenance + Enhancements

Everyone thinks it is party time once the MVP is out. But in reality, we are just trading one challenge for another. Whether you are using CI/CD, waterfall, or some other approach to release cycles – development simply takes time.

While the size of the update/enhancement increases the time required, the underlying process for engineering takes the same amount of time (once any mockups, designs, specifications are provided to and understood by the team):

  • 30% Styling and other UI refinements (Theme, Fonts, Icons)
  • 25% Workflow (UX) Improvements (interactions, layout, and component’s structural changes)
  • 20% Refactor to support new functionalities from UX and UI refinements
  • 25% Product support (APIs, internal documentation, fixes, libraries update)

While the most visible improvements take around 30% of the time, and the functionality improvement takes around 25% of the time, the ripple effects (refactoring and support) are often almost as large as the enhancement itself (45%). This is why so often even seemingly minor changes can take large periods of time to get right – it isn’t just that you moved a button, it is everything else that has to be adjusted to allow that move to happen.

One major thing that can also slow down enhancements are UX changes. For example, consider tabular top navigation systems [1][2][3][4].

These always are very clear and easy to read. However, because words are written horizontally, after maybe 5 or 7 pages, you simply run out of space in your top navbar. So adding “one more link” to your navigation bar might require a larger refactor to make a hamburger menu or even switch to a completely different navigation paradigm. 

And don’t forget, enhancements also go into “overtime” as well – adding in QA, bugs, and CI/CD. Depending on planning, that could include an extra 50 to 105% onto your enhancement/maintenance time-table.

Click to Expand Infographic

New Features

In general, it is impossible to estimate a brand new feature’s development time. Every feature is different but consider them largely like doing an MVP again (at hopefully a smaller scale). You will need to Create UI, Provide scaffolding and Integrate APIs (and test, test, test).

to get this new feature to work. That is the minimum for a new page. You likely also have to touch many of your existing pages to link appropriately to this new content, if not deeper integrations. And while the feature in question can greatly augment this breakdown, usually the UI itself is 55% of the work – with 25% of the time spent on scaffolding and 20% on Integrating APIs. But the story does NOT end there…

Now consider something like internationalization, restyling/face-lift, or UI access control. These are features that literally will cause your team to refactor every existing page in your product (unless you planned way ahead when you first started – which is extremely rare since every project is under the gun to trim everything that was “unnecessary” to get the MVP out). As a result, all the things you built up front have to be refactored anywhere from 10-95%. This is why major features, new content that changes a product from Version X to Version X+1 take so long: so much time must be spent updating everything that already exists. And the longer your product has been around, the more time this new feature will take (consider it interest on your technical debt).

A new feature often will therefore result in at least 30% existing product refactor, with 38% on new UI, 17% on scaffolding, and 15% on APIs. And don’t forget the QA, Bugs, and CI/CI adding in that 50-105% present.

Automation for Front Ends

Let’s be clear – we could write (and TechRadar as well as our Chief Product Officer has written) entire blog posts about how automation can make this process better. That is not the intent of this section. However, we do want to quantity some of this impact given the context of this article.

Consider the MVP. 

  • Imagine if a solution could automate UI/UX design and build 70-90% of your UI, all the navigation and common workflows (configuration, monitoring, investigation, etc). You are then dropping your UI feature development from 55% to 6-16%. 
  • Imagine if a solution could automate your scaffolding – setting all your frameworks and infrastructure (minus anything truly custom you might need). This could take that 25% of your time down to 3%.
  • Imagine if, for all the parts of your application that are automated, all the APIs needs for the front-end have to have full specifications remained consistent with the automated changes. Your UI team would no longer need to do any of the API integration for these automated elements. This would reduce your API integration time from 20% down to 2%.

As a result instead of spending 100% of the estimated time, you only need to spend maybe 11-21% of that original time to get your MVP out the door: a reduction of 79-89%. This is also a valid estimate for maintenance. Adding a new widget, a new action, a new CRUD operation could likewise take hours or days, instead of weeks or months. 

This is the type of world Kleeen Software is making a reality. Taking larger amounts of the front-end stack off the plate of designers, engineers, and product managers. And with all this free time – your UI engineers and designers can focus much more (and perhaps all) of their time on creating something new and exciting. They could create sizzle, something innovative, something no other company has done before (instead of one more config screen, one more investigation, one more monitoring screen). Kleeen Software’s impact is measured not in hours, but in months.

The Takeaway

As trite as it may be, the iceberg metaphor applies to the product front end development process – there is barely even a need to change the vocabulary. The visible part is, in fact, the visible part of your UI; everything else is underwater. Not only do YOU not see the underwater part – (but if done correctly) neither do your customers. They don’t care about the underwater part, but in order for the visible part (the buttons, form fields and visualizations) to float effortlessly, that underwater part better be robust.  (If you are interested in other things that are often hidden but take a lot of work – I love this podcast: 99% Invisible)

Looking at your next project, and the future of front-end automation Kleeen Software is providing – a new calculus must emerge. You can be spending lots of time working on completely necessary “UI development” and still have it look to your customer like you have nothing to show for it. Or, you can let Kleeen do all that and concentrate on noticeably improving the visible part.

Cover Image by Annie Spratt on Unsplash

outside-the-box

The Citzen Developer Revolution

Low-Code / No-Code is a technological trend that is attracting attention in every B2B sector [TechCrunch, Inc, Forbes, Ascend.io]. This disruptive technology brings automation to the tech stack (UI, Infrastructure and Data Science), empowering developers to accelerate their productivity in the creation of key business solutions.

However, it is important to note that the term “developer” is a poor choice of terminology in this space. Up to this point in time, we all have thought that being a “developer” meant being an  “employee”: trained individuals (either through personal development or formal education) who know about algorithms, data structures, and UI creation. These developers were company technologists: programmers or engineers.

However, with Low-Code / No-Code making development more accessible – three distinct categories of developers have emerged. Indeed, the categories are not completely distinct, rather these new developers exist on a spectrum. Of key importance, not all low-code / no-code solutions are suitable for all of these new developers.

account-code

Professional Developers

This is what we all think of as a CLASSIC developer – an engineer in training and practice. Low-Code / No-Code solutions in infrastructure, schemas analytics and process builders (hooking up services) are vital and useful. These are solutions that automate or simplify the burden of detailed bookkeeping, complex interconnectivity, or batch processing.

account-flash

Citizen Developers

This is a product owner, a team leader, product manager, VP or even someone in IT. A person who intimately understands the use-case to be solved but doesn’t have the technical skills (design or engineering) or the time/budget to create the solution.

citizen-developer… non-IT professionals gaining access to tools and expert systems that empower them to exploit and apply specialized skills beyond their own expertise and training

Gartner Identifies the Top 10 Strategic Technology Trends for 2020

For them, a Low-Code / No-Code solution can translate their vision into reality, converting end-user objectives into attractive UI, effective user workflows, and production-grade front-end code.

[“citizen data scientists” Gartner 1, “citizen programmers” Gartner 2]

account-time

Personal Developers

This is the average person who wants to create a small application to manage and organize a simple process or workflow. Low-Code / No-Code technologies for these users are often built on top of a very simple “spreadsheet” data source, and allows the Personal developer to drag and drop basic display elements (images and text) and form fields to design a UI for web or mobile applications. While the complexity of the realized application is limited, for many Personal developers – so is the complexity of their tasks.

What is so exciting about the Citizen developer is that they represent an unrealized resource for most companies. These are individuals who truly know the ins-and-outs of the customer. Consider a product manager who has spent months talking to and engaging with customers: they know their customer’s pain-points. On the other hand, imagine the IT team member who knows how the company works and how to lead employees to the insights and actions they need to be productive. Even a Business Consultant can look at the client and envision an ideal solution to help their client excel.

Before they were empowered, the Citizen developers’ vision for a solution was all too often left unrealized as they lacked the skills (engineering, UI design, or workflow design) to create a working system. Even with WYSIWYG tools, their goals are left unfulfilled – as these experts do not know what to drag and where to drag it to. They often have limited resources (time, money and team-members), which are already committed to other initiatives. 

But now imagine what would happen if each of them could, in minutes our hours, express their vision for a product; what data their end-user needs to see (the trend of a patient’s blood pressure), the objectives needing to be accomplished (monitor a feed of network events), and the actions to be taken (suspend a financial account’s future transactions).  Suddenly a huge number of the company employees can create actionable products – validating and testing ideas, and perhaps most importantly, taking work off the plate of the overburdened Professional developers – allowing them to focus on more critical (and interesting) work that require their specialized skills.

The Citizen developer is the future of every B2B company. And the Citizen developer is driving the future of this high-value category of Low-Code / No-Code technologies.

Cover Image by Nikita Kachanovsky on Unsplash

biTools

Limitations of BI

Everyone loves a good dashboard. To be perfectly honest: dashboards can be stylish, dynamic, and inviting. And we have all heard many times that products need dashboards to bring that “cool factor.” But are dashboarding solutions really that useful? 

The term of art used is “visual analytics”. Dashboards allow someone to visually understand their data by leveraging human perception instead of cognition to process the relationship between a bunch of raw numbers. The emphasis on visual analytics has spawned an entire industry vertical of dashboards and Business Intelligence (BI) tools. But while these tools have helped users visualize their data, they often seem to feel lacking when used in practice. They seem to just fall short in solving real-world problems.

This article will focus on how BI-tools have limited utility for empowering knowledge workers to take actions. As a result, we need to start thinking about solutions that help us create products faster; where any visualization of data are there to provide context, and is in service of helping an end user to take actions.

But if you ask end-users of BI solutions, why do they dislike their visual analytics tools, they cite the inflexibility and complexity of use (even when they know what it is they want to do), or the difficulty in setting up a new BI project. And while those are all valid concerns, they do seem to run surprisingly close to the adage attributed (or misattributed) to Henry Ford:  “If you ask people how to improve their transportation, they will ask for a faster horse”. 

And this is what makes finding an effective dashboard solution so hard. When you only have a hammer (reporting tools), every problem looks like a nail. That hammer will never be the tool to deliver what they need.  

So given the frustration, do teams really need a simpler/better reporting solution or is the problem really something else?

So let’s take a step back… why do we need to understand our data? Daniel Rosenberg, design professor at SJSU states in his new book “UX MAGIC” that:

A dashboard visualizes summary information for a family of related objects. The information selected for placement in a dashboard must support decision making. If no decision is facilitated by the dashboard, then it is just artwork to impress executives, not real [Interaction Design].

Clearly, visualizations and BI are not an end in themselves. The GOAL of every user workflow that involves visual analytics is making a decision and then taking action without having to use a separate tool thus doing something with the new understanding, context, or conclusion. The visualizations are needed in service to the end-user learning or knowing what steps to take (and identifying which actions are required). Any attempt at visualization must be in service to supporting that action selection and decision. If you reach that decision to impact your business via any BI dashboard today, you must use one or many other tools to affect that change.

Example Use Case

We all have received that call from our bank, where there is a suspicious charge on our credit card… These calls come from the Financial Fraud Detection team, who monitor suspicious activity and take actions to respond. 

The job responsibilities and workflows that they need to accomplish consist of 3 main activities that result in taking action:

    • [context] monitor holistic views of the bank and its accounts
    • [understand] Identify compromised or suspicious activities/account(s) ASAP
    • [understand] Drill in to understand the context
    • [take action] Immediately take actions to remediate suspicious activity…in real-time

Notice that, like all applications, the monitoring and visualization-heavy workflows are only there in service to enable the Fraud Analyst to take an action. The use of visualizations (over a large and complex data table) is to speed up the analyst’s understanding by switching the human memory burden from cognition (which is slow) to visual perception (which is lighting fast) and get him/her to take appropriate action rapidly and accurately.

In this example, if all the Fraud Analyst had was a written report on the data at hand, the effort required to drill in, identify the problem and remediate it would be extremely difficult. The desired action would be separated from the context.  Success would depend on the chance that the analyst had exactly the right slice of data in front of them at this particular instant in time. Such a report (or such a constrained dashboard) would not provide the right context.  Beyond that instant, it is also unlikely that the report/dashboard would seamlessly fit in the workflows needed to come to an effective conclusion.

Thus we can see that “understanding a problem and then taking the right action” is the edge of BI provides. It is the first step in providing a useful application. The goal of such an application is to make an ACTIONABLE system. Any B2B product you buy will have visualizations, dashboards, or other visual workflows to help inform the end-user and guide them to take a step, make an action, move the needle. 

And this is why team after team is frustrated with BI and dashboarding solutions.  Whether or not the users can articulate their underlying pain point, they are looking for the application to support them in doing something actionable. Visualizations and dashboards are hit-and-miss.  If you are lucky, the action required is extremely light-weight. But just as easily they can confuse the user by throwing data together without providing a clear and simple actionable step to resolve the discovery. The need for visualizations is the symptom of the problem (data is very complex), not the cure (diagnosing a problem and coming up with an effective action/solution). The cure is to identify the problem that fits the domain of the business, to determine a solution that concurrently supports both the data and the business workflow, and finally to take actions that solve the problem and improve the business — Is it any wonder that the end-user often cannot articulate their frustration?  They have been given a hammer so to them every problem looks like a nail.  They need an entire different class of easy to use and affordable tool that does not yet exist until now.

Cover Image by Edho Pratama on Unsplash

needUIUXautomation

Why we need Automation for UI/UX

Getting good UI (the visual presentation) and UX (workflows) into production is hard. In many cases it is an order of magnitude harder than getting traditional software deployed. Hence, in the zero-sum game of engineering resources, many UI/UX efforts never get the necessary time or resources, and a lot of  usability efforts never see the light of day. Organizations simply give up on developing good UI/UX to drive their products and customer experiences, relying on their underlying technology (e.g., great data science, great hardware, or access to great data) to make a sale.

From what I have seen running a B2B software design studio, a fundamental blocker preventing the creation of UI/UX at scale is the absence of automation that can translate vision into code. Some low-code/no-code solutions (either programming meta-languages that procedurally generate UI, or drag and drop UI builders) have emerged that have attempted to solve the process of building UI, but these tools still require the user to translate objectives into structure. The yawning chasm is the lack of intent-based automation that does that heavy lifting for the development team.

This blog post discusses why the industry needs to solve Automation for UI/UX, and the unique challenges that stifle efforts to get front-end creation (both design and engineering) operationalized and launched into production. It goes on to describe the vacuum in the current low-code/no-code ecosystem.

Website creation

Thinking back to 20 (or even 10) years ago, companies would go through a multi-million dollar process to develop their website. Websites were mostly custom written projects, with designers, copy-editors, and engineers working long hours to get even the most basic web-presence. Geocities websites just wouldn’t cut it if you were a B2B corporation, As a result, businesses would either form large in-house teams, or contract out to specialized firms to design, build, update and maintain their website. 

Then in the mid 2000’s along came website Content Management Systems (CMS). CMSs ranged from highly customizable (Wordpress and Drupal) to end-to-end platforms (Squarespace, Wix, and Shopify). Regardless of their approach, CMSs managed a common thread of pain points. Most websites had a common set of use-cases, and through templates, the company’s marketing team (or even a single marketing person) could design, update, and maintain their own website.

The advantage of the template-based approach is that while most developers, marketing teams, and executives do not know how to create good UI/UX, the template ensured an acceptable minimum quality of consistent UI (and to a lesser degree, a reasonable UX) for both the website creation process and its use by customers once deployed. This was another reason why templates were so safe and effective (for product managers and development leads)..

This fundamentally changed the scope of the engineering work. Previously, engineers were responsible for creating everything down to the smallest button as well as developing unique content. Now, companies were able to focus their limited resources on creating custom content, running web-campaigns, and responding quickly to their customer’s needs and challenges.

employees are 125% more productive when inspired by high value work

– Time, Talent, Energy By Michael Mankins and Eric Garton

Some key benefits of CMS 

  • Marketing/Product-Management owned the website. They were empowered and ultimately responsible for what website is in production. This sense of ownership generally increased quality, as well as timely website updates. Decisions of when and how to create “custom” elements could be planned, discussed, and iterated on — thus improving quality and predictability.
  • Teams were able to iterate rapidly. No more chafing under the imposed slowness of months-long waterfall cycles. Most changes could be handled in minutes or hours, instead of days or weeks. Larger efforts could be telegraphed weeks or months in advance; customer feedback could be solicited and integrated; even A/B testing became possible for most companies.

Today, the CMS website based approach is the default for many (if not most) B2B companies.

Complexity of Web Applications

While templates and drag-and-drop editors (also known as WYSIWYG or what you see is what you get) work quite well for websites, they fail to deliver for web-based applications. Even though they are also displayed in a browser, web-based applications are a different beast.

Webpages are primarily for information and marketing, allowing a potential/existing customer to understand what the company offers. The available options for interactivity are generally low, often including  search functionality, pricing/payment or form completion.

Web applications, however, are full-fledged applications in their own right. They allow an end-user to perform tasks that are a critical part of their job. Users (especially business users) depend on complex workflows that contain stateful information across multiple screens. They must investigate, configure, troubleshoot, monitor, and visualize data to make critical decisions for a business, hospital, or infrastructure. Unlike websites, application usage must:

  • Allow users to discover and access data at multiple levels of granularity
  • Cross-link data to follow trails of information
  • Provide support/help systems for when users get stuck
  • Configure complex systems
  • Maintain state to reduce their cognitive load

Further complicating matters, the variation between products and the uniqueness of the information being presented to users means that web application templates are not up for the job. It is not that they haven’t been tried. There are tons of websites that sell web-app templates. Yet their adoption remains low, and the reason for that is plain to see. Unlike websites, where simply providing a variety of colors, pictures, and text is typically good enough, each web application is unique: their data, workflows, and use-cases cannot be addressed by a one-size-fits-all solution.

The complex relationships between constantly changing data and the evolving workflows to be executed means that static templates could never hope to keep up with all the possible paths and interactions a user may need to have. 

This degree of interaction and data complexity also limits the utility of drag-and-drop/WYSIWYG tools. Information hierarchies, workflows, layouts, and data visualizations (to name a few) must be carefully designed and considered. So even someone can drag and drop whatever they want, they still must decide WHAT to drag and WHERE to drag it to. Using these tools, a creating user can produce a “compilable” UI but through lack of expertise, time, and/or planning their design can violate basic UX and workflow principles.  As a result they are likely to be left with a poorly designed outcome. Thus, the adoption of this class of solutions has also been relegated to (at best) simple applications.

For teams to deliver high-quality products, the UI/UX must be deliberately designed and the UI must be carefully implemented by hand, using highly-skilled, highly-paid designers who have expertise in the architecture, creation and implementation of a quality user experience. This does not scale well.

The Promise of WYSIWYG

All the limitations above being considered, WYSIWYG tools are reasonably effective for one particular UI/UX use-case: the creation of limited or focused UI. In data science or natural language processing (NLP), these techniques work better when the data set’s scope / vocabulary is limited. For example, it is far easier to build a system that can understand only legal text or doctor’s notes (each of which has its own constrained structure/style), than a general purpose system that can understand any kind of unstructured text. By limiting the types of words, and the way those words can be used, these types of algorithms can be trained and optimized for more rigid and structured real-world usages. As a concrete example, medical dictation software (something that sounds like it should be a more recent solution) was used even in the 1990s simply because of the limited and constrained nature of doctor’s notes.

The same is true for WYSIWYG product UI creation. Consider data entry builders. These are helpful tools that allow people to create solutions for data entry; forms, basic summary statistics, and raw-record browsers (think spreadsheets). Likewise, tools that do basic data lookup and presentation (e.g., recipe finders) can also be designed and implemented with WYSIWYG. The behavior, layout and tasks of these applications are so limited in scope that these tools can constrain creating user behavior sufficiently, and, hence, can ensure a successful outcome. This is especially true when the UI layer is almost a mirror of the data layer: for example, form apps, that read and write to a basic relational database, so that their visual presentation is nearly identical to the underlying database schema.  In short, WYSIWYG can empower many users to build applications – but the scope and complexity of those apps (to ensure high quality UI and UX without having expertise) is limited.

The Consumerization of the Enterprise Experience

A new era is emerging in the B2B product space: the Consumerization of the Enterprise Experience. This is a combination of:

  • the proliferation of high-quality consumer software solutions;
  • the migration of tools from consumer into enterprise; and
  • some companies putting a premium on designing great UI/UX

These trends have resulted in a massive shift. Time and again, we see companies with fewer features and less (or no) history come in and dominate existing players. Disruptors like Box, Meraki, iPhone, PagerDuty, Gsuite, and Slack have supplanted and disrupted the existing markets simply because their look-and-feel, usability, and overall end-user experience felt like a well-designed consumer product (not like enterprise software). Employees expect and demand that their required business apps should be as useful and flexible as those they use at home on their computers, smart TVs, or phones.

To achieve this level of usability, these new applications have required a fairly significant upfront investment to set up, although once properly established, good UI/UX empowered these companies to leapfrog the competition.

Unfortunately, this is an extremely difficult strategy to execute on. Companies have limited resources: time, people, and budget. Even worse, there are increased talent shortages (lack of skill, high cost, and unrealized outsourcing help), broken internal processes (handoff delays, long development cycles, slippage no user feedback), and siloed solutions (existing tools are segregating teams) exacerbating the problem.

Access to developers is a bigger threat to business than access to capital
– Stripe

[Projects] experienced cost overruns of 150 to 200% [and] experienced time overruns of 200 to 300%
– The Standish Group

Even the most ardent supporters of good UI/UX simply may not be able to find the budget and people to successfully execute on time.

 

The Future is Automation

Templates don’t work. WYSIWYG won’t work. And manual efforts do not scale. Yet companies need to avoid being outmaneuvered by their competition. 

But take heart, help is on the way! We are Kleeen Software and we are leading the way to a revolution of how B2B companies design and build UI. 

As the tenets of our revolution, we have taken 3 key pillars:

  • Build More, Faster – even if you don’t have the UI/UX/Eng expertise
  • Make Stunning Designs – with usable, high-quality code
  • Free Up Your Resources – take your time, money and talent and put it towards developing your differentiating product features and showcasing your unique value proposition

Doing more with less, freeing up resources, and having reliably good output is the hallmark of the automation movement. 

And this is why the future for UI/UX is so bright. Numerous technologies under the very broad umbrella of “AI” have characteristics that could help turn the art of UI/UX into a repeatable science. Imagine a solution that could help teams plan, design, validate, code and deploy a product’s UI (with a compelling UX and workflows) – without creating a non-functional mockup or writing a line of code? How could multiple automation technologies come together to accelerate that process? 

Please watch this space for upcoming announcements as we (in stealth for now) work closely with a few design partners, helping them get their UI/UX visions into production at scale. 

If your team is working through similar challenges and are interested in joining our hands-on pilot, we’d love to chat.

Cover Image by Edho Pratama on Unsplash

forget

Tickets to Never Forget

Our last blog post discussed the “dreaded demo,” (integration, testing, QA, etc) and that its creation should define a sprint’s status as “complete.” 

But this is not the only thing that teams fail to account for when scoping a project or sprint. Those blind spots, the tasks that are not tracked, are the focus of this article. What is the work that must be done but is often either forgotten, not documented or not officially accounted for – thereby leading to sprint overruns or quality issues. Even worse, what are the assumed implicit tasks that end up being overlooked/un-discussed – leading to major visibility issues, ultimately, to incorrect assumptions (to assume makes an ASS out of U and ME) regarding the ultimate goal of your team.

Meetings

There is a movement to eliminate or minimize meetings (and meeting duration) currently ablaze on social media. But independent of this movement, most teams still have scheduled or predictable conversations that are part of most sprints/quarters/cadences. These can be sprint-related (planning, scoping, retrospectives), architectural planning to unify a direction, customer discussions/emails, reviews, company wide meetings etc. These all take time. And often, there is prep-work for each meeting. 

All of these interactions should be documented in tickets (JIRA, Gituhub, etc). If there is an Epic for a new feature, there should be a Story that is a planning meeting. And, there should be  another ticket for any prep work or research in preparation for that meeting; maybe a 3rd ticket to record meeting notes (or maybe one story with 3 tasks – the construct doesn’t matter). Just as the “trendy” fads for meetings (discussion of 30 minute meetings only, or no-slides, or send notes before hand) are capturing aspects OF those meetings, so should any ticket. If the meeting is 30 minutes, make sure the points for the meeting is corresponding. Prep work before hand/after should also have a ticket. And if that ticket wasn’t created at sprint planning, add it after – so that the sprint DOES REFLECT what actually happened  (and maybe why things ran over becomes clear). Consider adding a TAG for tickets made after the sprint started, to capture unexpected additions (not to assign blame but to uncover where work is coming from to make future predictions better).

People often leave these out as they feel secondary to your “real work” or because the point/hour system make them seem unimportant and therefore “invisible” in the broader scale of points.  But don’t let that fool you. These tickets don’t need to be large, or have high hours/points – but pretending they don’t exist is a big problem because that impacts productivity. Even company wide “all-hands” or an “off-site” takes time away. 

We are not advocating for MORE meetings or LESS all-hands…. But if your velocity is 65 points (or whatever your unit of measure happens to be), then if there is an all-day meeting or if monday is your retrospective/planning day, make sure you account for the time spent on those activities and to any foreseeable meetings (e.g. a design review, or architecture designing) that are part of the tasks assigned to a given sprint.

Debt

Deadlines exist and they are an inevitable like death and taxes. While we all would love to design and build n the most robust solution,sometimes we must use metaphorical duct-tape and spit to get out the door. These stop-gap measures lead to accrued technical-debt or design-debt and this is often forgotten once the deadline is met. To prevent the debt from getting out of control,  for every major release (of a product or feature) we create an epic called ABC-Debt. Every story in this epic is created when someone makes a short cut such that we all remember to refactoring and refinement later on. 

Therefore, before that team works on feature 2.0, we make sure to take technical debt off the backlog. If a team-member leaves (because there are other good jobs) a record of each  limitation exists within an annotated ticket and let the team know about blockers This isn’t perfect, and sometimes things are missed – but without recording your debt, you won’t know where there might be a hidden bomb in your product that could easily turn the next great feature from a 4 week project to a 6 month quagmire.

Project Management and Backlog Grooming

Someone always has to clean up the mess around the house. And every sprint the team makes a mess in the backlog. And just like the dishes, if you leave them dirty for too long they develop intelligence, invent fire, and start working against you.  Controlling that chaos is something that must happen every sprint.

 

In theory, every team has a project manager whose sole job is to run sprints, manage the backlog, etc. In theory, that person is using sprints to manage their own time as well. But we have found that most teams lack a project manager, leaving this work for the team leaders, so this tip applies to team leads as well. Set aside time for grooming every week (minor upkeeping) and a larger task every quarter (for a really deep clean). The Project-manager/team-lead will see things that slipped through fingers, find un-finished loose ends, and most importantly, keep abreast of all of the work your team HAS accomplished.

To validate that this clean-up has occurred (and wasn’t just ignored or paid lip service) ensure accountability. Team-leads/Project-Managers should report the current roadmap/schedule/delays to the VP of Product and/or Engineering at the end of every sprint. And at the end of each quarter, this should be reported to the CEO/GM. This hard-accounting is vital visibility that leadership needs to make decisions, and assures that that when the CEO says “hey when is X coming out” that prep work was (at worst) done 7 days ago, and is ready to surface right away (instead of hours of scrambling to answer a seemingly simple question).

Documentation

We were all taught in school to document our code and designs. Use good variable/layer names. Be consistent, and if anything, document first code/design after. Then we got to the real world and getting products done is the primary  task. But 9, 12, 18 months later (or if you are successful 5-10 years later), the team is unlikely to remember how a random function works (or the motivation behind a given design). That documented/written personal and/or group knowledge is invaluable and allows a team  to make changes faster and fix bugs more easily s even if the original author is no longer part of the team .

I know justifying documentation isn’t the point of this article, but seeing documentation fall by the wayside because it “was not a priority,” simply cannot be an excuse. When you are creating your projects, make sure to add some stories for documentation. Explicitly set aside time to annotate and explain what you created. Then when sprint planning occurs, or leadership wants to know how long something will take – you can look at the epic and say “this is a 2 sprint epic” and know that at the end of that sprint, it will be working AND be able to be supported.

In other words, start looking at sprint management as team management. It should capture everything your team must do to build and support your product – now and in the future.

CONCLUSION

So lets summarize some key take aways of things to ALWAYS track to better manage your company, more accurately predict releases, and ensure high-quality product creation:

  • Add sub-tasks to tickets for PRs, testing and integration as part of every ticket to amortize this work [from prior article]
  • Make internal live demos happen at the completion of every sprint [from prior article]
  • Make documentation of code and architecture happen (and track as tickets) as part of every sprint – and a completion criteria to prevent loss of tribal knowledge and allowing better collaboration between team-members
  • Add Sprint/work/ticket related meetings as tasks in your management system to track the full scope of how much time it takes to complete a project
  • Add company-wide meetings as part of your management system to track its impact on available points/time
  • Have a repository epic for technical debt (to be cleaned up) from the current release/feature as a method to track future work, and ensure it is picked up and resolved at the next opportunity
  • Every sprint AND quarter grooming should occur (and be tracked as tickets) to ensure a clean and organized back-log
  • To ensure visibility, better predict release schedules and make sure grooming occurs, present backlog and velocity information to VPs and CEO on a semi-regular basis

Cover Image by Fabrizio Frigeni on Unsplash

new years

Happy 2020 from Kleeen Software

Happy 2020 from Kleeen

From everyone at the Kleeen Software family to yours, we wish you a wonderful and successful 2020. 

Looking back at 2019, KS has had quite a year. Our company secured pre-seed funding, grown to 14 full time team members, 1 part-time, 2 interns, and a distinguished and accomplished board of advisers. We have launched our podcast series Kleeen Talk, and our blog series on how to better create mange and build b2b enterprise products.

Thank you to everyone (especially our friends and families) for making 2019 a year we can be proud of, and we look forward to 2020 bringing new challenges!

Cover Image by Roven Images on Unsplash

Load More