Menu
Cart

Blog

landscape-4

The New Front-End Landscape

  1. Data is (and is not) Like Oil
  2. Are You a Data-Intensive Application? [Yes]
  3. Building Non-Linear Applications
  4. The New Front-End Landscape

Data-intensive applications are everywhere. Companies are building these products to sell, and increasingly, more companies are building them internally to leverage their own internal data, AI/ML initiatives, sensors, and more. 

We have seen countless companies sitting on exabytes of data but not having the ability to turn oil into gold.  You constantly hear about companies that are never able to leverage their customer data, create a new offering for their customers, or even internal departments being stymied by their internal IT’s resources and bandwidth to take on new projects. Often this is because the bottleneck for creating such rich and non-linear workflows has been the creation of a usable front-end.

The New Front-End Landscape

When we look out at the front-end development landscape we can decompose the world into 2 axes… how fast a team can get value/build a product and how open is the stack.

And in this space, something very exciting is happening at Kleeen Software – at the intersection of an open-stack and fast time to value.

Manual

Manual Development: 
Open Stack + Long Time to Value

This is the current way companies build software today: Humans – lots of talented humans. Human designers make mockups and wireframes. Human developers convert those designs into code. This is a process that takes months to execute. And it isn’t just creating the MVP; every new feature and function you build must be designed, maintained, updated, and enhanced. And while some companies or IT teams forgo design, that can actually cost more in the long (and short) run. Even with component libraries, visualization libraries and advances in JavaScript frameworks, manual UI development is a long, erratic process, often focusing on front-end infrastructure and common workflows rather than on domain or product-specific features that can “wow” and win-over your customers.

But while the time-to-value is long, the control is quite high. You and your team can customize everything. The front-end stack is yours to control… and so is your middleware, your backend, your DB, your hosting, authentication and more. Anything you ask your engineering team to do is technically “possible,” but it all comes at a cost. That is the freedom that has kept manual development the go-to solution for building data-intensive SaaS applications.

Kleeen Software: 
Open Stack + Quick Time to Value

Kleeen Software has taken a wholly different approach. Our solution is not about enabling customers to build workflow wizards or forms for their end-users; rather it empowers customers to build products/solutions which the end-user can use to investigate data a little differently every time. This is perfect for unstructured and non-linearly structured tasks – where there exists a clearly defined structure and relationship to the underlying data.

To create a product with Kleeen, you input WHAT you want your customers to do and WHY – not drag and drop. And as a result, it isn’t just “low code,” Kleeen is No Code to generate the application front-end. Kleeen’s AI will construct workflows, design UI, and generate production code ready for you to integrate to your APIs and ship. 

Moreover, instead of previewing with a mockup, picture, or drag-and-drop layout – Kleeen builds you an instant prototype – the real production UI code (running on Kleeen’s cloud) but with simulated data. Test and validate before you spend months building out a data-lake or analytics. This is true WYSIWYG because this is the real UI with all interactions there to experience live. Thus you can design and build out a new product in a few hours, iterate and have a full front-end integrated with your stack in days, not months.

Kleeen Software is not just about BI and data visualizations. We create the UI and the UX, allowing you to create a “Single Pane of Glass” to merge insights and context from those data visualizations with CRUD operations, actionable insights, and buttons that can connect to complex back-end business logic or even change data values to move a company forward. In short, we allow end-users to analyze data, make their decisions, and take action, regardless of where the data resides.

The secret here is transparency. Kleeen Software generates front-end code and checks it into your Git repository as a pull request. You can see, review and approve any and all coding changes. Nothing is closed. Because at the end of the day, your team is responsible for your product – which means you are responsible for the code. And Kleeen Software knows that too. 

In addition, every API needed by the generated front-end has a corresponding hook providing state and context from the UI and providing you the specification for the incoming data from whatever backend technology you wish to hook up. In the end, Kleeen is just a developer on your team — an extremely highly productive one. 

Furthermore, Kleeen allows you to drop in custom modals, widgets, pages, authentication systems, even styling. As a result, if you like your BI tool, drop in embedded-BI. If you need to create something custom that is domain specific, product specific, or a dashboard with “sizzle,” Kleeen doesn’t stop you at all. Want to restyle your product to conform with your brand, go ahead and drop in your custom CSS. Kleeen doesn’t box you in – it takes the most common workflows and front-end infrastructure off your plate with a true no-code solution, freeing up time, people and money to focus on what makes your product great. And next time you have a new feature, want to make an update, or respond to a customer – it turns into a resourcing decision not an “if” decision.

Cover Photo by Robert Lukeman on Unsplash

landscape-3

Building Non-Linear Applications

,

  1. Data is (and is not) Like Oil
  2. Are You a Data-Intensive Application? [Yes]
  3. Building Non-Linear Applications
  4. The New Front-End Landscape

Data-intensive applications are an essential part of the B2B landscape. They power more and more vital parts of the enterprise world. Marketing, Sales, IT, Engineering, and HR are all increasingly data-dependent segments in a business – as evidenced by how many products are being funded and built to target these data-hungry users. And while companies like Snowflake have created fantastic data solutions, the insights provided by the data/AI/ML are only valuable when exposed to end users in an intuitive way that enables them to investigate, understand and take actions in response to their changing data landscapes.

In short, humans need a front-end for these data-intensive applications. And the expectation for usability is growing, not shrinking.

But these data-intensive apps are not prescriptive – they are definitely not cookie-cutter or one size fits all.  You cannot build a linear workflow or wizard to help users investigate and remediate their data – at least not for a broad range of data originating from different sources and being used by different kinds of end users in different businesses. End users will use data products a little differently every time; following different connections, making different decisions – all based on the data they see. These investigations/explorations are unstructured (or at least non-linearly structured) tasks. And as such, the UI and UX for these products must also support unstructured data exploration that could start at multiple places, traverse multiple different connections, and conclude at multiple endpoints.

Creating this type of application is a daunting task. One that involves configuration, CRUD (create, read, update, delete) operations, actions, data visualization (of course), and most importantly, a deeply interconnected set of pages and views that can respond to the changing needs of the end user. For most complicated data, using templates does not work as these applications must reflect specific concepts and the interconnected relationship of those concepts to give the users any chance of finding the kind of patterns they need to create or test their hypotheses.

Allowing a product to deal with  this level of  interconnectedness is the key to supporting the common categories of workflow a data-intensive product needs; monitor/browse – investigate/drill-in – remediate/take-action.  The resulting complexity is also the most common frustration point. How many times have you seen something in a product and wanted to drill down?

“Oh this expense report from Steve looks high – let me see what items he is expensing?” 

Only to find out it isn’t a link

“Damn, ok – let me write down this expense report name, then i’ll navigate to the report management page… and I’ll  filter and find that report, ok – wait for that to load. Ok…”

And now you need to drill in again, and again and again… but your context is lost. You can’t even rely on your browser history because it is cluttered with all these intermediate pages.  Every one of those links must be hand-coded. Every visualization of any relationship that helps you make such a connection must be manually connected by an engineer.

This is a constant failing of these data-intensive applications. A new way of building data-intensive applications is needed – one where creating connections is not just easy but automatic. A process by which generating most grids/tables, common visualizations, enabling actions/CRUD-operations is simple (and maybe even generated/facilitated automatically). A platform that can facilitate and generate the front-end infrastructure that takes forever to build (theming, internationalization, UI access control, navigation, etc) freeing up resources to create domain-specific and product-specific UI and UX. A solution that allows you to respond to customers and update your UI/UX in hours, allowing your talented staff to focus on the roadmap and adding “sizzle” and innovation to your product.

So what does this mean for developing and maintaining these data-intensive applications?

Cover Photo by Rodrigo Soares on Unsplash

landscape-2

Are You a Data-Intensive Application? [Yes]

,

  1. Data is (and is not) Like Oil
  2. Are You a Data-Intensive Application? [Yes]
  3. Building Non-Linear Applications
  4. The New Front-End Landscape

This is a data-intensive world. Almost every product’s success depends on data. Data that end-users need to understand, to drill-in into, to make sense of, and to take action on.  

IoT Management

Consider an IoT management system: It brings together data from an automotive plant, agricultural center, or smart-city infrastructure. There are thousands of sensors, terabytes of data, and rich AI/analytics capabilities that help make sense of this information. But the end-users of the management system need to find insights, drill into related data, identify possible new patterns, and then take action based on their investigations – be it to create a repair ticket for an automotive part defect, change watering cycles on a crop, or adjust electric/water distribution to respond to changing demands.

People Management

Consider an application to help recruiters (and their customers) sift through huge amounts of job candidates: End-users need to see trends, find outliers and distributions, drill into specific former employers or job-levels, filter and refine data by skills – create hypotheses, test them, and eventually take action on specific candidates. 

Networking

Consider a company, providing wireless and wired internet to hundreds of employees (or servers in data centers) in anywhere from one to hundreds of locations: Not only do the IT analysts need to manage the internet infrastructure (finding performance issues, identifying the root cause and updating/adjusting the network in response), but they also need to track hacking attempts (using both known and unknown access points), find security threats as they happen, and then quarantine impacted users, applications and devices.

All of these examples (and more) are products or services that are predicated on data. Data empowers AI and machine learning to find patterns and make connections, but humans still need to understand that data, those patterns, and the insights provided by AI. Humans need to take action on that data and those insights, to remediate problems and impact the top and bottom line for their organizations. Humans still need to configure, update, and maintain the data and infrastructure providing that data. 

What is perhaps most important is that while there is a clear structure to the abstract data and concepts of the product, it is ultimately humans that must determine if the specific relationships of that data on screen are useful. Are there valid relationships between the insights, information and analytics? A complex network can overwhelm a user, but in the end, a human must traverse it. Only through an exploration and investigation – from the problem, to root cause, to taking a remediation action – can this data provide real value to the end user and their organization. 

But how do we build these Data-Intensive applications?  Continue reading in our next article.

Cover Photo by Marcelo Quinan on Unsplash

landscape-1

Data is (and is not) Like Oil

  1. Data is (and is not) Like Oil
  2. Are You a Data-Intensive Application? [Yes]
  3. Building Non-Linear Applications
  4. The New Front-End Landscape

There is a saying,  “Data is the new oil.”  When it is raw and unrefined it has little or no value, but after it is refined, exported, and transformed it is worth lots of money. And like unrefined oil, raw data can be turned into many products, each with their own consequences for our businesses and our economy. Loss of data through data breaches (or like oil through spills) has huge ramifications. Hence only proper management and good governance can ensure that raw data will provide lasting value. 

There is a key difference between the oil and data. Once oil is transformed into petrol or plastics, it is used up. You can’t use the same gallon of crude oil over and over to solve new problems (and yes we are ignoring recycling here) – but you can, and do, re-use raw data – it is truly the ultimate renewable resource!

Consider web-traffic for a website or maybe even behavior tracking in a product. That data can be examined in multiple ways. An AI system could provide insights about your visitor paths, entry points, and more. And as an owner/manager of that service, you will take different actions depending on those insights and the path into that data you traverse. Maybe after investigating and drilling in, you discover users convert if they come from a certain Keyword search and you would want to increase your SEO… but that same data, examined differently – traversed in a different path – would also lead you to understand that certain countries or time-zones are visiting your new material, adjusting when you push updates. And of course, looking at current vs historical trends is vital. Data keeps coming back.

The data has real value only when it supports an end user in their achievement of a goal. The data, the relationship between one piece of data and another, and even the data’s structure – that is what an end user needs to explore, to traverse, to combine, and to analyze. And unlike oil, that same data can and will be used and reused.

So what do we call these types of data-centric applications? This is not a form or data entry application. The focus here is on exploring, investigating, and taking action based on data. It isn’t a simple business intelligence (BI) or dashboarding solution that reports data in preconfigured ways. 

The answer is that they are data-intensive applications.

Continue reading in our next article: Are You a Data-Intensive Application? [Yes]

Cover Photo by John Mark Arnold on Unsplash

speedlight

Upgrade Your Product Lifecycle

Who hasn’t seen this diagram? The normal product lifecycle; a collaboration between product management, design, development, QA and support (or whatever subset your organization has).  And while we all do this, the question is – who finds this process that effective?

Upgrade Your Product Lifecycle

In reality, product creation is like a game of telephone. The Product Owner (Line of Business, Product Manager or VP of Development) has a vision of what the customer needs. This product owner encodes those specifications in a document and the product owner passes them on to a designer (assuming you can find/afford one). The designer attempts to translate that vision into UI/UX designs with wireframes and mockups. Then front-end engineers translate those designs into front-end code. But each step along the way, each translation between team members, things are left-out, dropped, misunderstood, or overlooked.

By the time this full lifecycle has run, maintenance and support are fixing, or enhancing features that should have already been solved – rather than truly listening to customers and adding new value that customers articulate.

Upgrade Your Product Lifecycle

With Kleeen Software we augment (not replace) almost every step in the product lifecycle, taking the burden off of your team and allowing you to focus.

100% of your product lifecycle moves at the speed of manual processes

Before Kleeen

100% of your product lifecycle moves at the speed of manual processes
80% of your product lifecycle is accelerated with Kleeen Software

After Kleeen

80% of your product lifecycle is accelerated with Kleeen Software

Kleeen’s Value Throughout Your Product Lifecycle:

Concept

When engaging and listening to customers (or future customers) Kleeen can be an invaluable tool. Product Managers or Solution Engineers can continue to listen, but they are not limited to that!  They can also build a quick demo with Kleeen’s Instant Prototypes (real front-end code with simulated data) to show they understand the customer expectations, validating immediately and ensuring what is built is what the customer wants. It doesn’t need to be perfect – but fully functioning and executable prototypes can show you are on the right path

Are you ready to upgrade your product lifecycle?

Try Kleeen for Free

 

Cover Photo by CHUTTERSNAP on Unsplash

disposable UI

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

  1. It is all about “Idea Validation”
  2. It is all about the “MVP”
  3. It is all about “Maintenance and Features”
  4. It is all about “Disposable UI” – The Future of Front Ends

This is the final article in a 4-part series covering the challenges from idea validation to MVP creation, maintenance / new feature creation.

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”

  1. It is all about “Idea Validation”
  2. It is all about the “MVP”
  3. It is all about “Maintenance and Features”
  4. It is all about “Disposable UI” – The Future of Front Ends

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”

  1. It is all about “Idea Validation”
  2. It is all about the “MVP”
  3. It is all about “Maintenance and Features”
  4. It is all about “Disposable UI” – The Future of Front Ends

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”

This is post 3 of 4 in the series “Products Are All About…” It is all about “Idea Validation” It is all about the “MVP” It is all about “Maintenance and Features” It is all about “Disposable UI” – The Future of Front Ends Your first customers are using your product, and the word around […]

Cover Image Markus Spiske on Unsplash

all-about-product

It is all about “Idea Validation”

This is post 1 of 4 in the series “Products Are All About...”

  1. It is all about “Idea Validation”
  2. It is all about the “MVP”
  3. It is all about “Maintenance and Features”
  4. It is all about “Disposable UI” – The Future of Front Ends

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”

This is post 2 of 4 in the series “Products Are All About…” It is all about “Idea Validation” It is all about the “MVP” It is all about “Maintenance and Features” It is all about “Disposable UI” – The Future of Front Ends You believe you know what you need to build. Your customers […]

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.

Link
Why UI Takes So Long To Build

Getting MVP/1.0

Link
Why UI Takes So Long To Build

Maintenance/Minor-Enhancements

Link
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

Load More